Re: Local users get to play root?
On Wed, 18 Nov 2009, Casey Dahlin wrote: On 11/18/2009 02:10 PM, Seth Vidal wrote: On Wed, 18 Nov 2009, Konstantin Ryabitsev wrote: 2009/11/18 Casey Dahlin cdah...@redhat.com: On 11/18/2009 01:22 PM, James Antill wrote: 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. I'm betting there's still enough systems out there without enough space in /usr for the entire package set. That's kind of a silly exercise in what-ifs. The default anaconda partition scheme is /boot, swap, and /. If someone wanted to fill up the disk, they can just write to /tmp on a default install. well - except for the 5% reserved for root :) -sv Which isn't safe from this since ultimately its root doing the install on the unprivileged user's behalf. which is why I said the user filling up /tmp couldn't fill up the whole disk.. -sv -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Local users get to play root?
Seth Vidal wrote: On Wed, 18 Nov 2009, nodata wrote: -sv I do if it's in the default DVD install, or was pulled in in an upgrade. I've never intentionally installed it, and yes I do. Never imagined it would be a problem. I'll remove it. Maybe you and I have a different concept of 'Servers'. But I tend to install @core only and then remove items whenever I can for a server. If it is a bad day I'll install X b/c something requires it but for servers I try to avoid anything beside the barest minimal I can have. Maybe you have a different concept of security, but I don't want any user on the server installing software, no matter what. right - which is why I wouldn't install PK on a server. yum doesn't allow users to install pkgs, only root. $ sudo rpm -e PackageKit error: Failed dependencies: ... PackageKit is needed by (installed) setroubleshoot-2.2.42-1.fc12.x86_64 Ouch. I like setroubleshoot. Is there some way to disable PackageKit but keep setroubleshoot? Andrew. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
F12 checksum file says it is SHA1 but it is SHA256
Hi, the file Fedora-12-i386-CHECKSUM which is on the mirrors and included in the torrents says: Hash: SHA1 f0ad929cd259957e160ea442eb80986b5f01daaffdbcc7e5a1840a666c4447c7 *Fedora-12-i386-DVD.iso But the truth is that it is SHA256. (I downloaded the DVD twice because of this...) So maybe someone could change that if I am right? Cheers Stefan -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Local users get to play root?
2009/11/18 Andrew Haley a...@redhat.com: Is there some way to disable PackageKit but keep setroubleshoot? Just set all the policykit answers to no. You'll find more than just setroubleshoot breaks if you do this. Richard. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Local users get to play root?
On 11/18/09 12:03, Konstantin Ryabitsev wrote: 2009/11/18 Simo Sorcesso...@redhat.com: If I have physical access to your machine, I'll own it. I may have to use tools to get to the HDD, but it's only a question of time and dedication. *you* are not one of my users, and this has nothing to do with *you* hacking in my machine. If I have physical access to a machine I do not even care about what's installed on it. In 99% of the cases I will just be able to boot from a live cd. That's a completely different issue. Well, then we're violently agreeing about the same thing. Anyway. It doesn't look like this is a change in Fedora policy, because it clearly caught everyone off-guard. Looks like PK developer made an executive decision and it's up to us to either issue an update to revert to the previous behaviour, or to continue debating whether allowing local console users to install trusted software from trusted repositories is a sane security trade-off. I haven't tried .. but does this this also include the capability for my grade-school child to *remove* software using their account? Like gcc? glibc? gdm? All fun activities ... -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Local users get to play root?
Am 2009-11-18 20:20, schrieb Richard Hughes: 2009/11/18 Casey Dahlincdah...@redhat.com: By the admin's first opportunity to change the settings the box could already be rooted. I'm not sure how you can root a computer from installing signed content by a user that already has physical access to the machine. You install software with a known buffer overflow before it is fixed and exploit it. More software = more chances to exploit. Bingo! -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Local users get to play root?
2009/11/18 Bob Arendt r...@rincon.com: I haven't tried .. but does this this also include the capability for my grade-school child to *remove* software using their account? Like gcc? glibc? gdm? All fun activities ... No, removing is a different role and requires a different authentication. The default is to ask the root password for the machine. Richard. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Local users get to play root?
On Wed, 18 Nov 2009, Richard Hughes wrote: 2009/11/18 Andrew Haley a...@redhat.com: Is there some way to disable PackageKit but keep setroubleshoot? Just set all the policykit answers to no. You'll find more than just setroubleshoot breaks if you do this. How do you do this? Set the policykit answers to no? -sv -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Local users get to play root?
2009/11/18 nodata l...@nodata.co.uk: You install software with a known buffer overflow before it is fixed and exploit it. More software = more chances to exploit. Bingo! Why would the additional package start extra services? I thought there were guidelines about that. Anyway, if the user has physical access to the machine, there are many quicker ways to root the box in question. (Like rebooting, and using grub to go to runlevel 1) Richard. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Local users get to play root?
On 11/18/2009 01:30 PM, Robert Locke wrote: Picture Windows Server for a moment. Now picture that admin coming over to administer a new Linux server. What's he gonna install? Click Next repeatedly. I'd like to think that our policy toward that user is one of education rather than accomodation. --CJD -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Local users get to play root?
2009/11/18 nodata l...@nodata.co.uk: Am 2009-11-18 20:20, schrieb Richard Hughes: 2009/11/18 Casey Dahlincdah...@redhat.com: By the admin's first opportunity to change the settings the box could already be rooted. I'm not sure how you can root a computer from installing signed content by a user that already has physical access to the machine. You install software with a known buffer overflow before it is fixed and exploit it. More software = more chances to exploit. Bingo! If a user logged in from a physical local console wanted to exploit their machine, this would be the hard way to do it. Regards, -- McGill University IT Security Konstantin Ryabitsev Montréal, Québec -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Local users get to play root?
Once upon a time, Colin Walters walt...@verbum.org said: On Wed, Nov 18, 2009 at 1:48 PM, Chris Adams cmad...@hiwaay.net wrote: It seems the latest way of doing this is via PolicyKit. Â IMHO all PolicyKit configuration should be secure by default, secure is an meaningless term without reference to a deployment model and threat model, but let's assume here for reference that what you mean is that the shipped RPMs should be configured to not grant any additional privileges over that afforded to the traditional Unix timesharing model, and then the desktop kickstart modifies them. Yes, that was what I meant. I would agree with that, but it's not trivial. Are we just scoping in PackageKit here, or also consolehelper @console actions? Does it imply removing the setuid bit from /bin/ping? In an ideal world, everything that could grant elevated privilege would come without it, and the admin (or spin config files) could easily configure it back. That obviously fails for things like /bin/ping, since that uses file permissions, and that's part of the RPM (and not configurable). However, ping has traditionally been run-able as a non-root user, and it is easily spotted with find. The number of setuid programs is small these days, but several of them are now helpers that allow a wide-range of other programs access, again with minimal documentation (what is pulse/proximity-helper? why is nspluginwrapper/plugin-config setuid root?) I think anything that uses PolicyKit should ship with no elevated privileges by default, since it is configurable. It would be nice to also get consolehelper, but that is more complicated. I thought that was on the way out (to be replaced by PolicyKit), but I see there are still a number of things that use it (looking at the F11 desktop I'm on right now). NetworkManager is another thing that probably could use some admin control in some places, especially as it is being pushed to replace the old network scripts. Does NM use PolicyKit or consolehelper, or does it just do things itself? Right now, I see files /usr/share/PolicyKit/policy; I guess that's where this kind of thing comes from. Â How do I override the settings in one of these files? Â None of them are marked config, so I guess I don't edit them. Â Are there other places such policy can be set? See man PolicyKit.conf The bigger issue is that much of the policy is not well documented, except in the XML files (which are pretty terse). -- Chris Adams cmad...@hiwaay.net Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Local users get to play root?
On 11/18/2009 01:19 PM, Konstantin Ryabitsev wrote: I may be wrong, but I understand that this behaviour of PackageKit only applies to users with direct console access (i.e. not remote shells). So, only users that are logged in via GDM or TTY would be able to perform such tasks. That's a silly thing to imply we can control. Just because firefox is running on a local console doesn't mean that a vulnerability therein has not allowed it to be ultimately controlled from elsewhere. --CJD -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: F12 checksum file says it is SHA1 but it is SHA256
On 11/19/2009 12:54 AM, Stefan Grosse wrote: Hi, the file Fedora-12-i386-CHECKSUM which is on the mirrors and included in the torrents says: Hash: SHA1 f0ad929cd259957e160ea442eb80986b5f01daaffdbcc7e5a1840a666c4447c7 *Fedora-12-i386-DVD.iso But the truth is that it is SHA256. (I downloaded the DVD twice because of this...) So maybe someone could change that if I am right? It is a SHA256 and the CHECKSUM file is gpg signed. SHA1 in the top indicates the hash of the gpg key and not the checksum file. Rahul -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Local users get to play root?
On 11/18/2009 02:32 PM, Casey Dahlin wrote: On 11/18/2009 01:19 PM, Konstantin Ryabitsev wrote: I may be wrong, but I understand that this behaviour of PackageKit only applies to users with direct console access (i.e. not remote shells). So, only users that are logged in via GDM or TTY would be able to perform such tasks. That's a silly thing to imply we can control. Just because firefox is running on a local console doesn't mean that a vulnerability therein has not allowed it to be ultimately controlled from elsewhere. --CJD Addendum: Why do you think sudo would ask an already-logged-in user for his password? --CJD -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: F12 checksum file says it is SHA1 but it is SHA256
On Wed, Nov 18, 2009 at 11:27, Rahul Sundaram sunda...@fedoraproject.orgwrote: On 11/19/2009 12:54 AM, Stefan Grosse wrote: Hi, the file Fedora-12-i386-CHECKSUM which is on the mirrors and included in the torrents says: Hash: SHA1 f0ad929cd259957e160ea442eb80986b5f01daaffdbcc7e5a1840a666c4447c7 *Fedora-12-i386-DVD.iso But the truth is that it is SHA256. (I downloaded the DVD twice because of this...) So maybe someone could change that if I am right? It is a SHA256 and the CHECKSUM file is gpg signed. SHA1 in the top indicates the hash of the gpg key and not the checksum file. Perhaps it could be made more clear. I almost made the same double download mistake. darrell -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Local users get to play root?
On 11/18/2009 02:29 PM, Richard Hughes wrote: 2009/11/18 nodata l...@nodata.co.uk: You install software with a known buffer overflow before it is fixed and exploit it. More software = more chances to exploit. Bingo! Why would the additional package start extra services? I thought there were guidelines about that. Anyway, if the user has physical access to the machine, there are many quicker ways to root the box in question. (Like rebooting, and using grub to go to runlevel 1) Richard. What if they don't? The mechanisms by which we are detecting and proving physical access are easily circumvented. If the buffer overflow allows arbitrary code execution, you need only an open(/dev/console, ...) to fool a lot of these mechanisms. Just because a program is interactive on a console does not mean that that's the /only/ place its being controlled from. --CJD -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: F12 checksum file says it is SHA1 but it is SHA256
On 11/19/2009 01:06 AM, darrell pfeifer wrote: Perhaps it could be made more clear. I almost made the same double download mistake. Jesse Keating on fedora-test list indicated earlier that he will fix this for Fedora 13. Not sure what could be done to clarify this. The instructions are at https://fedoraproject.org/en/verify Rahul -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Local users get to play root?
Am 2009-11-18 20:35, schrieb Matthew Garrett: On Wed, Nov 18, 2009 at 07:42:51PM +0100, nodata wrote: Err no. Admins trusts software he has chosen to install from the repo. I definitely don't want a user configuring an ftp server or running anything with a cronjob on a server I look after. Why do users have local access to your server? Remote access won't grant you the appropriate authentication for this. The real question, the point of all of this discussion, is a key piece of knowledge about how Linux works (root decides system wide) is now changed. The person who wants to make that change must justify it, now the other way round. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Local users get to play root?
On Wed, 2009-11-18 at 12:26 -0700, Bob Arendt wrote: I haven't tried .. but does this this also include the capability for my grade-school child to *remove* software using their account? Like gcc? glibc? gdm? All fun activities ... No thank-deity at least remove seem not to be permitted by default. Simo. -- Simo Sorce * Red Hat, Inc * New York -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Local users get to play root?
2009/11/18 Casey Dahlin cdah...@redhat.com: I may be wrong, but I understand that this behaviour of PackageKit only applies to users with direct console access (i.e. not remote shells). So, only users that are logged in via GDM or TTY would be able to perform such tasks. That's a silly thing to imply we can control. Just because firefox is running on a local console doesn't mean that a vulnerability therein has not allowed it to be ultimately controlled from elsewhere. Okay, so someone managed to get local shell via firefox. How does installing trusted packages further their nefarious purposes? Addendum: Why do you think sudo would ask an already-logged-in user for his password? Because sudo doesn't use policykit? Because sudo gives you full root access -- not just ability to install trusted software from trusted repositories? Moreover, even sudo doesn't ask me again if I invoke it within 5 minutes of using it (or however long it is). Regards, -- McGill University IT Security Konstantin Ryabitsev Montréal, Québec -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Local users get to play root?
On Wed, 2009-11-18 at 14:29 -0500, Seth Vidal wrote: On Wed, 18 Nov 2009, Richard Hughes wrote: 2009/11/18 Andrew Haley a...@redhat.com: Is there some way to disable PackageKit but keep setroubleshoot? Just set all the policykit answers to no. You'll find more than just setroubleshoot breaks if you do this. How do you do this? Set the policykit answers to no? The atom-bomb approach is to change everything in /usr/share/polkit-1/actions/ to allow_activeno/allow_active and allow_inactiveno/allow_inactive. But that's not right because those files aren't config files. Instead, you drop local authority files in /var/lib/polkit-1/localauthority/ that override those permissions on a site-by-site basis for your specific use-case, irregardless of what the defaults are. Dan -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Local users get to play root?
On Wed, Nov 18, 2009 at 19:20:42 +, Richard Hughes hughsi...@gmail.com wrote: 2009/11/18 Casey Dahlin cdah...@redhat.com: By the admin's first opportunity to change the settings the box could already be rooted. I'm not sure how you can root a computer from installing signed content by a user that already has physical access to the machine. The person may not intentionally be attacking the machine, they may just install something that is vulnerable without the approval of the administrator. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Local users get to play root?
On Wed, 2009-11-18 at 20:34 +0100, nodata wrote: If the servers are in locked racks and you require a reboot to get access to a grub prompt which is not password protected, then the outage would trip the monitoring system. The server is in a locked rack, but the console access to the server isn't? How far down the strawman path are where? -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating signature.asc Description: This is a digitally signed message part -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Local users get to play root?
On 11/18/2009 02:44 PM, Konstantin Ryabitsev wrote: 2009/11/18 Casey Dahlin cdah...@redhat.com: I may be wrong, but I understand that this behaviour of PackageKit only applies to users with direct console access (i.e. not remote shells). So, only users that are logged in via GDM or TTY would be able to perform such tasks. That's a silly thing to imply we can control. Just because firefox is running on a local console doesn't mean that a vulnerability therein has not allowed it to be ultimately controlled from elsewhere. Okay, so someone managed to get local shell via firefox. How does installing trusted packages further their nefarious purposes? Addendum: Why do you think sudo would ask an already-logged-in user for his password? Because sudo doesn't use policykit? Because sudo gives you full root access -- not just ability to install trusted software from trusted repositories? Moreover, even sudo doesn't ask me again if I invoke it within 5 minutes of using it (or however long it is). Regards, But why is it neccesary? That was more my point. The answer is: because being associated with a login on the local console doesn't verify that it is a /user/ in control. --CJD -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Local users get to play root?
On Wed, Nov 18, 2009 at 13:31:49 -0600, Chris Adams cmad...@hiwaay.net wrote: (what is pulse/proximity-helper? why is nspluginwrapper/plugin-config setuid root?) I already filed a bug (491543) about that. It does bad things, but the maintainer doesn't seem to want to change it. Firefox reenables disabled plugins. So you pretty much have to uninstall any that you don't want it to use. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Local users get to play root?
On Thu, 2009-11-19 at 00:34 +0530, Rahul Sundaram wrote: On 11/19/2009 12:31 AM, nodata wrote: Rahul, it seems to be that the person who made this change (fesco approved?) is the one who should answer why the change is a good thing, rather than oh I changed it, now tell me why it's bad. Do you know who it was? I don't see why FESCo should be involved and I have no idea who made this decision. I would have preferred the change to be announced and documented in detail regardless of that. I assume David Zeuthen? (CC'ed) Jeez, Rahul. This has nothing to do with polkit per se, only PackageKit and how it decides to use polkit. I've commented that much in the bug. And as noted in the bug I don't even agree there's a problem. But I leave that to Richard and others to sort out. Btw, please don't add me to the Cc again like this or reply to this - I'm not interested in this bike-shed or what color it is. Thanks. David -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Local users get to play root?
On Wed, Nov 18, 2009 at 14:44:20 -0500, Konstantin Ryabitsev i...@fedoraproject.org wrote: Okay, so someone managed to get local shell via firefox. How does installing trusted packages further their nefarious purposes? There are nuances to trust. Just because you trust a repository to not intentionally provide tampered packages, doesn't mean you want to trust specific packages. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Local users get to play root?
On 11/19/2009 01:26 AM, David Zeuthen wrote: On Thu, 2009-11-19 at 00:34 +0530, Rahul Sundaram wrote: On 11/19/2009 12:31 AM, nodata wrote: Rahul, it seems to be that the person who made this change (fesco approved?) is the one who should answer why the change is a good thing, rather than oh I changed it, now tell me why it's bad. Do you know who it was? I don't see why FESCo should be involved and I have no idea who made this decision. I would have preferred the change to be announced and documented in detail regardless of that. I assume David Zeuthen? (CC'ed) Jeez, Rahul. This has nothing to do with polkit per se, only PackageKit and how it decides to use polkit. Well, your reaction sounds like, everybody is expected to know this automatically. It is clear to me, that is not the case. So let's not overreact. Rahul -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Local users get to play root?
On Wed, Nov 18, 2009 at 11:18:28PM +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. They can install a package with a known local root exploit? They can install lots of packages are fill up all the disk space? They can install commands that the owner of the machine doesn't want? Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones New in Fedora 11: Fedora Windows cross-compiler. Compile Windows programs, test, and build Windows installers. Over 70 libraries supprt'd http://fedoraproject.org/wiki/MinGW http://www.annexia.org/fedora_mingw -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Local users get to play root?
Or even .. They become a Fedora packager, they put a backdoor into a Fedora package (which is very discrete and is only triggered when $hostname = $targethost), and they install that. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones New in Fedora 11: Fedora Windows cross-compiler. Compile Windows programs, test, and build Windows installers. Over 70 libraries supprt'd http://fedoraproject.org/wiki/MinGW http://www.annexia.org/fedora_mingw -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Local users get to play root?
On 11/18/2009 01:52 PM, nodata wrote: Am 2009-11-18 19:50, schrieb Tony Nelson: On 09-11-18 13:44:43, nodata wrote: Am 2009-11-18 19:16, schrieb Bruno Wolff III: On Wed, Nov 18, 2009 at 17:45:26 +, Bastien Nocerabnoc...@redhat.com wrote: Once we get the new user management stuff into F13 [1], we'd probably tighten that rule so that only admins are given the option, or all users but with the need to authenticate as an admin. This seems pretty reasonable. I don't like the way Fedora is going with this: digging out something that works and saying we'll replace it later makes no sense. Make it work now, or *keep it in*. Fedora has always been this way. Have you tried to use sound or video in the past few releases? I think it's called creative destruction. and ripping out the boot log for several releases... that was the opposite of helpful. Please do try and stay on topic. This is an entirely unrelated problem which has been resolved. -- Peter Any connection between your reality and mine is purely coincidental. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Bug Triage workflow for F13 and beyond
Today we celebrate another successful Fedora release (F12), congratulations to everyone. Never one to sit still development has already begun on F13, and with it comes a new bug triage work flow. For bugs filed against F13(rawhide) and beyond the keyword Triaged will now be used to indicate that a bug report has been triaged. BugZappers will no longer change the bug state to ASSIGNED, that will now be left in the hands of the package maintainers. BugZappers will still be using the NEEDINFO flag and closing reports as duplicates. The wiki will soon be updated to reflect these changes. Steven = Steven M. Parrish - gpg fingerprint: 4B6C 8357 059E B7ED 8095 0FD6 1F4B EDA0 A9A6 13C0 http://tuxbrewr.fedorapeople.org/ IRC nick: SMParrish on irc.freenode.net Channels: #fedora-kde, #fedora-olpc, #sugar, #fedora-devel, and many more ___ Fedora-devel-announce mailing list fedora-devel-annou...@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-announce -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
CVS branches for F-10 closed
Hi All, Since Fedora 12 was released yesterday new CVS branches for F-10 will not be allowed. http://fedoraproject.org/wiki/PackageMaintainers/Policy/EOL list the policy in effect this means that F-10 is now in a maintenance only cycle, with EOL fast approaching, the EOL date was set to December 17th by FESCo (http://meetbot.fedoraproject.org/fedora-meeting/2009-11-06/fedora- meeting.2009-11-06-17.00.html). Dennis signature.asc Description: This is a digitally signed message part. ___ Fedora-devel-announce mailing list fedora-devel-annou...@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-announce-- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Bug zapper clears NEEDINFO
I received a couple of emails last night telling me that the NEEDINFO flag for two bugs assigned to me were cleared. Great, I though, finally I have the information I need to proceed on those bugs. Only there is no new information. The flag was cleared by Bug Zapper reminding the reporter that the bug was originally filed against F-10 and will be closed automatically in the near future. Should the NEEDINFO flag be cleared by adding such a comment? I didn't expect that. -- Jerry Insert obligatory Spanish Inquisition reference here James http://www.jamezone.org/ -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Local users get to play root?
2009/11/18 Casey Dahlin cdah...@redhat.com: Because sudo doesn't use policykit? Because sudo gives you full root access -- not just ability to install trusted software from trusted repositories? Moreover, even sudo doesn't ask me again if I invoke it within 5 minutes of using it (or however long it is). Regards, But why is it neccesary? That was more my point. The answer is: because being associated with a login on the local console doesn't verify that it is a /user/ in control. Yes, this is security trade-off -- and with valid arguments. Does it make sense to have this as a default configuration for a desktop-oriented distribution? Quite possibly. Fedora installations in managed environments have qualified sysadmins that can alter this policy -- but a user who installs Fedora at home will probably welcome not having to type in a root password when they want to install a gimp plugin. If experience with Vista has shown us anything, is that people absolutely hate when they have to make constant decisions about most minute details of their system's operation. I installing trusted software such minute operation? Perhaps. I'm just trying to point out that this is very, very far from OMG LOCAL ROOT FOR EVERYONE as implied in the original email. Regards, -- McGill University IT Security Konstantin Ryabitsev Montréal, Québec -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Local users get to play root?
(Thanks for a constructive discussion by the way!) David, added you to CC for a question below: On Wed, Nov 18, 2009 at 2:31 PM, Chris Adams cmad...@hiwaay.net wrote: I would agree with that, but it's not trivial. Are we just scoping in PackageKit here, or also consolehelper @console actions? Does it imply removing the setuid bit from /bin/ping? In an ideal world, everything that could grant elevated privilege would come without it, and the admin (or spin config files) could easily configure it back. Right. That obviously fails for things like /bin/ping, since that uses file permissions, and that's part of the RPM (and not configurable). However, ping has traditionally been run-able as a non-root user, and it is easily spotted with find. Right; I gave the specific example of ping because it's about the oldest most traditional Unix thing I could think of. The number of setuid programs is small these days, but several of them are now helpers that allow a wide-range of other programs access, again with minimal documentation (what is pulse/proximity-helper? why is nspluginwrapper/plugin-config setuid root?) Hm, this is off the top of my head, but I think the idea with nspluginwrapper is that you install the flash-plugin RPM (which has no idea about nspluginwrapper, and I think upstream is actively hostile to it actually), then restart firefox (as your user), but the installed flash plugin needs to be wrapped, so our firefox runs the setuid script to update the system plugin database. Not sure about proximity. Yes, we could clearly use more auditing here. I think anything that uses PolicyKit should ship with no elevated privileges by default, since it is configurable. So, that leaves us with the question of how to configure it for Fedora. A data point here is that the Fedora polkit package adds two Unix groups desktop_user_r and desktop_admin_r. However, it's unclear to me whether the expectation is that official Fedora consumables (i.e. desktop installer) would customize PolicyKit using these. David, what do you think about having Fedora RPMs have all defaults be no? And getting this change made upstream? We discussed this eariler, you replied here: http://www.redhat.com/archives/fedora-desktop-list/2007-August/msg00266.html Do you still advocate doing this is achieved simply by editing PolicyKit.conf in the %post of the live cd creator. It's that simple really. ? We need to have some story for this, otherwise it's really confusing to everyone, from developers to admins, see e.g.: http://www.redhat.com/archives/rhl-devel-list/2009-August/msg00578.html It would be nice to also get consolehelper, but that is more complicated. I thought that was on the way out (to be replaced by PolicyKit), but I see there are still a number of things that use it (looking at the F11 desktop I'm on right now). Yeah, converting system-config- is going to take some time. The bigger issue is that much of the policy is not well documented, except in the XML files (which are pretty terse). The individual actions aren't documented well enough? Or the 1,000 meter view of all of the installed actions on a default desktop? -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Bug zapper clears NEEDINFO
On Wed, Nov 18, 2009 at 1:07 PM, Jeff Spaleta jspal...@gmail.com wrote: when you set the needinfo flag did you set it such that anyone could clear it or did you specifically require that the original reporter needed to reply in the bugzilla interface? The needinfo flag will change state on the next comment by anyone if configured to do so when the flag is initially set. -jef D'oh! Now that I've bothered to go find the wiki page, I see that my mental model of the bug workflow fails to match reality in a couple of places. Sorry for the noise. -- Jerry James http://www.jamezone.org/ -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Local users get to play root?
Am 2009-11-18 21:02, schrieb Peter Jones: On 11/18/2009 01:52 PM, nodata wrote: Am 2009-11-18 19:50, schrieb Tony Nelson: On 09-11-18 13:44:43, nodata wrote: Am 2009-11-18 19:16, schrieb Bruno Wolff III: On Wed, Nov 18, 2009 at 17:45:26 +, Bastien Nocerabnoc...@redhat.comwrote: Once we get the new user management stuff into F13 [1], we'd probably tighten that rule so that only admins are given the option, or all users but with the need to authenticate as an admin. This seems pretty reasonable. I don't like the way Fedora is going with this: digging out something that works and saying we'll replace it later makes no sense. Make it work now, or *keep it in*. Fedora has always been this way. Have you tried to use sound or video in the past few releases? I think it's called creative destruction. and ripping out the boot log for several releases... that was the opposite of helpful. Please do try and stay on topic. This is an entirely unrelated problem which has been resolved. It's related because it's the same problem. In both cases functionality was missing before a suitable replacement was available. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Local users get to play root?
On Wed, Nov 18, 2009 at 3:20 PM, Jeff Spaleta jspal...@gmail.com wrote: I'm not sure enough sysadmins understand PolicyKit enough to confidently generate local policy edits. I think learning how to implement site specific PolicyKit best practises by modifying unwanted PackageKit's behavior is going to be a trial by fire introduction to PolicyKit policy editting for a lot of admins. We saw the same sort of learning curve frustration when hal policy was introduced that changed how hardware was handled. Having Yet Another access control system in HAL was precisely the reason PolicyKit was created, so administrators can have one place to find this stuff across the OS. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Local users get to play root?
Am 2009-11-18 21:20, schrieb Jeff Spaleta: On Wed, Nov 18, 2009 at 11:08 AM, Konstantin Ryabitsev i...@fedoraproject.org wrote: Yes, this is security trade-off -- and with valid arguments. Does it make sense to have this as a default configuration for a desktop-oriented distribution? Quite possibly. Fedora installations in managed environments have qualified sysadmins that can alter this policy -- I'm not sure enough sysadmins understand PolicyKit enough to confidently generate local policy edits. I think learning how to implement site specific PolicyKit best practises by modifying unwanted PackageKit's behavior is going to be a trial by fire introduction to PolicyKit policy editting for a lot of admins. We saw the same sort of learning curve frustration when hal policy was introduced that changed how hardware was handled. -jef I think this feature should have been a Feature along with the appropriate pros and cons and documentation. Instead we have a chorus of people saying just turn it off without anyone seemingly knowing the correct way of doing it. Maybe we need a firstboot question to determine profiles. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Local users get to play root?
2009/11/18 nodata l...@nodata.co.uk: Am 2009-11-18 20:20, schrieb Richard Hughes: 2009/11/18 Casey Dahlincdah...@redhat.com: By the admin's first opportunity to change the settings the box could already be rooted. I'm not sure how you can root a computer from installing signed content by a user that already has physical access to the machine. You install software with a known buffer overflow before it is fixed and exploit it. More software = more chances to exploit. Bingo! If a user logged in from a physical local console wanted to exploit their machine, this would be the hard way to do it. So here is what I've just gotten from talking to Ray Strode and reading docs. if you want to disable this just run: pklalockdown --lockdown org.freedesktop.packagekit.package-install that will keep anyone from installing pkgs w/o authenticating as admin. That's the short version. the long version I'm working on writing up right now. -sv -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Local users get to play root?
Once upon a time, Dan Williams d...@redhat.com said: But that's not right because those files aren't config files. Instead, you drop local authority files in /var/lib/polkit-1/localauthority/ that override those permissions on a site-by-site basis for your specific use-case, irregardless of what the defaults are. Um, what is /var/lib/polkit-1/localauthority/? Again, I'm still sitting at my F11 desktop; was this something added in F12? Maybe (as someone else mentioned) I am looking for the 1000 foot (or 305 meter) view. I understand setuid-root, setgid-foo, etc., and that is widely documented. I kind of have a grip on consolehelper, more from poking around at it than reading anything. I have no clue how things work with PolicyKit, and it also seems that PolicyKit is still changing how things are done from release to release. I poked at PolicyKit a little when someone pointed out desktop users were allowed to change the system clock a couple of releases ago. Some of the same discussion happened then as is happening now; I made the same suggestion about no elevated access by default and spins can override. The clock perms finally changed in F12 (although it looks like users can still change the timezone, which is still not a good idea, as most things like cron and syslog use local time), and now we have PackageKit questions. It just seems like there needs to be: - better documentation - better defaults - better Fedora policy - better oversight (or enforcement, if necessary) about PolicyKit (or anything that can give regular users elevated access) rules and actions. -- Chris Adams cmad...@hiwaay.net Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Local users get to play root?
On Wed, 2009-11-18 at 10:53 -0900, Jeff Spaleta wrote: On Wed, Nov 18, 2009 at 10:45 AM, Dan Williams d...@redhat.com wrote: But that's not right because those files aren't config files. Instead, you drop local authority files in /var/lib/polkit-1/localauthority/ that override those permissions on a site-by-site basis for your specific use-case, irregardless of what the defaults are. Beyond the issue of what is and what is not the appropriate default at install time..which is already a difficult issue to talk through. I think there is an education gap here about how to competently admin PolicyKit based activities which adds frustration. -jefold dogs...new tricksspaleta That often happens with new software. The trikiest part is finding the proper documentation. man 8 polkit seems like a very good starting point. -- Jesse Keating RHCE (http://jkeating.livejournal.com) Fedora Project (http://fedoraproject.org/wiki/JesseKeating) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) identi.ca (http://identi.ca/jkeating) signature.asc Description: This is a digitally signed message part -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Local users get to play root?
On Wed, Nov 18, 2009 at 11:25 AM, Colin Walters walt...@verbum.org wrote: Having Yet Another access control system in HAL was precisely the reason PolicyKit was created, so administrators can have one place to find this stuff across the OS. Doesn't mean meathead sysadmins like me actually understand how to interact with it, -jefking of the meatheadsspaleta -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Local users get to play root?
Am 2009-11-18 20:50, schrieb Jesse Keating: On Wed, 2009-11-18 at 20:34 +0100, nodata wrote: If the servers are in locked racks and you require a reboot to get access to a grub prompt which is not password protected, then the outage would trip the monitoring system. The server is in a locked rack, but the console access to the server isn't? How far down the strawman path are where? huh? All servers are in locked racks, with a few KVM terminals. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Local users get to play root?
Am 2009-11-18 21:27, schrieb Seth Vidal: 2009/11/18 nodata l...@nodata.co.uk: Am 2009-11-18 20:20, schrieb Richard Hughes: 2009/11/18 Casey Dahlincdah...@redhat.com: By the admin's first opportunity to change the settings the box could already be rooted. I'm not sure how you can root a computer from installing signed content by a user that already has physical access to the machine. You install software with a known buffer overflow before it is fixed and exploit it. More software = more chances to exploit. Bingo! If a user logged in from a physical local console wanted to exploit their machine, this would be the hard way to do it. So here is what I've just gotten from talking to Ray Strode and reading docs. if you want to disable this just run: pklalockdown --lockdown org.freedesktop.packagekit.package-install that will keep anyone from installing pkgs w/o authenticating as admin. That's the short version. the long version I'm working on writing up right now. -sv Thanks for this. Does this need to be run as root? :) -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Local users get to play root?
On Wed, 18 Nov 2009, nodata wrote: Am 2009-11-18 21:27, schrieb Seth Vidal: 2009/11/18 nodata l...@nodata.co.uk: Am 2009-11-18 20:20, schrieb Richard Hughes: 2009/11/18 Casey Dahlincdah...@redhat.com: By the admin's first opportunity to change the settings the box could already be rooted. I'm not sure how you can root a computer from installing signed content by a user that already has physical access to the machine. You install software with a known buffer overflow before it is fixed and exploit it. More software = more chances to exploit. Bingo! If a user logged in from a physical local console wanted to exploit their machine, this would be the hard way to do it. So here is what I've just gotten from talking to Ray Strode and reading docs. if you want to disable this just run: pklalockdown --lockdown org.freedesktop.packagekit.package-install that will keep anyone from installing pkgs w/o authenticating as admin. That's the short version. the long version I'm working on writing up right now. -sv Thanks for this. Does this need to be run as root? :) yes :) -sv -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Local users get to play root?
On Wed, 2009-11-18 at 21:28 +0100, nodata wrote: Am 2009-11-18 20:50, schrieb Jesse Keating: On Wed, 2009-11-18 at 20:34 +0100, nodata wrote: If the servers are in locked racks and you require a reboot to get access to a grub prompt which is not password protected, then the outage would trip the monitoring system. The server is in a locked rack, but the console access to the server isn't? How far down the strawman path are where? huh? All servers are in locked racks, with a few KVM terminals. The places I've cared about security of the systems wouldn't allow anybody without a key to our rack to access the console. You'd have to unlock the rack in order to access the KVM or to plug anything into the machines. -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating signature.asc Description: This is a digitally signed message part -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Local users get to play root?
On 11/18/2009 03:24 PM, nodata wrote: Am 2009-11-18 21:02, schrieb Peter Jones: On 11/18/2009 01:52 PM, nodata wrote: Am 2009-11-18 19:50, schrieb Tony Nelson: On 09-11-18 13:44:43, nodata wrote: Am 2009-11-18 19:16, schrieb Bruno Wolff III: On Wed, Nov 18, 2009 at 17:45:26 +, Bastien Nocerabnoc...@redhat.comwrote: Once we get the new user management stuff into F13 [1], we'd probably tighten that rule so that only admins are given the option, or all users but with the need to authenticate as an admin. This seems pretty reasonable. I don't like the way Fedora is going with this: digging out something that works and saying we'll replace it later makes no sense. Make it work now, or *keep it in*. Fedora has always been this way. Have you tried to use sound or video in the past few releases? I think it's called creative destruction. and ripping out the boot log for several releases... that was the opposite of helpful. Please do try and stay on topic. This is an entirely unrelated problem which has been resolved. It's related because it's the same problem. In both cases functionality was missing before a suitable replacement was available. Related to the topic is not the same as on topic. -- Peter Any connection between your reality and mine is purely coincidental. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Local users get to play root?
Am 2009-11-18 21:27, schrieb nodata: Am 2009-11-18 21:20, schrieb Jeff Spaleta: On Wed, Nov 18, 2009 at 11:08 AM, Konstantin Ryabitsev i...@fedoraproject.org wrote: Yes, this is security trade-off -- and with valid arguments. Does it make sense to have this as a default configuration for a desktop-oriented distribution? Quite possibly. Fedora installations in managed environments have qualified sysadmins that can alter this policy -- I'm not sure enough sysadmins understand PolicyKit enough to confidently generate local policy edits. I think learning how to implement site specific PolicyKit best practises by modifying unwanted PackageKit's behavior is going to be a trial by fire introduction to PolicyKit policy editting for a lot of admins. We saw the same sort of learning curve frustration when hal policy was introduced that changed how hardware was handled. -jef I think this feature should have been a Feature along with the appropriate pros and cons and documentation. Instead we have a chorus of people saying just turn it off without anyone seemingly knowing the correct way of doing it. Maybe we need a firstboot question to determine profiles. and a tool to switch a box between different profiles/roles too. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Local users get to play root?
Once upon a time, Colin Walters walt...@verbum.org said: (Thanks for a constructive discussion by the way!) No problem; I'm trying to understand and help things move forward. I don't want to see another thing like SELinux or PulseAudio where it becomes common knowledge that you should just disable or remove something. So, that leaves us with the question of how to configure it for Fedora. A data point here is that the Fedora polkit package adds two Unix groups desktop_user_r and desktop_admin_r. However, it's unclear to me whether the expectation is that official Fedora consumables (i.e. desktop installer) would customize PolicyKit using these. Where are those documented? I guess that's something new for F12, so maybe there's something there. However, I just searched the Fedora wiki and got no hits (if this is Fedora-specific, shouldn't it be there?). The bigger issue is that much of the policy is not well documented, except in the XML files (which are pretty terse). The individual actions aren't documented well enough? Or the 1,000 meter view of all of the installed actions on a default desktop? I guess some of both. At a quick glance, I see over 100 actions on my F11 desktop (in over 1400 lines of XML, not counting langauges); how am I supposed to be knowledgeable enough to know which of those I may want (or need) to change for certain situations? Don't get me wrong; I do like having more fine-grained access control. What would be nice would be a guide of how all this fits together and when to change what (not just documentation of individual options or syntax), but I do also understand that developers don't always like writing documentation (hey, who does, other than tech writers!). -- Chris Adams cmad...@hiwaay.net Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Local users get to play root?
On Wed, 2009-11-18 at 14:39 -0600, Chris Adams wrote: What would be nice would be a guide of how all this fits together and when to change what (not just documentation of individual options or syntax), but I do also understand that developers don't always like writing documentation (hey, who does, other than tech writers!). In this case we do have some documentation. man 8 polkit looks to be a great read for getting your head around this stuff. Unfortunately you need to be on an F12 box (or chroot) to run that, although the man page may be on the web somewhere. -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating signature.asc Description: This is a digitally signed message part -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Local users get to play root?
On Wed, 18 Nov 2009, Seth Vidal wrote: 2009/11/18 nodata l...@nodata.co.uk: Am 2009-11-18 20:20, schrieb Richard Hughes: 2009/11/18 Casey Dahlincdah...@redhat.com: By the admin's first opportunity to change the settings the box could already be rooted. I'm not sure how you can root a computer from installing signed content by a user that already has physical access to the machine. You install software with a known buffer overflow before it is fixed and exploit it. More software = more chances to exploit. Bingo! If a user logged in from a physical local console wanted to exploit their machine, this would be the hard way to do it. So here is what I've just gotten from talking to Ray Strode and reading docs. if you want to disable this just run: pklalockdown --lockdown org.freedesktop.packagekit.package-install that will keep anyone from installing pkgs w/o authenticating as admin. That's the short version. the long version I'm working on writing up right now. longer version w/some more details: http://skvidal.wordpress.com/2009/11/18/polkit-and-package-kit-and-changing-settings/ -sv -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Local users get to play root?
On Wed, 18 Nov 2009, Dan Williams wrote: On Wed, 2009-11-18 at 14:29 -0500, Seth Vidal wrote: On Wed, 18 Nov 2009, Richard Hughes wrote: 2009/11/18 Andrew Haley a...@redhat.com: Is there some way to disable PackageKit but keep setroubleshoot? Just set all the policykit answers to no. You'll find more than just setroubleshoot breaks if you do this. How do you do this? Set the policykit answers to no? The atom-bomb approach is to change everything in /usr/share/polkit-1/actions/ to allow_activeno/allow_active and allow_inactiveno/allow_inactive. But that's not right because those files aren't config files. Instead, you drop local authority files in /var/lib/polkit-1/localauthority/ that override those permissions on a site-by-site basis for your specific use-case, irregardless of what the defaults are. To be fair - it took 2 engineers about 30-40 minutes and looking through the code to figure out what was wanted in those files and then how to verify what was in there. it resulted in: http://skvidal.wordpress.com/2009/11/18/polkit-and-package-kit-and-changing-settings/ but the manpages do not make it obvious. nor is it obvious why those files are in /var/lib/ -sv -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Local users get to play root?
On Wed, 18 Nov 2009, Jesse Keating wrote: On Wed, 2009-11-18 at 14:39 -0600, Chris Adams wrote: What would be nice would be a guide of how all this fits together and when to change what (not just documentation of individual options or syntax), but I do also understand that developers don't always like writing documentation (hey, who does, other than tech writers!). In this case we do have some documentation. man 8 polkit looks to be a great read for getting your head around this stuff. Unfortunately you need to be on an F12 box (or chroot) to run that, although the man page may be on the web somewhere. polkit man page tells you a lot - but it's not going to help a sysadmin configure something TODAY. FAQs and HOWTOs will do that. -sv -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Local users get to play root?
On 11/18/2009 03:27 PM, Seth Vidal wrote: 2009/11/18 nodata l...@nodata.co.uk: Am 2009-11-18 20:20, schrieb Richard Hughes: 2009/11/18 Casey Dahlincdah...@redhat.com: By the admin's first opportunity to change the settings the box could already be rooted. I'm not sure how you can root a computer from installing signed content by a user that already has physical access to the machine. You install software with a known buffer overflow before it is fixed and exploit it. More software = more chances to exploit. Bingo! If a user logged in from a physical local console wanted to exploit their machine, this would be the hard way to do it. So here is what I've just gotten from talking to Ray Strode and reading docs. if you want to disable this just run: pklalockdown --lockdown org.freedesktop.packagekit.package-install that will keep anyone from installing pkgs w/o authenticating as admin. That's the short version. the long version I'm working on writing up right now. -sv Thanks for this Seth TK009 -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Bug zapper clears NEEDINFO
Dne 18.11.2009 21:07, Jeff Spaleta napsal(a): On Wed, Nov 18, 2009 at 11:03 AM, Jerry James loganje...@gmail.com wrote: Should the NEEDINFO flag be cleared by adding such a comment? I didn't expect that. when you set the needinfo flag did you set it such that anyone could clear it or did you specifically require that the original reporter needed to reply in the bugzilla interface? But to be fait. Bugzappers should be conscious of this and careful not to liquidate needinfo by mistake, even when it was set incorrectly. Matěj -- http://www.ceplovi.cz/matej/, Jabber: mceplatceplovi.cz GPG Finger: 89EF 4BC6 288A BF43 1BAB 25C3 E09F EF25 D964 84AC Of course I'm respectable. I'm old. Politicians, ugly buildings, and whores all get respectable if they last long enough. --John Huston in Chinatown. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Local users get to play root?
On Wednesday 18 November 2009 01:35:30 pm Simo Sorce wrote: On Wed, 2009-11-18 at 13:23 -0500, Seth Vidal wrote: I'm not sure how this is 'surprise root'. IT will only allow installs of pkgs signed with a key you trust from a repo you've setup. which pretty much means: if the admin trusts the repo, then it is okay. if the admin doesn't trust the repo it should NOT be on the box and enabled b/c an untrusted repo can nuke your entire world. I may trust the repo, that doesn't mean I want to allow installation of any package that happens to live on that repo. I agree with this sentiment. It would be a huge surprise for setuid apps to suddenly start showing up on boxes. The problem is the *Default* not the fact that you can consciously allow users to update without a password. And I wonder what the audit trail will show? Does it show which user installed these packages? -Steve -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Local users get to play root?
2009/11/18 Steve Grubb sgr...@redhat.com: And I wonder what the audit trail will show? Does it show which user installed these packages? Yup, take a look at pkcon get-transactions or just use gpk-log to see it graphically. Richard. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Local users get to play root?
On 11/18/2009 03:06 PM, Peter Jones wrote: On 11/18/2009 02:35 PM, Casey Dahlin wrote: On 11/18/2009 02:32 PM, Casey Dahlin wrote: On 11/18/2009 01:19 PM, Konstantin Ryabitsev wrote: I may be wrong, but I understand that this behaviour of PackageKit only applies to users with direct console access (i.e. not remote shells). So, only users that are logged in via GDM or TTY would be able to perform such tasks. That's a silly thing to imply we can control. Just because firefox is running on a local console doesn't mean that a vulnerability therein has not allowed it to be ultimately controlled from elsewhere. --CJD Addendum: Why do you think sudo would ask an already-logged-in user for his password? Because the config file says to. Good sort of answer when speaking about chickens and roads. A bit too existential for system administration though. --CJD -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Local users get to play root?
Am 2009-11-18 22:08, schrieb Richard Hughes: 2009/11/18 Steve Grubbsgr...@redhat.com: And I wonder what the audit trail will show? Does it show which user installed these packages? Yup, take a look at pkcon get-transactions or just use gpk-log to see it graphically. Richard. This should be logged where everything else is logged. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Local users get to play root?
Sorry, but this default (desktop users can install pkgs without root) is just stupid. It is antithetical to all standard security models that have come before in Fedora and other Linux distributions. Instead of shielding yourselves with silly arguments about the lack of lock-and-key on a desktop machine, ask yourself how many decades-old assumptions you are wiping in one fell swoop. It's no excuse to give viruses, pranksters and other vectors easy access to Fedora. Even Microsoft Windows asks for elevated privileges for this sort of thing! This is just shameful. Jeff -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Local users get to play root?
On 11/18/2009 12:45 PM, Bastien Nocera wrote: On Wed, 2009-11-18 at 18:08 +0100, nodata wrote: Yikes! When was it decided that non-root users get to play root? Ref: https://bugzilla.redhat.com/show_bug.cgi?id=534047 This is horrible! Seems fair as the default for a desktop installation. Once we get the new user management stuff into F13 [1], we'd probably tighten that rule so that only admins are given the option, or all users but with the need to authenticate as an admin. No, the sane security answer is to least privileges as-is (require root) until your new user management stuff is ready. Re-read your own post, and realize you proposed: FC1+: secure F12: insecure F13+ secure again This is a hugely inconsistent security policy, a special case that administrators must un-learn and re-learn as they go through Fedora versions. Jeff -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Local users get to play root?
On 11/18/2009 01:04 PM, Seth Vidal wrote: On Wed, 18 Nov 2009, Jon Ciesla wrote: Seth Vidal wrote: You have PackageKit installed on servers? really? I do if it's in the default DVD install, or was pulled in in an upgrade. I've never intentionally installed it, and yes I do. Never imagined it would be a problem. I'll remove it. Maybe you and I have a different concept of 'Servers'. But I tend to install @core only and then remove items whenever I can for a server. This sounds like a tacit admission that the default install for servers is bloody stupid (== same as desktop), unless the admin REMOVES packages we helpfully installed on the server system. Does that sound like good engineering to you? Sorry, this new policy is wildly inconsistent, a special case that will change in F13, we are told. It is wholly different from the entire history of Linux distributions. Jeff -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Local users get to play root?
On Wed, 18 Nov 2009, Jeff Garzik wrote: On 11/18/2009 01:04 PM, Seth Vidal wrote: On Wed, 18 Nov 2009, Jon Ciesla wrote: Seth Vidal wrote: You have PackageKit installed on servers? really? I do if it's in the default DVD install, or was pulled in in an upgrade. I've never intentionally installed it, and yes I do. Never imagined it would be a problem. I'll remove it. Maybe you and I have a different concept of 'Servers'. But I tend to install @core only and then remove items whenever I can for a server. This sounds like a tacit admission that the default install for servers is bloody stupid (== same as desktop), unless the admin REMOVES packages we helpfully installed on the server system. Does that sound like good engineering to you? Sorry, this new policy is wildly inconsistent, a special case that will change in F13, we are told. It is wholly different from the entire history of Linux distributions. @core doesn't contain anything like that: http://fpaste.org/Bk9t/ I said I do remove items from @core that I don't need. It was my way of saying servers should have as little as possible on them. -sv -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Local users get to play root?
On 11/18/2009 01:28 PM, Seth Vidal wrote: I didn't say it did - I said it didn't make sense to have items like PK on servers. Listen to yourself. The above is a blatant admission that it is REALLY EASY for existing users to upgrade themselves into a security nightmare. * F11 w/ PK: requires root * F12 w/ PK: does not require root And you don't see any problem with this? Jeff -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: A silly question about our FC tag
On Tue, 17 Nov 2009 07:18:27 -0800, Jesse wrote:
If we did a macro change in dist-f13 and a mass rebuild, and did a macro
change on dist-f12 and dist-f11 at the same time (without a mass
rebuild) this might work.
Only with severe discipline by all packagers who push updates to
multiple branches.
The X%{?dist}.Y scenario is affected, too, for example:
$ rpmdev-vercmp 0 1.0 3.fc12.10 1.0 3.f12.2
0:1.0-3.fc12.1 is newer
Plus: Changing %dist would open the door for new cvs/koji tags that could
be created without bumping the rest of %release, creating package EVRs
which lose version comparison. Also in Obsoletes/Conflicts/Requires -- and
since %dist is appended to %release, we do have %dist in those tags if
packagers used %release in them.
I'm not sure I like dist value changing on a
released Fedora though.
If there were an automated sanity check somewhere as part of the pkg
release procedure, that might help. It would enforce proper %release
bumps.
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Local users get to play root?
On Wed, 18 Nov 2009, Jeff Garzik wrote: On 11/18/2009 01:28 PM, Seth Vidal wrote: I didn't say it did - I said it didn't make sense to have items like PK on servers. Listen to yourself. The above is a blatant admission that it is REALLY EASY for existing users to upgrade themselves into a security nightmare. * F11 w/ PK: requires root * F12 w/ PK: does not require root And you don't see any problem with this? you're talking to the wrong guy. I don't maintain PK. I don't work on PK. I don't have anything to do with it, in fact. And you should listen to yourself. I'm saying: You want to run secure servers, then you have to know what's on the system. Not just what pkg, but what the pkg does. This is why I said: It doesn't make sense to have programs like packagekit which are targeted at end users on servers. -sv -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Local users get to play root?
On Wed, 18 Nov 2009, Jeff Garzik wrote: On 11/18/2009 01:28 PM, Seth Vidal wrote: I didn't say it did - I said it didn't make sense to have items like PK on servers. Listen to yourself. The above is a blatant admission that it is REALLY EASY for existing users to upgrade themselves into a security nightmare. * F11 w/ PK: requires root * F12 w/ PK: does not require root And you don't see any problem with this? I can invent problems with this if I want to. But I suspect that when F13 comes out, people will look back on F12 and find PK more usable not less secure even though it is technically both. -Mike -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Local users get to play root?
On 11/18/2009 01:23 PM, Seth Vidal wrote: On Wed, 18 Nov 2009, nodata wrote: Am 2009-11-18 19:18, schrieb Colin Walters: This is a major change. I vote for secure by default. If the admin wishes this surprise-root feature to be enabled he can enable it. I'm not sure how this is 'surprise root'. IT will only allow installs of pkgs signed with a key you trust from a repo you've setup. which pretty much means: if the admin trusts the repo, then it is okay. if the admin doesn't trust the repo it should NOT be on the box and enabled b/c an untrusted repo can nuke your entire world. By your own adminssion, we are talking about DESKTOP USERS. How little social engineering + virus automation does it take to get such an install to include a malicious 3rd party repo? Jeff -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Local users get to play root?
On Wed, 2009-11-18 at 16:04 -0500, Steve Grubb wrote: The problem is the *Default* not the fact that you can consciously allow users to update without a password. And I wonder what the audit trail will show? Does it show which user installed these packages? PK has it's own logging, it logs the user the API is running from there. But it doesn't set loginuid, so yum history, auditd, SELinux, etc. don't know. -- James Antill - ja...@fedoraproject.org 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@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Local users get to play root?
On Wed, 18 Nov 2009, Jeff Garzik wrote: On 11/18/2009 01:23 PM, Seth Vidal wrote: On Wed, 18 Nov 2009, nodata wrote: Am 2009-11-18 19:18, schrieb Colin Walters: This is a major change. I vote for secure by default. If the admin wishes this surprise-root feature to be enabled he can enable it. I'm not sure how this is 'surprise root'. IT will only allow installs of pkgs signed with a key you trust from a repo you've setup. which pretty much means: if the admin trusts the repo, then it is okay. if the admin doesn't trust the repo it should NOT be on the box and enabled b/c an untrusted repo can nuke your entire world. By your own adminssion, we are talking about DESKTOP USERS. How little social engineering + virus automation does it take to get such an install to include a malicious 3rd party repo? Not much. Jeff, I think you're misunderstanding, a lot, here. I'm not in favor of user-can-install-pkgs. I'm just explaining why I don't think pk should be on servers. -sv -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Local users get to play root?
On 11/18/2009 01:41 PM, Konstantin Ryabitsev wrote: 2009/11/18 Simo Sorcesso...@redhat.com: On Wed, 2009-11-18 at 13:19 -0500, Konstantin Ryabitsev wrote: This significantly limits the number of users with powers to install signed software -- almost to the point of where it sounds like a fair trade-off. If someone has physical access to the machine, then heck -- it's not like they don't already effectively own it. Most of my users wouldn't be able to own it even if I let a root shell open, but they would definitely be able to install or remove packages using the GUI. The difference is huge. If I have physical access to your machine, I'll own it. I may have to use tools to get to the HDD, but it's only a question of time and dedication. Now, there can be situations where someone has access to the TTY console or GDM (usually when it's a VM guest or a machine behind a network KVM), but most often, if someone can log in on the console, they are sitting in front of the physical box, to which they have full access. Console access is no excuse for a completely lax security policy. Didn't Microsoft Windows teach us all that? In the real world(tm), hacking via console access still means there are a lot of hurdles you must dodge, like making noise while opening the case. This new policy completely screws multi-user setups where (for example) kids are given a login to play games -- but I sure don't want them to be installing packages. Now, pkgs installs for them are trivial. The physical argument by policy proponents is the real straw man: F12+PK lowers the security barrier from difficult to a simple mouse click. Jeff -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Local users get to play root?
On 11/18/2009 02:26 PM, Bob Arendt wrote: On 11/18/09 12:03, Konstantin Ryabitsev wrote: 2009/11/18 Simo Sorcesso...@redhat.com: If I have physical access to your machine, I'll own it. I may have to use tools to get to the HDD, but it's only a question of time and dedication. *you* are not one of my users, and this has nothing to do with *you* hacking in my machine. If I have physical access to a machine I do not even care about what's installed on it. In 99% of the cases I will just be able to boot from a live cd. That's a completely different issue. Well, then we're violently agreeing about the same thing. Anyway. It doesn't look like this is a change in Fedora policy, because it clearly caught everyone off-guard. Looks like PK developer made an executive decision and it's up to us to either issue an update to revert to the previous behaviour, or to continue debating whether allowing local console users to install trusted software from trusted repositories is a sane security trade-off. I haven't tried .. but does this this also include the capability for my grade-school child to *remove* software using their account? Like gcc? glibc? gdm? All fun activities ... They sure can install all the naughty software you've forbidden on that machine. Jeff -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Local users get to play root?
On 11/18/2009 02:53 PM, Casey Dahlin wrote: The answer is: because being associated with a login on the local console doesn't verify that it is a /user/ in control. Bingo. I guess everyone else missed that day in Security 101 class. Jeff -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Local users get to play root?
On 11/18/2009 03:25 PM, Colin Walters wrote: On Wed, Nov 18, 2009 at 3:20 PM, Jeff Spaletajspal...@gmail.com wrote: I'm not sure enough sysadmins understand PolicyKit enough to confidently generate local policy edits. I think learning how to implement site specific PolicyKit best practises by modifying unwanted PackageKit's behavior is going to be a trial by fire introduction to PolicyKit policy editting for a lot of admins. We saw the same sort of learning curve frustration when hal policy was introduced that changed how hardware was handled. Having Yet Another access control system in HAL was precisely the reason PolicyKit was created, so administrators can have one place to find this stuff across the OS. Rather irrelevant to our current problem, unfortunately. Admins will upgrade to F12 not knowning that PK policy defaults have changed. They will upgrade into insecurity. Jeff -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Local users get to play root?
On 11/18/2009 04:34 PM, Seth Vidal wrote: I said I do remove items from @core that I don't need. It was my way of saying servers should have as little as possible on them. You keep repeating this, as if your personal actions and situation are relevant. How many existing installs out there have PK, and will get upgraded into insecurity? How many admins will even known about this new F12 policy when they install? At a minimum there should have been a big flashing warning in F12 release notes, employing the blink tag, at the very top about this security change. Jeff -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Local users get to play root?
2009/11/18 Jeff Garzik jgar...@pobox.com: How little social engineering + virus automation does it take to get such an install to include a malicious 3rd party repo? You need the root password to install from repos not signed by a key previously imported, or if the package signature is wrong. Richard. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Local users get to play root?
On 11/18/2009 04:46 PM, Seth Vidal wrote: Jeff, I think you're misunderstanding, a lot, here. I'm not in favor of user-can-install-pkgs. I'm just explaining why I don't think pk should be on servers. PK will be on F12 servers, because of upgrades and very poor communication of this new policy. That is the reality of the situation. /should/ is not relevant at all here. Jeff -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Local users get to play root?
On Wed, 18 Nov 2009, Jeff Garzik wrote: On 11/18/2009 04:46 PM, Seth Vidal wrote: Jeff, I think you're misunderstanding, a lot, here. I'm not in favor of user-can-install-pkgs. I'm just explaining why I don't think pk should be on servers. PK will be on F12 servers, because of upgrades and very poor communication of this new policy. That is the reality of the situation. /should/ is not relevant at all here. It is for purposes of me stating my opinion, which is all I've been saying this whole time. -sv -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Local users get to play root?
On 11/18/2009 05:14 PM, Richard Hughes wrote: 2009/11/18 Jeff Garzikjgar...@pobox.com: How little social engineering + virus automation does it take to get such an install to include a malicious 3rd party repo? You need the root password to install from repos not signed by a key previously imported, or if the package signature is wrong. You forget we have botnets doing distributed cracking now. Fedora just opened up a huge attack vector, for the users who are least equipped to understand the consequences. And this enormous security hole of a policy change was done with next to /zero/ communication, making it likely that many admins will not even know they are vulnerable until their kids install a bunch of unwanted packages. Jeff -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Local users get to play root?
On 11/18/2009 04:10 PM, Casey Dahlin wrote: On 11/18/2009 03:06 PM, Peter Jones wrote: On 11/18/2009 02:35 PM, Casey Dahlin wrote: On 11/18/2009 02:32 PM, Casey Dahlin wrote: On 11/18/2009 01:19 PM, Konstantin Ryabitsev wrote: I may be wrong, but I understand that this behaviour of PackageKit only applies to users with direct console access (i.e. not remote shells). So, only users that are logged in via GDM or TTY would be able to perform such tasks. That's a silly thing to imply we can control. Just because firefox is running on a local console doesn't mean that a vulnerability therein has not allowed it to be ultimately controlled from elsewhere. --CJD Addendum: Why do you think sudo would ask an already-logged-in user for his password? Because the config file says to. Good sort of answer when speaking about chickens and roads. A bit too existential for system administration though. You've sortof missed my point here, which isn't a big surprise since I left a lot of space to figure it out in. root added your name to /etc/sudoers. She might have put: cjd ALL=(ALL) NOPASSWD:ALL but apparently instead she put: cjd ALL=(ALL) ALL If sudo is asking you for a password, it's because somebody intentionally made a choice for it to do so, in the config file. It's not some kind of accident. It's not some global policy because of a universal truth, as you seem to think. It's a choice somebody made when they put your name in there. (Read what you will as to how this is relevant to our current predicament.) -- Peter Computers don't make errors. What they do, they do on purpose. -- Dale -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Local users get to play root?
On Wed, 2009-11-18 at 13:22 -0500, Simo Sorce wrote: I would almost consider it a security vulnerability and ask for a CVE to be issued. It certainly seems like an easy path to a denial of service: just install everything and run the machine out of disk space. Tim. */ signature.asc Description: This is a digitally signed message part -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Local users get to play root?
On Wed, Nov 18, 2009 at 5:18 PM, Jeff Garzik jgar...@pobox.com wrote: You forget we have botnets doing distributed cracking now. But...if you've cracked the root password, there are rather easier (and less audited) routes to trojaning the system than adding a third party yum repository and downloading your malicious RPM. And this enormous security hole of a policy change was done with next to /zero/ communication, making it likely that many admins will not even know they are vulnerable until their kids install a bunch of unwanted packages. I think you are correct that the change could have been documented better. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Local users get to play root?
2009/11/18 Jeff Garzik jgar...@pobox.com: And this enormous security hole of a policy change was done with next to /zero/ communication, making it likely that many admins will not even know they are vulnerable until their kids install a bunch of unwanted packages. F11 had retained authorisations, which arguably were more of a security weakness. If rawhide had been signed during the F12 cycle everybody would have seen this change much earlier. If you're deploying F12, then I really think you should know the basics about PolicyKit. Richard. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Local users get to play root?
On Wed, 18 Nov 2009, Richard Hughes wrote: 2009/11/18 Jeff Garzik jgar...@pobox.com: And this enormous security hole of a policy change was done with next to /zero/ communication, making it likely that many admins will not even know they are vulnerable until their kids install a bunch of unwanted packages. F11 had retained authorisations, which arguably were more of a security weakness. If rawhide had been signed during the F12 cycle everybody would have seen this change much earlier. If you're deploying F12, then I really think you should know the basics about PolicyKit. Richard, to be fair, when I asked you how to edit a .pkla file you couldn't tell me. So, if our engineers don't know the basics, how should our users? -sv -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Local users get to play root?
2009/11/18 Seth Vidal skvi...@fedoraproject.org: Richard, to be fair, when I asked you how to edit a .pkla file you couldn't tell me. So, if our engineers don't know the basics, how should our users? Fair comment. Release notes additions might be good in this regard. Richard. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Local users get to play root?
On Wed, 2009-11-18 at 10:52 -0800, Jesse Keating wrote: On Wed, 2009-11-18 at 13:22 -0500, James Antill wrote: 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. Right, PK is counting on this being sufficiently difficult enough to prevent bad things from happening. While I'd like to think that, and would like to say that, I can't. I do not see how that's relevant, frankly. For it to be relevant it would have to be true to state that, if you need root privileges to install signed packages, it's absolutely no problem if a signed package is evil. Obviously, that's not at all true. An evil 'trusted' package would be a Very Bad Thing in any case. Whether you need to be root to install a trusted package or not is entirely orthogonal, as far as I can see. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Local users get to play root?
On Wed, Nov 18, 2009 at 10:36:20PM +, Tim Waugh wrote: On Wed, 2009-11-18 at 13:22 -0500, Simo Sorce wrote: I would almost consider it a security vulnerability and ask for a CVE to be issued. It certainly seems like an easy path to a denial of service: just install everything and run the machine out of disk space. org.freedesktop.packagekit.system-network-proxy-configure also seems scary to me. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Local users get to play root?
On Wed, 2009-11-18 at 14:49 -0800, Adam Williamson wrote: On Wed, 2009-11-18 at 10:52 -0800, Jesse Keating wrote: On Wed, 2009-11-18 at 13:22 -0500, James Antill wrote: 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. Right, PK is counting on this being sufficiently difficult enough to prevent bad things from happening. While I'd like to think that, and would like to say that, I can't. I do not see how that's relevant, frankly. For it to be relevant it would have to be true to state that, if you need root privileges to install signed packages, it's absolutely no problem if a signed package is evil. Obviously, that's not at all true. An evil 'trusted' package would be a Very Bad Thing in any case. Whether you need to be root to install a trusted package or not is entirely orthogonal, as far as I can see. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net I'd like to point out that there are trusted packages that I wouldn't want my users downloading. John is a good example but there are others. Anyone requested that CVE yet? --Eric signature.asc Description: This is a digitally signed message part -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Local users get to play root?
On 11/19/2009 04:19 AM, Richard Hughes wrote: 2009/11/18 Seth Vidal skvi...@fedoraproject.org: Richard, to be fair, when I asked you how to edit a .pkla file you couldn't tell me. So, if our engineers don't know the basics, how should our users? Fair comment. Release notes additions might be good in this regard. It should have been announced and documented with the rationale for the change *before* the release. Just pretending that everyone should know about how PolicyKit works when documentation is just lacking doesn't cut it. You didn't even respond to by bugzilla comment and just closed the bug. We will still do a post-release update for the release notes now but that's scrambling to minimize damage. Rahul -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Local users get to play root?
On Wed, 2009-11-18 at 20:00 +, Richard W.M. Jones wrote: They can install lots of packages are fill up all the disk space? Has someone checked yet whether this is actually possible? There are nuances here. It depends whether PackageKit is capable of using up the space reserved for root when installing packages or not. Even if it's operating 'as root', it doesn't necessarily follow that it can, as I understand it. Please check this before asserting it. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Local users get to play root?
On 11/18/2009 05:36 PM, Colin Walters wrote: On Wed, Nov 18, 2009 at 5:18 PM, Jeff Garzikjgar...@pobox.com wrote: You forget we have botnets doing distributed cracking now. But...if you've cracked the root password, there are rather easier (and less audited) routes to trojaning the system than adding a third party yum repository and downloading your malicious RPM. I am talking about cracking signing keys, not root passwords. Jeff -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Local users get to play root?
On Wed, 2009-11-18 at 17:54 -0500, Eric Christensen wrote: I do not see how that's relevant, frankly. For it to be relevant it would have to be true to state that, if you need root privileges to install signed packages, it's absolutely no problem if a signed package is evil. Obviously, that's not at all true. An evil 'trusted' package would be a Very Bad Thing in any case. Whether you need to be root to install a trusted package or not is entirely orthogonal, as far as I can see. I'd like to point out that there are trusted packages that I wouldn't want my users downloading. John is a good example but there are others. Anyone requested that CVE yet? That's a different point, and specifically _not_ the point I was addressing. You don't need to point it out as it's already been pointed out about five times earlier in the thread. :) -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Local users get to play root?
On 11/18/2009 05:38 PM, Richard Hughes wrote: If you're deploying F12, then I really think you should know the basics about PolicyKit. should? The F12 security policy is dumbed down to make life easier for users, making it easier for them to get by with -less- knowledge. And yet you claim that education bar should be HIGHER than F10/F11? That is unrealistic. Jeff -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Local users get to play root?
Adam Williamson awill...@redhat.com writes: I do not see how that's relevant, frankly. For it to be relevant it would have to be true to state that, if you need root privileges to install signed packages, it's absolutely no problem if a signed package is evil. Obviously, that's not at all true. An evil 'trusted' package would be a Very Bad Thing in any case. Whether you need to be root to install a trusted package or not is entirely orthogonal, as far as I can see. Really? You are talking about changing the local administrator trusts *this* package to the local administrator trusts whoever has the signing key for Fedora to decide which packages should be installed. -- Arnaud -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: A silly question about our FC tag
On Wed, 2009-11-18 at 22:37 +0100, Michael Schwendt wrote: If there were an automated sanity check somewhere as part of the pkg release procedure, that might help. It would enforce proper %release bumps. That is coming with AutoQA and it will certainly be able to find upgrade-path issues. -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating signature.asc Description: This is a digitally signed message part -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Local users get to play root?
On 11/18/2009 05:51 PM, Rahul Sundaram wrote: On 11/19/2009 04:19 AM, Richard Hughes wrote: 2009/11/18 Seth Vidalskvi...@fedoraproject.org: Richard, to be fair, when I asked you how to edit a .pkla file you couldn't tell me. So, if our engineers don't know the basics, how should our users? Fair comment. Release notes additions might be good in this regard. It should have been announced and documented with the rationale for the change *before* the release. Just pretending that everyone should know about how PolicyKit works when documentation is just lacking doesn't cut it. You didn't even respond to by bugzilla comment and just closed the Agreed 100.1%. bug. We will still do a post-release update for the release notes now but that's scrambling to minimize damage. The only thing that will fix the damage is to update PK, reverting the default-insecure policy. May I remind folks that it is easy to UPGRADE INTO INSECURITY here. Admins with servers, coming from F10/F11, can very easily fall into this trap simply by updating their current systems. Jeff -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Local users get to play root?
On Wed, 2009-11-18 at 18:03 -0500, Jeff Garzik wrote: On 11/18/2009 05:51 PM, Rahul Sundaram wrote: On 11/19/2009 04:19 AM, Richard Hughes wrote: 2009/11/18 Seth Vidalskvi...@fedoraproject.org: Richard, to be fair, when I asked you how to edit a .pkla file you couldn't tell me. So, if our engineers don't know the basics, how should our users? Fair comment. Release notes additions might be good in this regard. It should have been announced and documented with the rationale for the change *before* the release. Just pretending that everyone should know about how PolicyKit works when documentation is just lacking doesn't cut it. You didn't even respond to by bugzilla comment and just closed the Agreed 100.1%. bug. We will still do a post-release update for the release notes now but that's scrambling to minimize damage. The only thing that will fix the damage is to update PK, reverting the default-insecure policy. May I remind folks that it is easy to UPGRADE INTO INSECURITY here. Admins with servers, coming from F10/F11, can very easily fall into this trap simply by updating their current systems. Jeff Has anyone drafted a notice to go out on the Announce List explaining this vulnerability? If admins don't know to fix/remove PK then they are putting their systems at risk. --Eric signature.asc Description: This is a digitally signed message part -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
