tons of: denied socket(netlink,raw,ip)

[Dwokfur]

I'm using the latest hardened sources (2.6.32-r30 and 2.6.36-r5) based on the 201012040057 grsecurity patches.
For both kernels the log gets filled with "denied socket(netlink,raw,ip) messages. The target port or IP isn't mentioned in the entires.
I tried to specify connect and bind 0.0.0.0/32 raw_sock ip - without any success. Trying to specify netlink for the socket type produces and error message and policy load failure.
It's really annoying.
I don't want to give raw sock access to all my daemons and executables using the network.

What's this???

I've recently upgraded my binutils. Gcc or glibc hasn't changed lately on my systems.

Please give me a clue on how to get rid of these nasty error messages.

[Dwokfur]

Looks like I need some lessons again about RTFM.
Additional socket families must be unlocked starting from grsec 2.2.1...

[Dwokfur]

I propose either to make netlink another default besides ipv4 or I'd like to ask for the possiblity to specify netlink for default subject. I'm getting tired of copying the "allow_sock_family netlink" from subject to subject.

Thx

[spender]

What percentage of your subjects with "connect disabled / bind disabled" require allow_sock_family netlink? How many with some connect/bind rules allowed require it?

-Brad

[Dwokfur]

What percentage of your subjects with "connect disabled / bind disabled" require allow_sock_family netlink? How many with some connect/bind rules allowed require it?

-Brad

Not too much, actually. I was just overracting it.

It is important, that event those producing the log entries (apache, squid, privoxy, chronyd, sendmail, dovecot, bind...) are functioning completely well. It think some functions they use are tampering with netlink and claim unnecessary rights.
So the symptoms are only disturbing, but didn't cause dysfunction in my case.

It seems to me all daemons - being run by root or by their own user - binding to a port require it. There are some user space executables (eg. communication, some GNOME components) binding to ports during startup or while running.

I think most of these utilities use some library function tickling netlink, but end up never using it - so a denial won't do much harm.

After my initial reaction: I accept the idea, that only those programs should be granted netlink socket access, which would really need it.
The optimal solution would be to fix a library claiming netlink while called only for binding a regular ipv4 port... However the error message is not too specific about the exact reason, metioning raw, ip and netlink...

I assume this feature to be absolutely useful after all - so thanks!

Offtopic: On my systems I'm having some serious sync issues for some time now. If these persist with the recent kernel, I'll get back.

Regards:
Dw.

[spender]

I think it's probably Linux's audit system, which uses netlink (and would explain why everything still worked without it). You could strace to confirm.

By sync do you mean clock sync?

-Brad

[Dwokfur]

I think it's probably Linux's audit system, which uses netlink (and would explain why everything still worked without it). You could strace to confirm.

By sync do you mean clock sync?

-Brad

Audit: sounds suspicious. I keep AUDITSYSCALL enabled for some userspace utility I can't remember.

Here is an example strace of /sbin/ip:

Code: Select all

execve("/sbin/ip", ["ip"], [/* 66 vars */]) = 0
brk(0)                                  = 0x179f92d4
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x519ad000
access("/etc/ld.so.preload", R_OK)      = -1 ENOENT (No such file or directory)
open("LD_LIBRARY_PATH/tls/i686/libdl.so.2", O_RDONLY) = -1 ENOENT (No such file or directory)
open("LD_LIBRARY_PATH/tls/libdl.so.2", O_RDONLY) = -1 ENOENT (No such file or directory)
open("LD_LIBRARY_PATH/i686/libdl.so.2", O_RDONLY) = -1 ENOENT (No such file or directory)
open("LD_LIBRARY_PATH/libdl.so.2", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/etc/ld.so.cache", O_RDONLY)      = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=201033, ...}) = 0
mmap2(NULL, 201033, PROT_READ, MAP_PRIVATE, 3, 0) = 0x5197b000
close(3)                                = 0
open("/lib/libdl.so.2", O_RDONLY)       = 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0000\n\0\0004\0\0\0"..., 512) = 512
fstat64(3, {st_mode=S_IFREG|0755, st_size=9488, ...}) = 0
mmap2(NULL, 12344, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x51977000
mmap2(0x51979000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x1) = 0x51979000
close(3)                                = 0
open("LD_LIBRARY_PATH/tls/i686/libc.so.6", O_RDONLY) = -1 ENOENT (No such file or directory)
open("LD_LIBRARY_PATH/tls/libc.so.6", O_RDONLY) = -1 ENOENT (No such file or directory)
open("LD_LIBRARY_PATH/i686/libc.so.6", O_RDONLY) = -1 ENOENT (No such file or directory)
open("LD_LIBRARY_PATH/libc.so.6", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/lib/libc.so.6", O_RDONLY)        = 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0@n\1\0004\0\0\0"..., 512) = 512
fstat64(3, {st_mode=S_IFREG|0755, st_size=1413452, ...}) = 0
mmap2(NULL, 1424616, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x5181b000
mprotect(0x51970000, 4096, PROT_NONE)   = 0
mmap2(0x51971000, 12288, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x155) = 0x51971000
mmap2(0x51974000, 11496, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x51974000
close(3)                                = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x5181a000
set_thread_area({entry_number:-1 -> 6, base_addr:0x5181a6c0, limit:1048575, seg_32bit:1, contents:0, read_exec_only:0, limit_in_pages:1, seg_not_present:0, useable:1}) = 0
mprotect(0x51971000, 8192, PROT_READ)   = 0
mprotect(0x51979000, 4096, PROT_READ)   = 0
mprotect(0x179e7000, 4096, PROT_READ)   = 0
mprotect(0x519cb000, 4096, PROT_READ)   = 0
munmap(0x5197b000, 201033)              = 0
socket(PF_NETLINK, SOCK_RAW, 0)         = 3
setsockopt(3, SOL_SOCKET, SO_SNDBUF, [32768], 4) = 0
setsockopt(3, SOL_SOCKET, SO_RCVBUF, [1048576], 4) = 0
bind(3, {sa_family=AF_NETLINK, pid=0, groups=00000000}, 12) = 0
getsockname(3, {sa_family=AF_NETLINK, pid=17925, groups=00000000}, [12]) = 0
time(NULL)                              = 1292031933
close(3)                                = 0
write(2, "Usage: ip [ OPTIONS ] OBJECT { C"..., 493Usage: ip [ OPTIONS ] OBJECT { COMMAND | help }
       ip [ -force ] -batch filename
where  OBJECT := { link | addr | addrlabel | route | rule | neigh | ntable |
                   tunnel | tuntap | maddr | mroute | mrule | monitor | xfrm }
       OPTIONS := { -V[ersion] | -s[tatistics] | -d[etails] | -r[esolve] |
                    -f[amily] { inet | inet6 | ipx | dnet | link } |
                    -o[neline] | -t[imestamp] | -b[atch] [filename] |
                    -rc[vbuf] [size]}
) = 493
exit_group(-1)                          = ?


However ip might be an example for expected use of netlink. How the reason could be figured out? Agetty is affected, but strace shows no signs of NETLINK after calling it without arguments.

Sync: file systems sync. I'm suffering from it. I removed some tp_smapi modules on my laptop. I disabled the old firewire stack in the kernel. I converted both the laptop and the server to use data=journal for ext3 - that is the most conservative choice. It still there. I'll test the recent kernels. Compiling qt-gui can ruin the whole file systems so I should make a backup first...

Regards:
Dw.