[Hackage] #214: Package security
#214: Package security ------------------------------+--------------------------------------------- Reporter: duncan | Owner: Type: task | Status: new Priority: normal | Milestone: Component: misc | Version: 1.2.3.0 Severity: normal | Keywords: Difficulty: project(> week) | Ghcversion: 6.8.2 Platform: | ------------------------------+--------------------------------------------- It'd be nice to avoid getting hacked by a trojaned package. This task is to: * survey the issue * consider the threats * see what solutions other systems use * consider the cost/benefit trade-offs in various security solutions * propose something -- Ticket URL: http://hackage.haskell.org/trac/hackage/ticket/214 Hackage http://haskell.org/cabal/ Hackage: Cabal and related projects
#214: Package security ---------------------+------------------------------------------------------ Reporter: duncan | Owner: Type: task | Status: new Priority: normal | Milestone: Component: misc | Version: 1.2.3.0 Severity: normal | Resolution: Keywords: | Difficulty: project(> week) Ghcversion: 6.8.2 | Platform: ---------------------+------------------------------------------------------ Changes (by guest): * cc: svein.ove@aas.no (added) -- Ticket URL: http://hackage.haskell.org/trac/hackage/ticket/214#comment:1 Hackage http://haskell.org/cabal/ Hackage: Cabal and related projects
#214: Package security ---------------------+------------------------------------------------------ Reporter: duncan | Owner: Type: task | Status: new Priority: normal | Milestone: Component: misc | Version: 1.2.3.0 Severity: normal | Resolution: Keywords: | Difficulty: project(> week) Ghcversion: 6.8.2 | Platform: ---------------------+------------------------------------------------------ Comment (by guest): This does seem important. I'll have a look. - svein -- Ticket URL: http://hackage.haskell.org/trac/hackage/ticket/214#comment:2 Hackage http://haskell.org/cabal/ Hackage: Cabal and related projects
#214: Package security ----------------------------+----------------------------------------------- Reporter: duncan | Owner: Type: task | Status: new Priority: normal | Milestone: Component: miscellaneous | Version: 1.2.3.0 Severity: normal | Resolution: Keywords: | Difficulty: project(> week) Ghcversion: 6.8.2 | Platform: ----------------------------+----------------------------------------------- Changes (by guest): * cc: matthew@wellquite.org (added) -- Ticket URL: http://hackage.haskell.org/trac/hackage/ticket/214#comment:3 Hackage http://haskell.org/cabal/ Hackage: Cabal and related projects
#214: Package security ----------------------------+----------------------------------------------- Reporter: duncan | Owner: Type: task | Status: new Priority: normal | Milestone: Component: miscellaneous | Version: 1.2.3.0 Severity: normal | Resolution: Keywords: | Difficulty: project(> week) Ghcversion: 6.8.2 | Platform: ----------------------------+----------------------------------------------- Comment (by duncan): See for example this little demo: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/rmrf "Delete your home directory during compliation" It doesn't actually do it of course. It's just a demo. It's probably been taken down by the time you read this so I've attachd the tarball for reference. -- Ticket URL: http://hackage.haskell.org/trac/hackage/ticket/214#comment:4 Hackage http://haskell.org/cabal/ Hackage: Cabal and related projects
#214: Package security ----------------------------+----------------------------------------------- Reporter: duncan | Owner: Type: task | Status: new Priority: normal | Milestone: Component: miscellaneous | Version: 1.2.3.0 Severity: normal | Resolution: Keywords: | Difficulty: project(> week) Ghcversion: 6.8.2 | Platform: ----------------------------+----------------------------------------------- Comment (by ross): I don't appreciate having my time wasted with demonstrations of the bleedin' obvious. I'll delete the username of the next "demonstrator". -- Ticket URL: http://hackage.haskell.org/trac/hackage/ticket/214#comment:5 Hackage http://haskell.org/cabal/ Hackage: Cabal and related projects
#214: Package security ----------------------------+----------------------------------------------- Reporter: duncan | Owner: Type: task | Status: new Priority: normal | Milestone: Component: miscellaneous | Version: 1.2.3.0 Severity: normal | Resolution: Keywords: | Difficulty: project(> week) Ghcversion: 6.8.2 | Platform: ----------------------------+----------------------------------------------- Comment (by duncan): We discussed this on #ghc this afternoon. For reference some other obvious ways to make a trojan package are: * with build-type Custom using a malicious Setup.hs * with build-type Configure using a malicious ./configure * with build-type Simple using a malicious custom pre-processor and {{{ghc-options: -F -pgmF dist/build/foo/foo}}} * with build-type Simple using {{{ghc-options: -F -pgmFrm -optF-rf}}} I assume the tricks with ghc options work just as well in {-# OPTIONS #-} pragmas in source files. Then of course there is TH as in today's example which can do arbitrarily bad things, since it has access to IO via runIO and unsafePerformIO. So clearly it's not sensible to try and patch all these holes just so that we can build (but not run) hostile packages safely, when the obvious way to do that is using OS sandboxing features. As for users downloading bad packages, perhaps we should ask why they might be more likely to download and run an unknown package from hackage than say `132.73.41.22/hax0r.sh`. We should be careful not to give any false sense of security. -- Ticket URL: http://hackage.haskell.org/trac/hackage/ticket/214#comment:6 Hackage http://haskell.org/cabal/ Hackage: Cabal and related projects
#214: Package security ----------------------------+----------------------------------------------- Reporter: duncan | Owner: Type: task | Status: new Priority: normal | Milestone: Component: miscellaneous | Version: 1.2.3.0 Severity: normal | Resolution: Keywords: | Difficulty: project(> week) Ghcversion: 6.8.2 | Platform: ----------------------------+----------------------------------------------- Comment (by guest): ''As for users downloading bad packages, perhaps we should ask why they might be more likely to download and run an unknown package from hackage than say 132.73.41.22/hax0r.sh.'' I think {{{cabal install}}} is a fair answer to that question. Together with #239 we have a real security problem, because it makes package names untrustworthy. Password protecting packages as discussed on the libraries list would help there. - int-e -- Ticket URL: http://hackage.haskell.org/trac/hackage/ticket/214#comment:7 Hackage http://haskell.org/cabal/ Hackage: Cabal and related projects
#214: Package security ----------------------------+----------------------------------------------- Reporter: duncan | Owner: Type: task | Status: new Priority: normal | Milestone: Component: miscellaneous | Version: 1.2.3.0 Severity: normal | Resolution: Keywords: | Difficulty: project(> week) Ghcversion: 6.8.2 | Platform: ----------------------------+----------------------------------------------- Comment (by guest): I agree with int-e - by putting something on hackage, and telling everyone that hackage is great, we are putting some faith in the system. I think instead of trusting packages, we should be trusting uploaders. There aren't going to be many people who write 3 real Haskell libraries, then on their fourth go, decide to harm everyone. Perhaps a "this person also uploaded", or a cursory check by a human when a person uploads their first package. -- Ticket URL: http://hackage.haskell.org/trac/hackage/ticket/214#comment:8 Hackage http://haskell.org/cabal/ Hackage: Cabal and related projects
#214: Package security ----------------------------+----------------------------------------------- Reporter: duncan | Owner: Type: task | Status: new Priority: normal | Milestone: Component: miscellaneous | Version: 1.2.3.0 Severity: normal | Resolution: Keywords: | Difficulty: project(> week) Ghcversion: 6.8.2 | Platform: ----------------------------+----------------------------------------------- Comment (by duncan): I accept that it's bad to be able to subvert an existing named package that has people's trust. #239 is now fixed. I agree that we want a system to let package authors limit who else should be allowed to upload their package. Linking authors to what else they have uploaded is also a good idea. My point was about a new package that someone uploaded as in the recent demo and that that's not so much of a problem precisely because its new. We expect people to download packages they know of or have had recommended, not random packages. -- Ticket URL: http://hackage.haskell.org/trac/hackage/ticket/214#comment:9 Hackage http://haskell.org/cabal/ Hackage: Cabal and related projects
#214: Package security ----------------------------+----------------------------------------------- Reporter: duncan | Owner: Type: task | Status: new Priority: normal | Milestone: Component: miscellaneous | Version: 1.2.3.0 Severity: normal | Resolution: Keywords: | Difficulty: project(> week) Ghcversion: 6.8.2 | Platform: ----------------------------+----------------------------------------------- Comment (by guest): I worry about the idea of providing "security" or some notion of safety or trust only if one behaves "as expected". That seems slightly odd to me. Secondly, there has to be a first person or a first five people that grab the package to try it out and to give it its initial "rating". And those five could be 500 if it's suitably advertised, an oft requested feature or a popular idea. Try adding a package to Hackage that claims it adds a dependently typed system to Haskell and watch the number of downloads! And if such a package as that is trojaned... -- matthew -- Ticket URL: http://hackage.haskell.org/trac/hackage/ticket/214#comment:10 Hackage http://haskell.org/cabal/ Hackage: Cabal and related projects
I accept that it's bad to be able to subvert an existing named package
#214: Package security ----------------------------+----------------------------------------------- Reporter: duncan | Owner: Type: task | Status: new Priority: normal | Milestone: Component: miscellaneous | Version: 1.2.3.0 Severity: normal | Resolution: Keywords: | Difficulty: project(> week) Ghcversion: 6.8.2 | Platform: ----------------------------+----------------------------------------------- Comment (by ross@soi.city.ac.uk): Replying to [comment:9 duncan]: that has people's trust. #239 is now fixed. I agree that we want a system to let package authors limit who else should be allowed to upload their package. #239 is only fixed in that you cannot replace an existing version, and the uploader is displayed on the package page. It remains possible for anyone to upload a new version of any package. I've been assuming that I'm dealing with responsible people, and will remove any that aren't. People seem very keen to jump to the last item on your list above. Most security measures have costs to implementors, users and in maintenance. If they cover only some of the holes, they will be worse than useless: the system will be harder to use and maintain, but no more secure.
Linking authors to what else they have uploaded is also a good idea.
This would be useful, and tied in with build reporting would give some sort of ranking of package maintainers, and may motivate them to test their packages before uploading them. I'm not sure it would help a lot with security, though. -- Ticket URL: http://hackage.haskell.org/trac/hackage/ticket/214#comment:11 Hackage http://haskell.org/cabal/ Hackage: Cabal and related projects
#214: Package security ----------------------------+----------------------------------------------- Reporter: duncan | Owner: Type: task | Status: new Priority: normal | Milestone: Component: miscellaneous | Version: 1.2.3.0 Severity: normal | Resolution: Keywords: | Difficulty: project(> week) Ghcversion: 6.8.2 | Platform: ----------------------------+----------------------------------------------- Comment (by guest): Replying to [comment:9 myself]:
Password protecting packages as discussed on the libraries list
Actually I liked the idea of limiting the uploaders of packages better, because it has a smaller impact on the authors' workflow, and paves the way for trusting packages by their base name (which is what {{{cabal- install}}} uses to find packages.) In a way it's similar to what CPAN does. They force their authors to register the namespace they are going to use, and their package names are tied to the namespace. (http://www.cpan.org/modules/04pause.html) They also have co-maintainers for packages, and they require admin intervention for taking over orphaned packages. (http://www.nntp.perl.org/group/perl.cvs.perlfaq/2007/07/msg393.html) - int-e -- Ticket URL: http://hackage.haskell.org/trac/hackage/ticket/214#comment:12 Hackage http://haskell.org/cabal/ Hackage: Cabal and related projects
#214: Package security ----------------------------+----------------------------------------------- Reporter: duncan | Owner: Type: task | Status: new Priority: normal | Milestone: Component: miscellaneous | Version: 1.2.3.0 Severity: normal | Resolution: Keywords: | Difficulty: project(> week) Ghcversion: 6.8.2 | Platform: ----------------------------+----------------------------------------------- Comment (by ross): Replying to [comment:12 guest]:
Replying to [comment:9 myself]:
Password protecting packages as discussed on the libraries list
Actually I liked the idea of limiting the uploaders of packages better, because it has a smaller impact on the authors' workflow, and paves the way for trusting packages by their base name (which is what {{{cabal- install}}} uses to find packages.)
I suspect that Bulat, who proposed that, didn't realize that we have password authentication for users. There may be an inevitable logic to what you say. Still, there's only been one case so far of someone overwriting a package, and that wouldn't have happened if we had had a policy on display. Almost all of the problems so far have been with the first upload (by a non-maintainer), and this machinery wouldn't help there, but would make it worse. -- Ticket URL: http://hackage.haskell.org/trac/hackage/ticket/214#comment:13 Hackage http://haskell.org/cabal/ Hackage: Cabal and related projects
#214: Package security ----------------------------+----------------------------------------------- Reporter: duncan | Owner: Type: task | Status: new Priority: normal | Milestone: Component: miscellaneous | Version: 1.2.3.0 Severity: normal | Resolution: Keywords: | Difficulty: project(> week) Ghcversion: 6.8.2 | Platform: ----------------------------+----------------------------------------------- Comment (by duncan): Replying to [comment:10 guest]:
I worry about the idea of providing "security" or some notion of safety or trust only if one behaves "as expected". That seems slightly odd to me.
I think it's really essential. You are expecting for some reason that something on hackage is held to a higher security or QA standard than something else you randomly download off the web. What gives you that confidence? What makes you think other users have that confidence? Perhaps that's the security problem. There's no security problem with `132.73.41.22/hax0r.sh` because there's no reason you would expect to trust it. As I said, a name can establish a reputation so there is value in preventing well known names from being subverted. -- Ticket URL: http://hackage.haskell.org/trac/hackage/ticket/214#comment:14 Hackage http://haskell.org/cabal/ Hackage: Cabal and related projects
Replying to [comment:10 guest]:
I worry about the idea of providing "security" or some notion of safety or trust only if one behaves "as expected". That seems slightly odd to me.
I think it's really essential. You are expecting for some reason that something on hackage is held to a higher security or QA standard than something else you randomly download off the web. What gives you that confidence? What makes you think other users have that confidence? Perhaps
As I said, a name can establish a reputation so there is value in
#214: Package security ----------------------------+----------------------------------------------- Reporter: duncan | Owner: Type: task | Status: new Priority: normal | Milestone: Component: miscellaneous | Version: 1.2.3.0 Severity: normal | Resolution: Keywords: | Difficulty: project(> week) Ghcversion: 6.8.2 | Platform: ----------------------------+----------------------------------------------- Comment (by guest): Replying to [comment:14 duncan]: that's the security problem. There's no security problem with `132.73.41.22/hax0r.sh` because there's no reason you would expect to trust it. I'm not sure we're disagreeing, I think we're just talking about different things. You say "We expect people to download packages they know of or have had recommended, not random packages." I'm trying to say that the only way in which code can migrate from "random package" status to "known and/or recommended" status is precisely by people downloading random packages. preventing well known names from being subverted. Yes, absolutely, except without the "well known" bit. -- matthew -- Ticket URL: http://hackage.haskell.org/trac/hackage/ticket/214#comment:15 Hackage http://haskell.org/cabal/ Hackage: Cabal and related projects
Yes, absolutely, except without the "well known" bit. -- matthew
I don't have an account yet so I can't answer on trac, can I? I've talked about this with dcoutts some time ago. And he told me he has already implemnted kind of strace tool. One way would be: Use kind of sandbox/ observation and build the package once on hackage. If it doesn't try to rm -fr ${HOMe} it's considered beeing safe and everyone can download it.. If it tries to do such stupid things (and making connections to somewhere else should be considered stupid..) it could be marked as malicious .. Of course the package might become malicious only on Monday or after 9.11.2011 etc.. but obvious packages which would hurt hundreds of people could be catched this way easily. All we would need is a build system. Of course we can't do anything about this only no Monday problem but trusting uploaders.. Marc Weber
Hi Marc,
I don't have an account yet so I can't answer on trac, can I?
Username: guest Password: haskell'
And he told me he has already implemnted kind of strace tool. One way would be: Use kind of sandbox/ observation and build the package once on hackage. If it doesn't try to rm -fr ${HOMe} it's considered beeing safe and everyone can download it.. If it tries to do such stupid things (and making connections to somewhere else should be considered stupid..) it could be marked as malicious ..
If you make it harder to do this, you are really just encouraging people to be more creative. If you leave a box on a table, everyone will leave it alone. If you lock the box, you are just encouraging people to test their lock picking skills. Thanks Neil
participants (3)
-
Hackage -
Marc Weber -
Neil Mitchell