6:32 p.m.
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 /00000 -a -uid 0 -exec chmod u+x {} \; 2>/dev/null
find /usr/sbin -type f -perm /00000 -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 0000 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
7:38 p.m.
Steve Grubb <sgrubb(a)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
7:54 p.m.
On Sunday 26 July 2009 08:38:45 pm Tom Lane wrote:
Steve Grubb <sgrubb(a)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
8 p.m.
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
8:11 a.m.
Quoting Steve Grubb (sgrubb(a)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(a)redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
8:16 a.m.
On Monday 27 July 2009 09:11:33 am Serge E. Hallyn wrote:
Quoting Steve Grubb (sgrubb(a)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
8:42 a.m.
Quoting Steve Grubb (sgrubb(a)redhat.com):
On Monday 27 July 2009 09:11:33 am Serge E. Hallyn wrote:
> Quoting Steve Grubb (sgrubb(a)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
9:45 a.m.
Steve Grubb <sgrubb(a)redhat.com> 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
8:01 p.m.
Steve Grubb <sgrubb(a)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
4:25 a.m.
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
<jmorris(a)namei.org>
10:29 a.m.
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
6:12 p.m.
On Mon, Jul 27, 2009 at 5:29 PM, Adam Jackson<ajax(a)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(a)redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
8:59 a.m.
On Tue, 2009-07-28 at 01:12 +0200, yersinia wrote:
On Mon, Jul 27, 2009 at 5:29 PM, Adam Jackson<ajax(a)redhat.com>
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
9:22 a.m.
Quoting Adam Jackson (ajax(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<ajax(a)redhat.com> 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
9:10 a.m.
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 0000 should press forward, though.
-Steve
2:06 p.m.
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: bill(a)bfccomputing.com
Blog: http://blog.bfccomputing.com/
VCard: http://bfccomputing.com/vcard/bill.vcf
2:14 p.m.
Quoting Bill McGonigle (bill(a)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
3:11 p.m.
Once upon a time, Bill McGonigle <bill(a)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 <cmadams(a)hiwaay.net>
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.
3:43 p.m.
On Tue, Jul 28, 2009 at 10:11 PM, Chris Adams<cmadams(a)hiwaay.net> wrote:
Once upon a time, Bill McGonigle <bill(a)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.
Selinux can only restrict access but not grant any privileges.
4:53 p.m.
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: bill(a)bfccomputing.com
Blog: http://blog.bfccomputing.com/
VCard: http://bfccomputing.com/vcard/bill.vcf
6:15 p.m.
On Tue, Jul 28, 2009 at 17:53:53 -0400,
Bill McGonigle <bill(a)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.
8:13 p.m.
Quoting Bill McGonigle (bill(a)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
7:03 a.m.
On Tue, 2009-07-28 at 20:13 -0500, Serge E. Hallyn wrote:
Quoting Bill McGonigle (bill(a)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
8:01 a.m.
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
<jmorris(a)namei.org>
8:10 a.m.
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
8:32 a.m.
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
3:09 a.m.
On Wed, Jul 29, 2009 at 9:32 AM, Stephen Smalley<sds(a)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?
7:36 a.m.
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
8:49 a.m.
Quoting Stephen Smalley (sds(a)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
9:06 a.m.
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
1:16 p.m.
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: bill(a)bfccomputing.com
Blog: http://blog.bfccomputing.com/
VCard: http://bfccomputing.com/vcard/bill.vcf
9:07 a.m.
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(a)redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
7:09 p.m.
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.
7:02 a.m.
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.
5:08 p.m.
On 08/05/2009 08:02 AM, Paul Howarth wrote:
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: bill(a)bfccomputing.com
Blog: http://blog.bfccomputing.com/
VCard: http://bfccomputing.com/vcard/bill.vcf
11:38 a.m.
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 /00000 -a -uid 0 -exec chmod u+x {} \; 2>/dev/null
find /usr/sbin -type f -perm /00000 -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 0000 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
9:02 a.m.
On Mon, Aug 3, 2009 at 12:38 PM, Till Maas<opensource(a)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.
3:26 p.m.
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
4:53 p.m.
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
8:27 p.m.
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
9:15 a.m.
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
5:05 p.m.
Quoting Steve Grubb (sgrubb(a)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
8:04 p.m.
On Friday 14 August 2009 06:05:06 pm Serge E. Hallyn wrote:
Quoting Steve Grubb (sgrubb(a)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.000000000 -0400
+++ filesystem/filesystem.spec 2009-08-14 13:09:19.000000000 -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
5367
days inactive
5387
days old
43 comments
19 participants
participants (19)
-
Adam Jackson -
Bill McGonigle -
Bruno Wolff III -
Chris Adams -
David Malcolm -
drago01 -
Gregory Maxwell -
James Morris -
Joe Nall -
John Poelstra -
Jon Stanley -
Matthew Woehlke -
Paul Howarth -
Serge E. Hallyn -
Stephen Smalley -
Steve Grubb -
Till Maas -
Tom Lane -
yersinia