CAP_NET_ADMIN with 2.6.20 or later

[bplant]

Does anyone know why, starting around 2.6.20, heaps of processes require the CAP_NET_ADMIN capability?

Running a 2.6.18 (xen) kernel, everything is fine, but as soon as I go to 2.6.20 (xen) or a more recent pvops kernel (E.g. 2.6.27 or 2.6.32), the RBAC system starts reporting attempts by processes to use CAP_NET_ADMIN. From http://www.lids.org/lids-howto/node48.html, CAP_NET_ADMIN allows many things that sudo and cat just shouldn't need to do.

Jan 29 10:16:31 ns2 grsec: From 10.20.50.1: (root:U:/) use of CAP_NET_ADMIN denied for /bin/cat[cat:6378] uid/euid:0/0 gid/egid:0/0, parent /usr/local/bin/check_conns.sh[check_conns.sh:6377] uid/euid:414/414 gid/egid:414/414
Jan 29 10:16:36 ns2 grsec: From 10.20.50.2: (nagios:U:/usr/bin/sudo) use of CAP_NET_ADMIN denied for /usr/bin/sudo[sudo:6390] uid/euid:414/0 gid/egid:414/414, parent /usr/local/bin/check_conns.sh[check_conns.sh:6389] uid/euid:414/414 gid/egid:414/414

Any clues?

[spender]

Can you paste an strace of the cat that causes the log? It may help in tracking down a call to capable that needs to be changed to capable_nolog (cases where a process isn't necessarily requesting certain privilege, but the kernel is checking for the existence of said privilege anyway).

-Brad

[bplant]

<rant>The login timeout on this forum is way too short. Just lost my 90% written post!</rant>

Can you paste an strace of the cat that causes the log? It may help in tracking down a call to capable that needs to be changed to capable_nolog (cases where a process isn't necessarily requesting certain privilege, but the kernel is checking for the existence of said privilege anyway).

I looked at the script that was using cat and it turns out cat is reading from /proc/sys/net/netfilter/nf_conntrack_count. Coincidence? What I didn't mention earlier was that the programs still function correctly (more evidence for your theory above?). I.e. cat is still able to read from /proc/sys/net/netfilter/nf_conntrack_count despite the logged message.

Here is the strace for cat. I ran it from the admin role as I'd need to create a subject for strace otherwise. Hope this is ok.

Code: Select all

execve("/bin/cat", ["cat", "/proc/sys/net/netfilter/nf_connt"...], [/* 23 vars */]) = 0
brk(0)                                  = 0x677f6be1a08
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x77b8a9d05000
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x77b8a9d04000
access("/etc/ld.so.preload", R_OK)      = -1 ENOENT (No such file or directory)
open("/etc/ld.so.cache", O_RDONLY)      = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=19115, ...}) = 0
mmap(NULL, 19115, PROT_READ, MAP_PRIVATE, 3, 0) = 0x77b8a9cff000
close(3)                                = 0
open("/lib/libc.so.6", O_RDONLY)        = 3
read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0p\324\1\0"..., 832) = 832
fstat(3, {st_mode=S_IFREG|0755, st_size=1369216, ...}) = 0
mmap(NULL, 2340200, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x77b8a99b1000
mprotect(0x77b8a9ae4000, 1044480, PROT_NONE) = 0
mmap(0x77b8a9be3000, 20480, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x132000) = 0x77b8a9be3000
mmap(0x77b8a9be8000, 17768, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x77b8a9be8000
close(3)                                = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x77b8a9cfe000
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x77b8a9cfd000
arch_prctl(ARCH_SET_FS, 0x77b8a9cfd6d0) = 0
open("/dev/urandom", O_RDONLY)          = 3
read(3, "\344\367\31E\362\355\300\207", 8) = 8
close(3)                                = 0
mprotect(0x77b8a9be3000, 12288, PROT_READ) = 0
mprotect(0x77b8a9d07000, 4096, PROT_READ) = 0
munmap(0x77b8a9cff000, 19115)           = 0
brk(0)                                  = 0x677f6be1a08
brk(0x677f6c02a08)                      = 0x677f6c02a08
brk(0x677f6c03000)                      = 0x677f6c03000
fstat(1, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 0), ...}) = 0
open("/proc/sys/net/netfilter/nf_conntrack_count", O_RDONLY) = 3
fstat(3, {st_mode=S_IFREG|0444, st_size=0, ...}) = 0
read(3, "100\n", 1024)                  = 4
write(1, "100\n", 4100
)                    = 4
read(3, "", 1024)                       = 0
brk(0x677f6c02000)                      = 0x677f6c02000
close(3)                                = 0
close(1)                                = 0
close(2)                                = 0
exit_group(0)                           = ?

FYI, the same thing happens for sshd, apache2 and rsync as well as every (or most of them) program in the postfix suite. I could try stracing rsync or sshd, but apache2 and postfix could be a bit tricky. I think there might be a pattern here though - programs that use (or at least bind to) the network.

Cheers,

Brad

[spender]

That would explain it. There's a generic capable check any time a /proc/sys/net entry is accessed. You can change it in net/sysctl_net.c from capable to capable_nolog or wait for me to do it in the next patch (which will have a UDEREF fix and a Xen domU fix as well).

-Brad

[bplant]

That would explain it. There's a generic capable check any time a /proc/sys/net entry is accessed. You can change it in net/sysctl_net.c from capable to capable_nolog or wait for me to do it in the next patch (which will have a UDEREF fix and a Xen domU fix as well).

Thanks Brad, I'll checkout net/sysctl_net.c.

Cheers, Brad

[spender]

Regarding login timeouts, that shouldn't be happening if you have the option checked to stay logged in. The only case I'm aware of where it will occur is if your IP is changing to a different class C subnet (say, if you're using TOR).

-Brad

[bplant]

That would explain it. There's a generic capable check any time a /proc/sys/net entry is accessed. You can change it in net/sysctl_net.c from capable to capable_nolog or wait for me to do it in the next patch (which will have a UDEREF fix and a Xen domU fix as well).

Changing the capable call in net/sysctl_net.c to capable_nolog stopped the CAP_NET_ADMIN logs for cat, but not for sudo. I made the necessary adjustments so that I could strace sudo without being in the admin role. I'll email the strace output to you in a second.

[spender]

Looks netlink related (probably within the DNS resolver from glibc) -- I'll see what I can do about it.

-Brad

[spender]

Does every process running as root that uses the network trigger the log? (look in the strace for the socket(PF_NETLINK, SOCK_RAW, 0) call, the 0 is NETLINK_ROUTE) What version of glibc are you using?

-Brad

[bplant]

Hi Brad,

Does every process running as root that uses the network trigger the log? (look in the strace for the socket(PF_NETLINK, SOCK_RAW, 0) call, the 0 is NETLINK_ROUTE) What version of glibc are you using?

I believe all the processes that trigger the log are running as root (or at least start out that way before dropping permissions) and are using the network. Apache2, sshd, rsync and postfix. sudo doesn't use the network, but it has the socket call you listed above.

There are other processes that both run as root and use the network though such as syslog-ng. I straced syslog-ng however and there was *no* use of the PF_NETLINK or SOCK_RAW option at all.

sshd on the other hand *does* call socket(PF_NETLINK, SOCK_RAW, 0) so it would appear as though your suspicions are correct.

glibc version is 2.5 (Gentoo -r4)

Cheers,

Brad

[spender]

It should be fixed in the latest patch I just uploaded.

-Brad

[bplant]

It should be fixed in the latest patch I just uploaded.

Thanks Brad. I'm away until Tuesday so I'll check it then.

Cheers,

Brad

[bplant]

It should be fixed in the latest patch I just uploaded.

Looking pretty good so far

Cheers,

Brad