syslog-ng as non-root user? (and misc acl syntax questions)

[jnf]

Hi.
Still kinda trying to grapple with the acl's, so excuse me if I'm being stupid.
I'm trying to run syslog-ng as its own non-root user, It keeps getting a Operation not permitted when it tries to read from /proc/kmsg .
Now at some point the linux kernel was patched to allow anyone with CAP_SYS_ADMIN to read from it:

Code: Select all

kmsg.c
[ ... ]
static int kmsg_open(struct inode * inode, struct file * file)
{
return do_syslog(1,NULL,0);
}
[ ... ]
static ssize_t kmsg_read(struct file * file, char * buf,
size_t count, loff_t *ppos)
{
return do_syslog(2,buf,count);
}

printk.c
[ .... ]
if (!capable(CAP_SYS_ADMIN))
       return -EPERM;

Ok, so as I am understanding the acl's, I should be able to setup a role, ie 'syslog', give it minimal privs, then a subject like /sbin/syslog-ng and give it CAP_SYS_ADMIN and etc permissions and we should be good to go correct ?

Below is a copy of the relevant acl's, also - as I understand it this function will only be called in process context (do_syslog()), so I could just as easily patch the source there and check the uid against my syslog uid, instead of having to give it CAP_SYS_ADMIN ?

Any thoughts on that would be helpful.

My other question as I grapple with the ACL's is the basic syntax, meaning:

Code: Select all

role foo
role_transitions bar
role_allow_ip 0.0.0.0/32

subject / {
           /                        h
           /bin/bash            x
          -CAP_ALL
          bind disabled
          connect disabled
}

subject /bin/bash o {
            [ ... ]
             -CAP_ALL
             +CAP_SYS_ADMIN
             bind [ ... ]
             connect [ ... ]
}

If I am understanding things correct, here we have the role foo, who can transition to bar, and is allowed to come from any address, by default he has no capabilities and can only exec bash, then bash itself can do whatever files are listed in the first [ ... ] , (i.e. /lib/libc.so.2 x would allow it to execute libc.so.2), it should also run with the sys admin capability correct? If I am following all of that correctly (feel free to correct me or point me in the direction of better documentation) then this should be working correctly:

Code: Select all

role syslog uTi
subject / {
   /            h
   -CAP_ALL
   bind disabled
   connect  disabled
}
subject /sbin/syslog-ng o {
   /            h
   /proc            h
   /proc/kmsg         rw
   /proc/sys/kernel/ngroups_max   r
   /dev            h
   /dev/log         rw
   /var            h
   /var/run         h
   /var/run/syslog-ng      rwcd
   /var/run/nscd
   /var/run/nscd/socket      rw
   /lib            h
   /lib/libnsl.so.1      rx
   /lib/libnss_files.so.2      rx
   /lib/libresolv.so.2      rx
   /lib/libc.so         rx
   /lib/ld-linux.so.2      rx
   /usr/lib         h
   /usr/lib/libwrap.so.0      rx
   /etc            h
   /etc/passwd         r
   /etc/group         r
   /etc/ld.so.cache      r
   /etc/hosts         r
   /etc/nsswitch.conf      r
   /etc/resolv.conf      r
   /etc/syslog-ng
   /etc/syslog-ng/syslog-ng.conf   r
   -CAP_ALL
   +CAP_SYS_ADMIN
   bind disabled
   connect 172.0.0.0/32:514 stream tcp # real ip edited
}


This all works correctly, when it open's /proc/kmsg it does so with mode O_RDWR and that returns fine, however any attempts to read from it return Operation not permitted.

Any ideas?

[jnf]

hrm upon further inspection, It doesn't appear that this is the result of grsec's checks for CAP_SYS_ADMIN- directly after the

kernel/printk.c
do_syslog() :

Code: Select all

if (!capable(CAP_SYS_ADMIN) && [ ... ])


we see a:

Code: Select all

error = security_syslog(type)
if (error)
        return error ;


which is defined in something like include/linux/security.h as a pointer to the function cap_syslog(), which does a:

security/commoncap.c

Code: Select all

if ((type != 3 && type != 10) && !capable(CAP_SYS_ADMIN))
         return -EPERM
return 0;


Which if I had the sys admin capability, then I should be able to pass this without a problem, upon returning from that into do_syslog() we enter a switch statement, and immediately on type being equal to 4 (which it is per strace) it sets error to -EINVAL, and all failures do a goto out, out being defined as return error;

SO.
In conclusion I am not getting CAP_SYS_ADMIN somehow, which tells me its something with my acl's.

ideas?

[jj]

The +CAP_SYS_ADMIN in the acl only means that if a process has this capability, grsec will not oppose that it uses it, it does not however grant this cap to the subject in question.
I do not know if it adds the cap to the permitted set, anyway you will need a wrapper around syslog to start it with the right capabilities set.

[jnf]

rad. dunno why i didnt think of that, but it makes sense.
I will give it a shot, thanks again.

[jnf]

just as an addendum I wanted to add that it appears there is more to this, simply having cap_sys_admin and/or cap_dac_override does not allow one to access /proc/kmsg . However cap_dac_override of course allows you to access some files in /proc regardless of the dac's, however trying to access /etc/shadow as a non-root user w/ cap_dac_override still fails. I guess this is what they mean by linux capabilities being incomplete ;]