Re: Lower Process Capabilities
On Wed, Jul 29, 2009 at 9:32 AM, Stephen Smalleys...@tycho.nsa.gov wrote: If you want something more akin to privilege bracketing within a program, then a closer analog in SELinux would be setcon(3) to switch to a more restricted domain. But in general our goal is to enforce security goals at the system level and not depend on the correctness of the application to shed privilege. [snip] But then, of course, we depend on the correctness of the system to deny privileges. Considering the number of users that disable SELinux entirely— this surely can't be counted on. And the historic number of applications which fail to shed privilege (to the limited extents possible) shows that depending on the application also isn't a complete solution. It seems to me that the approaches could be complimentary— It would be very nice if applications could drop any SELinux controlled privileged at runtime, either temporarily or permanently. This would not replace the system level protection but would supplement it by remaining active even if the wider protection were partially disabled, by offering finer granularity, and by giving developers a greater opportunity to participate in the use of SELinux (perhaps resulting in more applications being structured in SELinux friendly ways). Capabilities are agreed to be far too coarse, and they only subset root when we really want to subset user permissions too. SELinux provides many nice hooks. Developers would like to right software that remains as secure as possible even if a user has goofed up the file permissions. Is there no possible improvement here? -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Lower Process Capabilities
On Mon, Aug 3, 2009 at 12:38 PM, Till Maasopensou...@till.name wrote: $ sudo -i sudo: /etc/sudoers is mode 00, should be 0440 sudo: no valid sudoers sources found, quitting This is sudo checking the permissions of it's own sudoers file. Since they aren't what it expects, it bails. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Lower Process Capabilities
On Thu, 2009-08-13 at 21:27 -0400, Steve Grubb wrote: On Thursday 13 August 2009 05:53:37 pm John Poelstra wrote: Can you update the feature page to reflect the reduced scope of the feature and its completion percentage? All I see since FESCo met was the change to the detailed description related to the permissions. That *is* the reduction in scope - other than what I have time to actually work on. If I can fix dhcp, that is a major win. That is the item that stands out as the biggest problem when running netcap. Steve: With my paranoid/QA hat on, I think the How to Test section needs some more items. It covers testing that each specific change being made works as expected, but it doesn't also cover testing that there weren't unexpected side effects. I added some questions to this end to the discussion page: https://fedoraproject.org/wiki/Talk:Features/LowerProcessCapabilities Hope this is helpful Dave -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Lower Process Capabilities
Quoting Steve Grubb (sgr...@redhat.com): On Sunday 26 July 2009 07:32:36 pm Steve Grubb wrote: What can be done is that we program the application to drop some of the capabilities so that its not all powerful. There's just one flaw in this plan. The directory for /bin is 0755 root root. So, even if we drop all capabilities, the root acct can still trojan a system. If we change the bin directory to 005, then root cannot write to that directory unless it has the CAP_DAC_OVERRIDE capability. The idea with this project is to not allow network facing or daemons have CAP_DAC_OVERRIDE, but to only allow it from logins or su/sudo. As discussed at the Fesco meeting last week, the lower process capabilities project is going to reduce the scope of this part of the proposal. At this point, we are going to tighten up perms on the directories in $PATH, /lib[64], /boot, and /root. A sample srpm can be found here for anyone wanting to try it out before alpha is unfrozen. http://people.redhat.com/sgrubb/files/filesystem-2.4.24-1.fc12.src.rpm Any feedback would be appreciated. Hi Steve, downloading and looking at filesystem.spec in the above rpm, I don't see any special treatment for boot, root, or /lib Is the right rpm at that link? If so, then I must be misunderstanding - can you give me a diff or something to explain how it's supposed to work? thanks, -serge -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Lower Process Capabilities
On Thursday 13 August 2009 05:53:37 pm John Poelstra wrote: Can you update the feature page to reflect the reduced scope of the feature and its completion percentage? All I see since FESCo met was the change to the detailed description related to the permissions. That *is* the reduction in scope - other than what I have time to actually work on. If I can fix dhcp, that is a major win. That is the item that stands out as the biggest problem when running netcap. -Steve -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Lower Process Capabilities
On 31/07/09 01:09, Matthew Woehlke wrote: Bill McGonigle wrote: What's it going to take to make most people who shut off SELinux stop doing that? ...being able to install bleeding-edge devel KDE to /usr/local/my-kde-install and be able to use that as my primary desktop. I guess that would - at best - take some kind of smart auto-labeling on the first exec of an unlabeled process. Could probably be done by using file context equivalence and a restorecon run after the build completes: # semanage fcontext -a -e /usr /usr/local/my-kde-install # restorecon -rvF /usr/local/my-kde-install http://danwalsh.livejournal.com/27571.html Paul. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Lower Process Capabilities
On 08/05/2009 08:02 AM, Paul Howarth wrote: http://danwalsh.livejournal.com/27571.html This is really nice. To partially answer my own question, Dan keeps coming up with great stuff that seems essential for average admins to maintain an SELinux box. -Bill -- Bill McGonigle, Owner Work: 603.448.4440 BFC Computing, LLC Home: 603.448.1668 http://www.bfccomputing.com/Cell: 603.252.2606 Twitter, etc.: bill_mcgonigle Page: 603.442.1833 Email, IM, VOIP: b...@bfccomputing.com Blog: http://blog.bfccomputing.com/ VCard: http://bfccomputing.com/vcard/bill.vcf -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Lower Process Capabilities
Bill McGonigle wrote: What's it going to take to make most people who shut off SELinux stop doing that? ...being able to install bleeding-edge devel KDE to /usr/local/my-kde-install and be able to use that as my primary desktop. I guess that would - at best - take some kind of smart auto-labeling on the first exec of an unlabeled process. -- Matthew Please do not quote my e-mail address unobfuscated in message bodies. -- Disadvantage: Bad Puns [-5] You constantly utter puns so egregious as to cause mental distress to anyone hearing them. This can, however, be used to distract enemies. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Lower Process Capabilities
On Tue, 2009-07-28 at 20:13 -0500, Serge E. Hallyn wrote: Quoting Bill McGonigle (b...@bfccomputing.com): On 07/28/2009 04:11 PM, Chris Adams wrote: Still, is such a change less severe than changing what root means? Is Fedora that committed to SELinux? What's it going to take to make most people who shut off SELinux stop doing that? Moving to heavier exploitation of capabilities doesn't mean stop using SELinux. Any more than finding and fixing buffer overflows should only be done if we want to turn off selinux. Well, it isn't quite the same thing. Assignment of capabilities to specific processes running specific binaries is something that SELinux can already do via Type Enforcement. And preventing a uid 0 process from writing to system files is likewise something that SELinux can already do via Type Enforcement. So I think the only piece of the proposal that is orthogonal to SELinux is privilege bracketing within the program (dropping caps after use). But the changes to the file and directory permissions seem more questionable. -- Stephen Smalley National Security Agency -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Lower Process Capabilities
On Tue, 2009-07-28 at 17:53 -0400, Bill McGonigle wrote: On 07/28/2009 04:11 PM, Chris Adams wrote: AFAIK SELinux introduces additional controls and does not replace or override existing controls. I'm pretty sure non-root still can't directly listen on a low-numbered port. For some reason I thought it was possible with MAC, but I can't find anything to support that. I might have been thinking of Solaris privileges. There was a patch floated on selinux list circa June 2007 that would have allowed SELinux to directly grant capabilities. But it met a certain amount of resistance from people concerned about the implications of changing the historical position that SELinux only further restricts access and about how to handle states like permissive mode, selinux-disabled, etc seamlessly. http://marc.info/?l=selinuxm=118159187318524w=2 http://marc.info/?l=selinuxm=118192327422630w=2 http://marc.info/?l=selinuxm=118191791828777w=2 -- Stephen Smalley National Security Agency -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Lower Process Capabilities
On Wed, 29 Jul 2009, Stephen Smalley wrote: So I think the only piece of the proposal that is orthogonal to SELinux is privilege bracketing within the program (dropping caps after use). But the changes to the file and directory permissions seem more questionable. Once we have access control on policy itself, we may be able to provide an API where an application can toggle a boolean on itself, e.g. to perform one action with broader permissions, then switch to a tighter set of permissions. This might be implementable in a way which also prevents applications from ever gaining more permissions (via typebounds). - James -- James Morris jmor...@namei.org -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Lower Process Capabilities
On Wed, 2009-07-29 at 23:01 +1000, James Morris wrote: On Wed, 29 Jul 2009, Stephen Smalley wrote: So I think the only piece of the proposal that is orthogonal to SELinux is privilege bracketing within the program (dropping caps after use). But the changes to the file and directory permissions seem more questionable. Once we have access control on policy itself, we may be able to provide an API where an application can toggle a boolean on itself, e.g. to perform one action with broader permissions, then switch to a tighter set of permissions. This might be implementable in a way which also prevents applications from ever gaining more permissions (via typebounds). We can actually already apply fine-grained access control on temporary changes to booleans - just specify a distinct label for the boolean in policy (via genfscon selinuxfs entries) and then control who can write to that file type. However, note that such changes affect all processes running in a given domain, so it isn't precisely the same thing as process privilege bracketing. -- Stephen Smalley National Security Agency -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Lower Process Capabilities
On Wed, 2009-07-29 at 09:10 -0400, Stephen Smalley wrote: On Wed, 2009-07-29 at 23:01 +1000, James Morris wrote: On Wed, 29 Jul 2009, Stephen Smalley wrote: So I think the only piece of the proposal that is orthogonal to SELinux is privilege bracketing within the program (dropping caps after use). But the changes to the file and directory permissions seem more questionable. Once we have access control on policy itself, we may be able to provide an API where an application can toggle a boolean on itself, e.g. to perform one action with broader permissions, then switch to a tighter set of permissions. This might be implementable in a way which also prevents applications from ever gaining more permissions (via typebounds). We can actually already apply fine-grained access control on temporary changes to booleans - just specify a distinct label for the boolean in policy (via genfscon selinuxfs entries) and then control who can write to that file type. However, note that such changes affect all processes running in a given domain, so it isn't precisely the same thing as process privilege bracketing. If you want something more akin to privilege bracketing within a program, then a closer analog in SELinux would be setcon(3) to switch to a more restricted domain. But in general our goal is to enforce security goals at the system level and not depend on the correctness of the application to shed privilege. -- Stephen Smalley National Security Agency -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Lower Process Capabilities
Quoting Stephen Smalley (s...@tycho.nsa.gov): On Tue, 2009-07-28 at 17:53 -0400, Bill McGonigle wrote: On 07/28/2009 04:11 PM, Chris Adams wrote: AFAIK SELinux introduces additional controls and does not replace or override existing controls. I'm pretty sure non-root still can't directly listen on a low-numbered port. For some reason I thought it was possible with MAC, but I can't find anything to support that. I might have been thinking of Solaris privileges. There was a patch floated on selinux list circa June 2007 that would have allowed SELinux to directly grant capabilities. But it met a certain amount of resistance from people concerned about the implications of changing the historical position that SELinux only further restricts access and about how to handle states like permissive mode, selinux-disabled, etc seamlessly. http://marc.info/?l=selinuxm=118159187318524w=2 http://marc.info/?l=selinuxm=118192327422630w=2 http://marc.info/?l=selinuxm=118191791828777w=2 I suppose the main problem with relying on this for granting privilege to system processes would be that if the selinux policy wasn't loaded for some reason, such processes (sshd, login, ...) would fail. The same thing can happen at the moment with capabilities for an NFS rootfs, so perhaps the same solution (falling back to classic setuid if there is no selinux policy loaded) could apply? -serge -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Lower Process Capabilities
On Wednesday 29 July 2009 09:49:29 am Serge E. Hallyn wrote: There was a patch floated on selinux list circa June 2007 that would have allowed SELinux to directly grant capabilities. But it met a certain amount of resistance from people concerned about the implications of changing the historical position that SELinux only further restricts access and about how to handle states like permissive mode, selinux-disabled, etc seamlessly. http://marc.info/?l=selinuxm=118159187318524w=2 http://marc.info/?l=selinuxm=118192327422630w=2 http://marc.info/?l=selinuxm=118191791828777w=2 I suppose the main problem with relying on this for granting privilege to system processes would be that if the selinux policy wasn't loaded for some reason, such processes (sshd, login, ...) would fail. There is also the argument that what we've been teaching people for years is that SE Linux strips away privileges and doesn't grant them. Changing the model would be somewhat confusing. -Steve -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Lower Process Capabilities
On Jul 29, 2009, at 8:49 AM, Serge E. Hallyn wrote: The same thing can happen at the moment with capabilities for an NFS rootfs, prelink killed file caps on fedora last time I checked. Makes them useless for general purpose app protection. https://bugzilla.redhat.com/show_bug.cgi?id=456105 joe so perhaps the same solution (falling back to classic setuid if there is no selinux policy loaded) could apply? -serge -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Lower Process Capabilities
On 07/29/2009 10:06 AM, Steve Grubb wrote: There is also the argument that what we've been teaching people for years is that SE Linux strips away privileges and doesn't grant them. Changing the model would be somewhat confusing. Just to play the devil's hair-splitting advocate, if the kernel were enforcing less and SELinux were enforcing more, the SElinux model wouldn't have changed, 'just' the kernel's. Certainly there's a good forty years of expectation about what the kernel will enforce, though I'm not sure that's important if SELinux is preventing unwanted access. Thanks for the mailing list links from '07, those made for good reading. I think the vision of SELinux in Fedora has alot to say about what the right options are. Will Fedora ever get to the point where advice to turn off SELinux is as verboten as suggesting to chmod -R 777 to solve a problem? That is, if we can guarantee that SELinux is enforcing, a whole different set of options is open that don't exist if SELinux is an optional bolt-on. Tangentially, has anybody attempted a statistical analysis tool to gather data from systems running in permissive mode to look for policy holes, ala smolt? -Bill -- Bill McGonigle, Owner Work: 603.448.4440 BFC Computing, LLC Home: 603.448.1668 http://www.bfccomputing.com/Cell: 603.252.2606 Twitter, etc.: bill_mcgonigle Page: 603.442.1833 Email, IM, VOIP: b...@bfccomputing.com Blog: http://blog.bfccomputing.com/ VCard: http://bfccomputing.com/vcard/bill.vcf -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Lower Process Capabilities
On 07/26/2009 07:32 PM, Steve Grubb wrote: If we change the bin directory to 005, then root cannot write to that directory unless it has the CAP_DAC_OVERRIDE capability. The idea with this project is to not allow network facing or daemons have CAP_DAC_OVERRIDE, but to only allow it from logins or su/sudo. What mechanism do you use to segregate things like yum-cron that do automatic security updates? Doesn't SELinux already support allowing non-root users to have access to low-numbered ports? There's also authbind and packet mangling. We have rsyslog rules for logfile writing now. Isn't it simpler to aim for not running daemons as root rather than redefining what root means? -Bill -- Bill McGonigle, Owner Work: 603.448.4440 BFC Computing, LLC Home: 603.448.1668 http://www.bfccomputing.com/Cell: 603.252.2606 Twitter, etc.: bill_mcgonigle Page: 603.442.1833 Email, IM, VOIP: b...@bfccomputing.com Blog: http://blog.bfccomputing.com/ VCard: http://bfccomputing.com/vcard/bill.vcf -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Lower Process Capabilities
Once upon a time, Bill McGonigle b...@bfccomputing.com said: Doesn't SELinux already support allowing non-root users to have access to low-numbered ports? AFAIK SELinux introduces additional controls and does not replace or override existing controls. I'm pretty sure non-root still can't directly listen on a low-numbered port. -- 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: Lower Process Capabilities
On 07/28/2009 04:11 PM, Chris Adams wrote: AFAIK SELinux introduces additional controls and does not replace or override existing controls. I'm pretty sure non-root still can't directly listen on a low-numbered port. For some reason I thought it was possible with MAC, but I can't find anything to support that. I might have been thinking of Solaris privileges. One simple alternative, sure to be unpopular with many, would be to patch the kernel to skip the low-numbered-port enforcement if SELinux is running in enforcing mode, and ship policies that do the right thing. Admins would have to purposely cripple their policies to make this insecure. However, init scripts would all have to become selinux savvy and know how to launch with the old model, which may be too tall an order. It also makes permissive mode more treacherous. Still, is such a change less severe than changing what root means? Is Fedora that committed to SELinux? What's it going to take to make most people who shut off SELinux stop doing that? -Bill -- Bill McGonigle, Owner Work: 603.448.4440 BFC Computing, LLC Home: 603.448.1668 http://www.bfccomputing.com/Cell: 603.252.2606 Twitter, etc.: bill_mcgonigle Page: 603.442.1833 Email, IM, VOIP: b...@bfccomputing.com Blog: http://blog.bfccomputing.com/ VCard: http://bfccomputing.com/vcard/bill.vcf -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Lower Process Capabilities
On Tue, Jul 28, 2009 at 17:53:53 -0400, Bill McGonigle b...@bfccomputing.com wrote: One simple alternative, sure to be unpopular with many, would be to patch the kernel to skip the low-numbered-port enforcement if SELinux is running in enforcing mode, and ship policies that do the right thing. Admins would have to purposely cripple their policies to make this insecure. I think after the selinux involvement in the recent popularized kernel exploit, that isn't going to happen. Having enforcing mode do things you can't in permissive mode is dangerous. While xguest will probably stay, I don't think you'll see too many other cases where selinux will give you extra privileges. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Lower Process Capabilities
Quoting Bill McGonigle (b...@bfccomputing.com): On 07/28/2009 04:11 PM, Chris Adams wrote: Still, is such a change less severe than changing what root means? Is Fedora that committed to SELinux? What's it going to take to make most people who shut off SELinux stop doing that? Moving to heavier exploitation of capabilities doesn't mean stop using SELinux. Any more than finding and fixing buffer overflows should only be done if we want to turn off selinux. -serge -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Lower Process Capabilities
On Sun, 26 Jul 2009, Steve Grubb wrote: The basic idea goes something like this: We would like to do something to prevent priv escalation for processes running as root. For this example, lets take cupsd to be a good case in point. If the attacker can find a vuln with cupsd, then they can have root privs and all that goes with it. (SE Linux may prevent total compromise, but some people turn it off.) We should put effort into improving SELinux rather than papering things over with new or previously discarded security schemes. Capabilities are inherently problematic in that you can't meaningfully reason about overall system behavior with them. e.g. what does CAP_SYS_ADMIN actually mean? Here's where the symbol is found in the kernel source: http://www.cs.fsu.edu/~baker/devices/lxr/http/ident?i=CAP_SYS_ADMIN I challenge anyone to explain the boundary of privilege for any process which has this capability, and how the propagation of that privilege is bounded within the system as a whole. We can do that with SELinux (in fact it's been somehwat designed for this purpose), and that's how we should approach the problem. - James -- James Morris jmor...@namei.org -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Lower Process Capabilities
Quoting Steve Grubb (sgr...@redhat.com): On Sunday 26 July 2009 08:54:26 pm Steve Grubb wrote: I trust you meant to write 0555? No, I really mean 005 so that root daemons are using public permissions. Admins of course have DAC_OVERRIDE and can do anything. Try the script in a VM and tell me if there are any problems you see. I should elaborate more. The issue is that sometimes there are secrets that root admins have access to that should not be available to semi-trusted daemons. For example, any private keys in /root or /etc. You do not want any daemon that could be compromised to have access to these. So, its safest just to set the permissions to 0005 so that they have no access to /root. But 0555 will also prevent root without CAP_DAC_OVERRIDE from writing, no? Using 0005 will mean root also needs CAP_DAC_OVERRIDE to read/execute, which seems a bit much. Suddenly it needs extra privilege if i just want it to be able to execute /bin/date. That actually seems less secure in any real system. I expect a few corner cases, but other than /etc/resolve.conf I don't know of any problems. -Steve -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Lower Process Capabilities
On Monday 27 July 2009 09:11:33 am Serge E. Hallyn wrote: Quoting Steve Grubb (sgr...@redhat.com): On Sunday 26 July 2009 08:54:26 pm Steve Grubb wrote: I trust you meant to write 0555? No, I really mean 005 so that root daemons are using public permissions. Admins of course have DAC_OVERRIDE and can do anything. Try the script in a VM and tell me if there are any problems you see. I should elaborate more. The issue is that sometimes there are secrets that root admins have access to that should not be available to semi-trusted daemons. For example, any private keys in /root or /etc. You do not want any daemon that could be compromised to have access to these. So, its safest just to set the permissions to 0005 so that they have no access to /root. But 0555 will also prevent root without CAP_DAC_OVERRIDE from writing, no? True. After some thought, I guess most secrets that a partially trusted root daemon may attempt to access would be in /root, /etc, /var, and /home. Perhaps those are the ones that need the extra tight permissions? Using 0005 will mean root also needs CAP_DAC_OVERRIDE to read/execute, which seems a bit much. Suddenly it needs extra privilege if i just want it to be able to execute /bin/date. That actually seems less secure in any real system. # ls -l /bin/date -rwxr-xr-x 1 root root 69296 2009-03-02 08:57 /bin/date The file is 0755 and therefore is executable by anyone. DAC_OVERRIDE is not needed for anything but writing to the file as in yum update. -Steve -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Lower Process Capabilities
On Mon, 2009-07-27 at 19:25 +1000, James Morris wrote: On Sun, 26 Jul 2009, Steve Grubb wrote: The basic idea goes something like this: We would like to do something to prevent priv escalation for processes running as root. For this example, lets take cupsd to be a good case in point. If the attacker can find a vuln with cupsd, then they can have root privs and all that goes with it. (SE Linux may prevent total compromise, but some people turn it off.) We should put effort into improving SELinux rather than papering things over with new or previously discarded security schemes. Capabilities are inherently problematic in that you can't meaningfully reason about overall system behavior with them. e.g. what does CAP_SYS_ADMIN actually mean? Here's where the symbol is found in the kernel source: http://www.cs.fsu.edu/~baker/devices/lxr/http/ident?i=CAP_SYS_ADMIN I challenge anyone to explain the boundary of privilege for any process which has this capability, and how the propagation of that privilege is bounded within the system as a whole. We can do that with SELinux (in fact it's been somehwat designed for this purpose), and that's how we should approach the problem. I agree with this, with some caveats. Capabilities are hard to reason about, and not just because they're coarse-grained. Practically speaking they don't get used, so kernel developers are careless about picking the right capable() check for a given action, since it ends up being a fancy way of checking current-euid. To pick a favorite example: CAP_SYS_RAWIO is documented to mean iopl, ioperm, and /dev/kcore. It actually means significantly more than that. It's effectively equivalent to root, though, because write access to /dev/kcore means you can change your uid. You might like it to mean can do raw I/O to peripherals like the name suggests, but the one most useful thing that could mean - r/w maps of PCI BARs - is covered under CAP_SYS_ADMIN instead. Which is not merely equivalent to root, but so coarse that it's basically useless. So it's hard for me to justify trying to make X use capabilities, since I'm not meaningfully limiting X's privileges in doing so. Caps are also wrong in that they're effectively a partitioning of root's privileges above those of a user. You would like the ability to do more than that. For example, you'd like to be able to remove your ability to clone() or exec(). SELinux can do this, kinda. And, of course, at an implementation level caps are just a dword bitmask, which is not nearly enough granularity. However, the inheritance model is _not_ hard to reason about. I find it slightly easier to understand than selinux transitions, in fact. And capabilities have the notable advantage of being something I can drop for myself when I don't need them, a safety model I'm used to from setuid. I would like to use SELinux as a defensive development practice, but I'm not aware of any good way to do so. All I have is the hope that the user is running with the policy enabled. - ajax 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: Lower Process Capabilities
On Mon, Jul 27, 2009 at 5:29 PM, Adam Jacksona...@redhat.com wrote: On Mon, 2009-07-27 at 19:25 +1000, James Morris wrote: On Sun, 26 Jul 2009, Steve Grubb wrote: The basic idea goes something like this: We would like to do something to prevent priv escalation for processes running as root. For this example, lets take cupsd to be a good case in point. If the attacker can find a vuln with cupsd, then they can have root privs and all that goes with it. (SE Linux may prevent total compromise, but some people turn it off.) We should put effort into improving SELinux rather than papering things over with new or previously discarded security schemes. Capabilities are inherently problematic in that you can't meaningfully reason about overall system behavior with them. e.g. what does CAP_SYS_ADMIN actually mean? Here's where the symbol is found in the kernel source: http://www.cs.fsu.edu/~baker/devices/lxr/http/ident?i=CAP_SYS_ADMIN I challenge anyone to explain the boundary of privilege for any process which has this capability, and how the propagation of that privilege is bounded within the system as a whole. We can do that with SELinux (in fact it's been somehwat designed for this purpose), and that's how we should approach the problem. I agree with this, with some caveats. Capabilities are hard to reason about, and not just because they're coarse-grained. Practically speaking they don't get used, so kernel developers are careless about picking the right capable() check for a given action, since it ends up being a fancy way of checking current-euid. To pick a favorite example: CAP_SYS_RAWIO is documented to mean iopl, ioperm, and /dev/kcore. It actually means significantly more than that. It's effectively equivalent to root, though, because write access to /dev/kcore means you can change your uid. You might like it to mean can do raw I/O to peripherals like the name suggests, but the one most useful thing that could mean - r/w maps of PCI BARs - is covered under CAP_SYS_ADMIN instead. Which is not merely equivalent to root, but so coarse that it's basically useless. So it's hard for me to justify trying to make X use capabilities, since I'm not meaningfully limiting X's privileges in doing so. Caps are also wrong in that they're effectively a partitioning of root's privileges above those of a user. You would like the ability to do more than that. For example, you'd like to be able to remove your ability to clone() or exec(). SELinux can do this, kinda. Put an example, thanks. And, of course, at an implementation level caps are just a dword bitmask, which is not nearly enough granularity. However, the inheritance model is _not_ hard to reason about. I find it slightly easier to understand than selinux transitions, in fact. And capabilities have the notable advantage of being something I can drop for myself when I don't need them, a safety model I'm used to from setuid. I would like to use SELinux as a defensive development practice, but I'm not aware of any good way to do so. All I have is the hope that the user is running with the policy enabled. - ajax -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Lower Process Capabilities
Hello,
I wanted to send an email to give everyone a heads up about a project I'm
working on. You can find the write-up here:
https://fedoraproject.org/wiki/Features/LowerProcessCapabilities
The basic idea goes something like this: We would like to do something to
prevent priv escalation for processes running as root. For this example, lets
take cupsd to be a good case in point. If the attacker can find a vuln with
cupsd, then they can have root privs and all that goes with it. (SE Linux may
prevent total compromise, but some people turn it off.)
What can be done is that we program the application to drop some of the
capabilities so that its not all powerful. There's just one flaw in this plan.
The directory for /bin is 0755 root root. So, even if we drop all
capabilities, the root acct can still trojan a system.
If we change the bin directory to 005, then root cannot write to that
directory unless it has the CAP_DAC_OVERRIDE capability. The idea with this
project is to not allow network facing or daemons have CAP_DAC_OVERRIDE, but
to only allow it from logins or su/sudo.
This will fundamentally change the permissions you see when doing ls -l, but
it will work as it always did for admins. If you wanted to test this out for
yourselves, you can setup a VM and run the following commands:
echo Hardening files...
find / -type f -perm /00700 -a -uid 0 -exec chmod u-wrx {} \; 2/dev/null
find / -type f -perm /00070 -a -gid 0 -exec chmod g-wrx {} \; 2/dev/null
echo Hardening directories...
find / -type d -perm /00200 -a -uid 0 -exec chmod u-w {} \; 2/dev/null
find / -type d -perm /00020 -a -gid 0 -exec chmod g-w {} \; 2/dev/null
echo Correcting a couple things...
find /sbin -type f -perm /0 -a -uid 0 -exec chmod u+x {} \; 2/dev/null
find /usr/sbin -type f -perm /0 -a -uid 0 -exec chmod u+x {} \; 2/dev/null
This project also plans to set the permissions for /etc/shadow and
/etc/gshadow to so that daemons running as root, but without DAC_OVERRIDE
cannot read the shadow file. Login, [gkx]dm, and sshd will still have
DAC_OVERRIDE or this wouldn't work.
Does a system running like this still work? Yes it does. But there is still
one rough spot. That is the /etc/resolve.conf file. The problem is that if we
follow the new theory of only allowing system updates with DAC_OVERRIDE, then
root daemons cannot update dynamically created files. The solution to this is
to move those into a directory owned by an account other than root and have
the daemon running under that account to write the file.
This would mean that anything that writes to /etc/resolve.conf, would need to
run under this new acct. And /etc/resolve.conf would need to be moved to
something like /etc/resolve/resolve.conf. And then that is symlinked back to
/etc/resolve.conf for the transition.
The last phase of the project is to play whack-a-mole and fix permission
problems in packages that specify file permissions explicitly. The plan is to
cover @core files first as I would like to make the minimal install work first
and then branch out to other use cases.
Asbestos underwear is firmly in place. Let me know if any one has concerns.
Also please try out the script above on a VM before posting so that you can
assure yourself that everything still works. :)
Thanks,
-Steve
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Lower Process Capabilities
Steve Grubb sgr...@redhat.com writes: The directory for /bin is 0755 root root. So, even if we drop all capabilities, the root acct can still trojan a system. If we change the bin directory to 005, then root cannot write to that directory unless it has the CAP_DAC_OVERRIDE capability. I trust you meant to write 0555? regards, tom lane -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Lower Process Capabilities
On Sunday 26 July 2009 08:38:45 pm Tom Lane wrote: Steve Grubb sgr...@redhat.com writes: The directory for /bin is 0755 root root. So, even if we drop all capabilities, the root acct can still trojan a system. If we change the bin directory to 005, then root cannot write to that directory unless it has the CAP_DAC_OVERRIDE capability. I trust you meant to write 0555? No, I really mean 005 so that root daemons are using public permissions. Admins of course have DAC_OVERRIDE and can do anything. Try the script in a VM and tell me if there are any problems you see. Thanks, -Steve -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Lower Process Capabilities
On Sunday 26 July 2009 08:54:26 pm Steve Grubb wrote: I trust you meant to write 0555? No, I really mean 005 so that root daemons are using public permissions. Admins of course have DAC_OVERRIDE and can do anything. Try the script in a VM and tell me if there are any problems you see. I should elaborate more. The issue is that sometimes there are secrets that root admins have access to that should not be available to semi-trusted daemons. For example, any private keys in /root or /etc. You do not want any daemon that could be compromised to have access to these. So, its safest just to set the permissions to 0005 so that they have no access to /root. I expect a few corner cases, but other than /etc/resolve.conf I don't know of any problems. -Steve -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Lower Process Capabilities
Steve Grubb sgr...@redhat.com writes: On Sunday 26 July 2009 08:38:45 pm Tom Lane wrote: I trust you meant to write 0555? No, I really mean 005 so that root daemons are using public permissions. What's the point? The most you will accomplish is to confuse people (and perhaps programs too). 0005 is certainly not meaningfully more secure than 0555. regards, tom lane -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Lower Process Capabilities
On Sunday 26 July 2009 09:01:14 pm Tom Lane wrote: 0005 is certainly not meaningfully more secure than 0555. There are some secrets in files that semi-trusted root apps should not have access to. -Steve -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
