Hi.
I have been playing a little here and there with linux capabilities, and
seem to be hitting a few snags so I was hoping to obtain some input on
their current status. The kernel on the box in question is 2.6.10, with
the CAP_INIT_EFF_SET macro modified to allow init to have CAP_SETPCAP.
I am mostly trying to accomplish this so that I can run syslog as a
non-root user and as I understand it by digging through the source, one
should be able to accomplish this with the CAP_SYS_ADMIN capability-
however this does not appear to be true ?
in kernel/printk.c I see
error = security_syslog(type)
if (error)
return error ;
which is defined in something like include/linux/security.h as a pointer
to cap_syslog(), which in turn is defined in security/commoncap.c where I
see:
if ((type != 3 && type != 10) && !capable(CAP_SYS_ADMIN))
return -EPERM
return 0;
Type 3 is:
* 3 -- Read up to the last 4k of messages in the ring buffer.
So when I give the process CAP_SYS_ADMIN I still cannot seem to read from
/proc/kmsg, I also tried giving it CAP_DAC_OVERRIDE just to test to see if
DAC's were the problem but that didn't seem to help any.
So with that said, anyone have any idea's as to what I need to do and any
details on the current state of the capabilities would be helpful.
Thanks,
jnf
* jnf ([email protected]) wrote:
> I have been playing a little here and there with linux capabilities, and
> seem to be hitting a few snags so I was hoping to obtain some input on
> their current status. The kernel on the box in question is 2.6.10, with
> the CAP_INIT_EFF_SET macro modified to allow init to have CAP_SETPCAP.
This is not exactly safe. It was removed on purpose. See this paper:
http://www.cs.berkeley.edu/~daw/papers/setuid-usenix02.pdf
> I am mostly trying to accomplish this so that I can run syslog as a
> non-root user and as I understand it by digging through the source, one
> should be able to accomplish this with the CAP_SYS_ADMIN capability-
> however this does not appear to be true ?
BTW, CAP_SYS_ADMIN is a lot of privileges, so even this would not be as
secure as you might hope.
> in kernel/printk.c I see
>
> error = security_syslog(type)
> if (error)
> return error ;
>
> which is defined in something like include/linux/security.h as a pointer
> to cap_syslog(), which in turn is defined in security/commoncap.c where I
> see:
>
> if ((type != 3 && type != 10) && !capable(CAP_SYS_ADMIN))
> return -EPERM
> return 0;
>
>
> Type 3 is:
> * 3 -- Read up to the last 4k of messages in the ring buffer.
3 doesn't require any permissions. It's like doing 'dmesg.'
> So when I give the process CAP_SYS_ADMIN I still cannot seem to read from
> /proc/kmsg, I also tried giving it CAP_DAC_OVERRIDE just to test to see if
> DAC's were the problem but that didn't seem to help any.
Since /proc/kmsg is 0400 you need CAP_DAC_READ_SEARCH (don't necessarily
need full override). Otherwise, you are right, you do need CAP_SYS_ADMIN.
Or just use syslog(2) directly, and you'll avoid the DAC requirement.
> So with that said, anyone have any idea's as to what I need to do and any
> details on the current state of the capabilities would be helpful.
The best way is to drop the caps from within the syslogd. Otherwise
you will gain/lose all caps on execve() due to the way caps actually
effectively follow uids. Here, I threw together an example of some
other bits of code I have laying around (run it as root).
thanks,
-chris
--
Linux Security Modules http://lsm.immunix.org http://lsm.bkbits.net
Hi Chris, thank you for the response.
>
> This is not exactly safe. It was removed on purpose. See this paper:
> http://www.cs.berkeley.edu/~daw/papers/setuid-usenix02.pdf
I will read the paper before commenting on it further, however I cannot
see what dangers it would really provide that a setuid program doesnt
already have- other than the ability to give another non-root process root
like abilities. However, the more I ponder it, it seems as if you could
accomplish a lot of things with a set of ACL's and Capabilities (think
compartmentalizing everything from each other where no one thing has full
control of anything other than its particular subsystem).
>
> BTW, CAP_SYS_ADMIN is a lot of privileges, so even this would not be as
> secure as you might hope.
Yes, I am fully aware of that, I had previously written in a current->uid
check as well to get around the capabilities problem, however it didn't
work so I took it out. Portability isn't as much as an issue as 'making it
work on this box'.
>
> 3 doesn't require any permissions. It's like doing 'dmesg.'
Hrm, am I missing something? Oh wait, duh, I misread that line. ;]
> Since /proc/kmsg is 0400 you need CAP_DAC_READ_SEARCH (don't necessarily
> need full override). Otherwise, you are right, you do need CAP_SYS_ADMIN.
> Or just use syslog(2) directly, and you'll avoid the DAC requirement.
Hrm, even a chmod of it didn't appear to really affect things?
I will investigate the CAP_DAC_READ_SEARCH and see how that works, I
appreciate the response.
> The best way is to drop the caps from within the syslogd. Otherwise
> you will gain/lose all caps on execve() due to the way caps actually
> effectively follow uids. Here, I threw together an example of some
> other bits of code I have laying around (run it as root).
Thank you, when I get a second I will take a look through it. I've already
written a couple programs to set/get capabilities, so I am aware of the
interface/api, it was just that even with the capabilities it was not
working ;]
Either way I will take a look through the code, I appreciate the reply.
> thanks,
> -chris
> --
> Linux Security Modules http://lsm.immunix.org http://lsm.bkbits.net
>
cheers,
jnf
* jnf ([email protected]) wrote:
> I will read the paper before commenting on it further, however I cannot
> see what dangers it would really provide that a setuid program doesnt
> already have- other than the ability to give another non-root process root
> like abilities. However, the more I ponder it, it seems as if you could
It was a dangerous failure mode when a capability isn't present that hit
sendmail.
> accomplish a lot of things with a set of ACL's and Capabilities (think
> compartmentalizing everything from each other where no one thing has full
> control of anything other than its particular subsystem).
Yes, that's the ideal. Unfortunately it doesn't work out quite so
neatly ;-/
> > Since /proc/kmsg is 0400 you need CAP_DAC_READ_SEARCH (don't necessarily
> > need full override). Otherwise, you are right, you do need CAP_SYS_ADMIN.
> > Or just use syslog(2) directly, and you'll avoid the DAC requirement.
>
> Hrm, even a chmod of it didn't appear to really affect things?
Should, and it makes a difference for me.
thanks,
-chris
--
Linux Security Modules http://lsm.immunix.org http://lsm.bkbits.net
jnf <[email protected]> writes:
> Thank you, when I get a second I will take a look through it. I've already
> written a couple programs to set/get capabilities, so I am aware of the
> interface/api, it was just that even with the capabilities it was not
> working ;]
> Either way I will take a look through the code, I appreciate the reply.
You might want to look at
<http://www.kernel.org/pub/linux/libs/security/linux-privs/kernel-2.4/capfaq-0.2.txt>
And in
<http://www.kernel.org/pub/linux/libs/security/linux-privs/kernel-2.4/libcap-1.10.tar.bz2>,
you will find some example programs: execcap, setpcaps and sucap.
Regards, Olaf.