grsecurity forums

I see these entries in the log.
Aug 18 17:40:25 kernel: grsec: (root:U:/usr/sbin/alsactl) denied create of /dev/shm/pulse-shm-3863106936 for reading writing by /usr/sbin/alsactl[alsactl:5926] uid/euid:0/0 gid/egid:0/0, parent /lib64/rc/sh/runscript.sh[runscript.sh:5918] uid/euid:0/0 gid/egid:0/0
However /usr/sbin/alsactl has rwcdlma rights for /dev/shm.
What else do I need to let alsactl do its job on /dev/shm?
I'm running a reasonably new kernel (hardened-sources-3.5.1-r2).

Thx:
Dw.

Can you mail me your full policy for alsactl? Did the problem first occur with 3.5.1, or have you changed userland in the meantime?

-Brad

This is what I have for alsactl as root in my policy:

Code: Select all

subject /usr/sbin/alsactl
        /dev/snd        rwcdlma
        /etc/asound.state       rwcdlma
        /var/lib/alsa   rwcdlma
        /.pulse-cookie  rwcdlma
        /.pulse         rwcdlma
        /dev/shm        rwcdlma
        -CAP_ALL
        +CAP_CHOWN
        +CAP_FOWNER
        +CAP_FSETID
        +CAP_SYS_TTY_CONFIG
        bind disabled
        connect disabled


Unfortunately there have been extensive userland changes lately, including: udev, udisks and many other key packages. Baselayout has been also updated and it involved alsa packages and pulseaudio as well...

Regards:
Dw.

Was /dev/shm perhaps unmounted and remounted while RBAC was enabled? I don't see anything wrong with the policy itself (other than being overly permissive and "a" being redundant when "w" is set).

-Brad

In my last post I forgot to mention, that openrc has been also updated lately.
I use Gentoo. I get the denial, during the system is going down for a reboot. There are no symptoms, just the log entry during shutdown. Something has been changed how the system handles pulseaudio. Personally I don't keen on pulseaudio, but some userland stuff seems to require it. I enable RBAC in the local portion of init. So it gets activated at the end of the boot process. I don't know if Gentoo userland would remount shm, but I see no grsec entries in my log (I keep mount logging switched on), that would indicate such a remount.
I usually switch to overly permissive mode while writing policies if I have denials like this - I know it's an adverse thing regarding security. May I omit 'a' if 'w' has been already specified?

Thx:
Dw.

Are you able to reproduce it at all? What I think must be happening is the inode on /dev/shm is changing behind the scenes, similar to the /proc mess I had to deal with before. This would cause the lookup to fall back to /dev, then to /. I can look at the code, but if you can demonstrate it easily that would confirm the problem. Some periodic stat's of /dev/shm interspersed with cache flushes via /proc/sys should do the trick.

-Brad

Dear Brad,

I can observe the log entry each time I restart the computer. But I cannot see the message during everyday use. Alsactl does something, which triggers the error message. Please be a bit more precise on exactly what should I do by periodic stat's of /dev/shm. I know how to flush using /proc/sys. I can also introduce an arbitrary line in source for debugging if you wish.

Thx:
Dw.

So just record the inode number reported by /dev/shm before alsactl does that thing, and record it after it does that thing. Let me know if the numbers differ.

Thanks,
-Brad

It turned out, that all applications trying to use the sound services now also fiddle around with shm because of the bloody pulseaudio.
If somebody uses a system-wide instance, it won't use /dev/shm. But this method has drawbacks, including some security implications.
http://www.freedesktop.org/wiki/Softwar ... SystemWide
http://www.freedesktop.org/wiki/Softwar ... SystemWide
However I've discovered the /etc/pulse/daemon.conf and client.conf configuration files, where I could explicitly disable the use of shm. That is told to increase memory usage, but I have plenty of it.
http://linux.die.net/man/5/pulse-daemon.conf
It turned out, that pulseaudio is not running after logging in. Despite I disabled realtime and nice features as well (both by the configuration files and command line options), pulseaudio still tries to renice itself. If I try to start it while RBAC is enabled, the daemon cannot start. If I disable RBAC, the daemon starts, but pavucontrol dosen't show the proper audio devices, only the Ati FIrePro's HDMI stuff. I think I also have to alter some other config files in order to get it running. Although I'm completely satisfied by ALSA alone. I have to increase logging limits for the RBAC and study system logs what happens. I also check how I can handle the niceness of the daemon. I will try to look into it tomorrow. At least disabling shm usage makes the original problem go away. I may also give a try for shm, just for checking out the inodes you've requested.
Pulseaudio will surely give me some headaches.

I increased the flood limit for grsec log. Unsuccessful attempts to raise niceness masked some error messages previously about pulseaudio failures to access /sys entries of devices and also blocked /dev/log write attempts. Now I could accommodate the policy. I also did some configuration modifications in asound.conf and pulseaudio config files. The sound system now works properly with pulseaudio as well. I didn't take the time to observe inode changes of /dev/shm - sorry.

Regards:
Dw.