Re: Lower Process Capabilities
Steve Grubb 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 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 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
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 -- 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
Quoting Steve Grubb (sgr...@redhat.com): > 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? Well 0555 vs. 0755 is already 'extra tight' for /bin itself, 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. > > # 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". But you said you were making /bin 0005, in which case users other than root could access /bin/date, but root itself could not without CAP_DAC_OVERRIDE (as tested by: mkdir delme chmod 005 delme ls delme Permission denied ) -serge -- 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 writes: > On Monday 27 July 2009 09:11:33 am Serge E. Hallyn wrote: >> 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". Are you deliberately misunderstanding the point? Whether /bin/date is executable is moot if I can't search /bin/ to get to it. This 0005 business is security theater, or maybe even worse than that. Please just use 0555 and don't try to be cute. 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 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 Jackson 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
Re: Lower Process Capabilities
On Tue, 2009-07-28 at 01:12 +0200, yersinia wrote: > On Mon, Jul 27, 2009 at 5:29 PM, Adam Jackson wrote: > > 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. Trim message bodies when quoting, thanks. You can create an selinux context that is not allowed to exec, or only allowed to exec certain things. Or not allowed to connect to TCP sockets. Or pretty much anything else a normal user would otherwise be allowed to do. - 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
Quoting Adam Jackson (a...@redhat.com): > On Tue, 2009-07-28 at 01:12 +0200, yersinia wrote: > > On Mon, Jul 27, 2009 at 5:29 PM, Adam Jackson wrote: > > > 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. > > Trim message bodies when quoting, thanks. > > You can create an selinux context that is not allowed to exec, or only > allowed to exec certain things. Or not allowed to connect to TCP > sockets. Or pretty much anything else a normal user would otherwise be > allowed to do. This has little to do with what Steve is trying to do. There has been talk of extending seccomp to do that kind of thing, which seems interesting. But I think that floundered away a few weeks ago... pending on someone to post a patch I guess. -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 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
Quoting Bill McGonigle (b...@bfccomputing.com): > 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? heh, I agree - running them not as root, and with just the capabilities they need. What Steve is doing is a step toward that. (Then I disagree with the last part of your statement - eventually redefine root to be just another user who happens to own the hardware. pie in the sky, perhaps.) -serge -- 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 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 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 Tue, Jul 28, 2009 at 10:11 PM, Chris Adams wrote: > Once upon a time, Bill McGonigle 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. Selinux can only restrict access but not grant any privileges. -- 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 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 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=selinux&m=118159187318524&w=2 http://marc.info/?l=selinux&m=118192327422630&w=2 http://marc.info/?l=selinux&m=118191791828777&w=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 -- 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=selinux&m=118159187318524&w=2 > http://marc.info/?l=selinux&m=118192327422630&w=2 > http://marc.info/?l=selinux&m=118191791828777&w=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=selinux&m=118159187318524&w=2 > > http://marc.info/?l=selinux&m=118192327422630&w=2 > > http://marc.info/?l=selinux&m=118191791828777&w=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 Tuesday 28 July 2009 10:22:56 am Serge E. Hallyn wrote: > > You can create an selinux context that is not allowed to exec, or only > > allowed to exec certain things. Or not allowed to connect to TCP > > sockets. Or pretty much anything else a normal user would otherwise be > > allowed to do. > > This has little to do with what Steve is trying to do. Right. All I am doing at this point is going over the daemons running as root and patching them to lower their capabilities. With libcap-ng, its generally 2-3 lines of code. As for directory perms...I'm still mulling it over. Changing perms on shadow and gshadow to should press forward, though. -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 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
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 Sun, Jul 26, 2009 at 07:32:36PM -0400, Steve Grubb wrote:
> 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
F10 does not work with this setup here:
$ sudo -i
sudo: /etc/sudoers is mode 00, should be 0440
sudo: no valid sudoers sources found, quitting
Regards
Till
pgprOrkuS7x0i.pgp
Description: PGP signature
--
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
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. -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 said the following on 08/13/2009 01:26 PM Pacific Time: 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. 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. Thank you, John -- 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 Mon, Aug 3, 2009 at 12:38 PM, Till Maas 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 Friday 14 August 2009 06:05:06 pm Serge E. Hallyn wrote:
> Quoting Steve Grubb (sgr...@redhat.com):
> > On Sunday 26 July 2009 07:32:36 pm Steve Grubb wrote:
> > 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.
>
> 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?
Should be. this morning I found that I forgot the /usr/lib[64] directories and
updated my local copy. I just updated the file I linked to above.
rpm -qpl --verbose seems to show me that the changes are in place. I also
added tracker bugs to the project page so people can better tell what was
patched and how it might have been modified. In any event the patch attached to
bz is below. I only change the attributes and not the main code.
-Steve
--- filesystem.orig/filesystem.spec 2009-07-25 11:07:17.0 -0400
+++ filesystem/filesystem.spec 2009-08-14 13:09:19.0 -0400
@@ -79,15 +79,17 @@
%files -f filelist
%defattr(0755,root,root)
-%dir /
-/bin
-/boot
+%dir %attr(555,root,root) /
+%attr(555,root,root) /bin
+%attr(555,root,root) /boot
/dev
/etc
/home
-/lib
+%attr(555,root,root) /lib
+%attr(555,root,root) /usr/lib
%ifarch x86_64 ppc ppc64 sparc sparc64 s390 s390x
-/%{_lib}
+%attr(555,root,root) /%{_lib}
+%attr(555,root,root) /usr/%{_lib}
%endif
/media
%dir /mnt
@@ -95,15 +97,16 @@
%ghost %config(missingok) %verify(not size md5 mode user link rdev group
mtime) /mnt/floppy
%dir /opt
%attr(555,root,root) /proc
-%attr(750,root,root) /root
-/sbin
+%attr(550,root,root) /root
+%attr(555,root,root) /sbin
/selinux
/srv
/sys
%attr(1777,root,root) /tmp
%dir /usr
/usr/[^s]*
-/usr/sbin
+%attr(555,root,root) /usr/sbin
+%attr(555,root,root) /usr/bin
%dir /usr/share
/usr/share/applications
/usr/share/augeas
--
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, Jul 29, 2009 at 9:32 AM, Stephen Smalley 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
