On Wed, 2009-11-18 at 23:18 +0530, Rahul Sundaram wrote: > On 11/18/2009 11:19 PM, nodata wrote: > > > > > Thanks. I have changed the title to: > > "All users get to install software on a machine they do not have the > > root password to" > > .. if the packages are signed and from a signed repository. So, you left > out the important part. Explain why this is a problem in a bit more > detail. That is important, and personally I have a lot of sympathy for some of the desired use cases¹ I've heard about. On the other hand this does open up a lot of ways to attack the system, esp. given that there is _no_ authentication ... as I had expected that code running as the user would still have to authenticate as the user (Hello Linux virus makers, welcome to the party). Off the top of my head, these are the first things I'd look at for attacking a system with PK and this config: 1. Does "install" of obsoleting packages come under the same auth. (if so I can now arbitrarily upgrade certain packages). 2. Does "install" of installonly come under the same auth. (if so I can now stop kernel upgrades). 3. Are there any attacks due to disk space used? Eg. If /var is low² I can probably install enough pkgs to make logging stop. 4. Are there any attacks against packages with "default on" services? (Note that you can almost certainly wait until there is an attack, and then install the insecure service). 5. Are there any attacks against packages with set*id apps? (Dito. with the waiting approach in #4). 6. Are there any attacks against packages which provide plugins? (Dito. waiting) 7. And the most obvious one ... how hard is it to get a bad package into one of the repos. that the machine has enabled. ¹ Things like letting a spouse/child install a new game/theme/editor/etc. without having to get "their admin" to do it. ² If /var is on a separate partition then spamming /var/tmp is a goood first step here. -- James Antill - james@xxxxxxxxxxxxxxxxx http://yum.baseurl.org/wiki/releases http://yum.baseurl.org/wiki/whatsnew/3.2.25 http://yum.baseurl.org/wiki/YumMultipleMachineCaching -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
