* linux capabilities ?
@ 2005-01-20 18:02 jnf
2005-01-20 21:49 ` Chris Wright
0 siblings, 1 reply; 5+ messages in thread
From: jnf @ 2005-01-20 18:02 UTC (permalink / raw)
To: linux-kernel
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
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: linux capabilities ?
2005-01-20 18:02 linux capabilities ? jnf
@ 2005-01-20 21:49 ` Chris Wright
2005-01-20 22:54 ` jnf
0 siblings, 1 reply; 5+ messages in thread
From: Chris Wright @ 2005-01-20 21:49 UTC (permalink / raw)
To: jnf; +Cc: linux-kernel
[-- Attachment #1: Type: text/plain, Size: 2273 bytes --]
* jnf (jnf@innocence-lost.us) 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
[-- Attachment #2: read_syslog.c --]
[-- Type: text/x-c++src, Size: 2403 bytes --]
/* Copyright (c) Chris Wright <chrisw@osdl.org>
* GPL v2
* Drop uid/gid and caps and read syslog
*/
#include <unistd.h>
#include <stdio.h>
#include <errno.h>
#include <string.h>
#include <fcntl.h>
#include <sys/types.h>
#include <sys/prctl.h>
#include <sys/capability.h>
static void usage(void)
{
printf("Usage: read_syslog options\n");
printf("-u uid\n -p {use /proc/kmsg (default)}\n -s {use syslog(2)}\n");
}
static void dumpcred(void)
{
uid_t ruid, euid, suid;
gid_t rgid, egid, sgid;
cap_t caps = cap_get_proc();
getresuid(&ruid, &euid, &suid);
getresgid(&rgid, &egid, &sgid);
printf(" Real Eff Saved\n");
printf("User %-8d%-8d%-8d\n", ruid, euid, suid);
printf("Group %-8d%-8d%-8d\n", rgid, egid, sgid);
if (caps)
{
char *p = cap_to_text(caps, NULL);
if (p) {
printf("Caps: %s\n\n", p);
cap_free(p);
}
cap_free(caps);
}
}
static int usecap(const char *caps)
{
int rc = -1;
cap_t capset = cap_from_text(caps);
if (capset)
{
rc = cap_set_proc(capset);
if (rc) {
perror("cap_set_proc");
}
cap_free(capset);
}
return rc;
}
static int drop_privs(uid_t uid, gid_t gid, const char *caps)
{
int rc;
dumpcred();
prctl(PR_SET_KEEPCAPS, 1);
rc = setresgid(gid, gid, gid);
if (rc == -1) {
perror("setresgid");
goto out;
}
rc = setresuid(uid, uid, uid);
if (rc == -1) {
perror("setresuid");
goto out;
}
rc = usecap(caps);
if (rc == -1) {
perror("usecap");
goto out;
}
out:
dumpcred();
return rc;
}
main(int argc, char *argv[])
{
uid_t new_uid = 500;
gid_t new_gid = 500;
int c, fd, rc, use_proc = 1;
char *caps = "cap_dac_read_search,cap_sys_admin=ep";
char buf[1024];
while ((c = getopt(argc, argv, "u:g:ps")) != -1) {
switch(c) {
case 'u':
new_uid = atoi(optarg);
break;
case 'g':
new_gid = atoi(optarg);
break;
case 'p':
/* default */
break;
case 's':
use_proc = 0;
caps = "cap_sys_admin=ep";
break;
default:
usage();
exit(1);
break;
}
}
memset(buf, 0, sizeof(buf));
if (drop_privs(new_uid, new_gid, caps) == -1) {
exit(1);
}
if (use_proc) {
fd = open("/proc/kmsg", O_RDONLY);
if (fd == -1) {
perror("open");
exit(1);
}
rc = read(fd, buf, sizeof(buf));
if (rc == -1) {
perror("read");
exit(1);
}
} else {
rc = syslog(2, buf, sizeof(buf));
if (rc == -1) {
perror("syslog");
exit(1);
}
}
printf("%s\n", buf);
}
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: linux capabilities ?
2005-01-20 21:49 ` Chris Wright
@ 2005-01-20 22:54 ` jnf
2005-01-21 0:23 ` Chris Wright
2005-01-21 23:19 ` Olaf Dietsche
0 siblings, 2 replies; 5+ messages in thread
From: jnf @ 2005-01-20 22:54 UTC (permalink / raw)
To: Chris Wright; +Cc: linux-kernel
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
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: linux capabilities ?
2005-01-20 22:54 ` jnf
@ 2005-01-21 0:23 ` Chris Wright
2005-01-21 23:19 ` Olaf Dietsche
1 sibling, 0 replies; 5+ messages in thread
From: Chris Wright @ 2005-01-21 0:23 UTC (permalink / raw)
To: jnf; +Cc: Chris Wright, linux-kernel
* jnf (jnf@innocence-lost.us) 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
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: linux capabilities ?
2005-01-20 22:54 ` jnf
2005-01-21 0:23 ` Chris Wright
@ 2005-01-21 23:19 ` Olaf Dietsche
1 sibling, 0 replies; 5+ messages in thread
From: Olaf Dietsche @ 2005-01-21 23:19 UTC (permalink / raw)
To: jnf; +Cc: Chris Wright, linux-kernel
jnf <jnf@innocence-lost.us> 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.
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2005-01-21 23:25 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2005-01-20 18:02 linux capabilities ? jnf
2005-01-20 21:49 ` Chris Wright
2005-01-20 22:54 ` jnf
2005-01-21 0:23 ` Chris Wright
2005-01-21 23:19 ` Olaf Dietsche
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).