Re: [gentoo-hardened] Can't get fully functional (kde) desktop with SELinux

[Paolo Barile]

Hello Sven, first of all, all the denials I wrote here are from
enforcing mode.

On 25/08/2012 19:24, Sven Vermeulen wrote:
> On Sat, Aug 25, 2012 at 07:00:09PM +0200, Paolo Barile wrote:
>> Hi Sven, thank you for rev4, but it didn't conclusively solve my
>> problems. Sone denial has gone, but many of them remain.
>>
>> So let's see again all the step by step denial, I'll avoid redundancies.
>>
>> As I boot (whithout starting xdm) I obtain:
>>
>> Aug 25 18:06:05 dell-studio kernel: [    8.028595] type=1400
>> audit(1345917944.027:3): avc:  denied  { search } for  pid=1433
>> comm="alsactl" name="root" dev="sda5" ino=1308163
>> scontext=system_u:system_r:alsa_t tcontext=system_u:object_r:default_t
>> tclass=dir
> This sais /root is default_t again. Mine sais:
>
> ~ # matchpathcon /root
> /root   root:object_r:user_home_dir_t
>
> ~ # grep '/root' /etc/selinux/strict/contexts/files/file_contexts* | grep user_home_dir_t
> /etc/selinux/strict/contexts/files/file_contexts.homedirs:/root -d root:object_r:user_home_dir_t

The same gives me nothing.

>
> It is because /root is marked as a home directory of a user that a hole set
> of contexts is generated for it. Perhaps for a targeted system this is
> different, but I don't think so.
>
> Whenever you hit a denial with file_t or default_t in it, it means there is
> something awry with the contexts on the system.
>
> You might be able to fix it by running genhomedircon (without options). It
> should regenerate the file context as mentioned in my grep result above.
genhomedircon doesn't change anything.

>
>> Aug 25 18:06:05 dell-studio kernel: [    8.707035] type=1400
>> audit(1345917944.706:7): avc:  denied  { read } for  pid=1431
>> comm="alsactl" name="urandom" dev="tmpfs" ino=3356
>> scontext=system_u:system_r:alsa_t
>> tcontext=system_u:object_r:urandom_device_t tclass=chr_file
> Did you enable global_ssp (or are you not running a hardened system, just
> SELinux)? By enabling the global_ssp boolean, all domains get access to the
> urandom_device_t chr_file:
>
> ~ # sesearch -s alsa_t -t urandom_device_t -A -C
> Found 2 semantic av rules:
> DT allow nsswitch_domain urandom_device_t : chr_file { ioctl read getattr lock open } ; [ authlogin_nsswitch_use_ldap ]
> ET allow domain urandom_device_t : chr_file { ioctl read getattr lock open } ; [ global_ssp ]
No, it isn't. I did not enabled it because I'm still not in hardened
because I'd want let selinux comletely work before the conversion.

>
>> Aug 25 18:06:05 dell-studio kernel: [    8.707053] type=1400
>> audit(1345917944.706:9): avc:  denied  { read } for  pid=1431
>> comm="alsactl" name="random" dev="tmpfs" ino=1642
>> scontext=system_u:system_r:alsa_t
>> tcontext=system_u:object_r:random_device_t tclass=chr_file
> This one is new for me. If it is prohibiting alsa to work, we'll need to
> allow this, but I think you're booting in permissive mode, so we can't know
> for sure if the denial is cosmetic or not.
As I wrote, everything is already in enforcing moe.
>
>> Aug 25 18:06:05 dell-studio kernel: [    8.707089] type=1400
>> audit(1345917944.706:11): avc:  denied  { getattr } for  pid=1431
>> comm="alsactl" name="/" dev="tmpfs" ino=2970
>> scontext=system_u:system_r:alsa_t tcontext=system_u:object_r:tmpfs_t
>> tclass=filesystem
> Which file system is it trying to get attributes from here?
>
>> Aug 25 18:06:05 dell-studio kernel: [   16.930444] type=1400
>> audit(1345910753.814:32): avc:  denied  { module_request } for  pid=1517
>> comm="cryptsetup" kmod="cbc(aes)" scontext=system_u:system_r:lvm_t
>> tcontext=system_u:system_r:kernel_t tclass=system
>> Aug 25 18:06:05 dell-studio kernel: [   16.930452] type=1400
>> audit(1345910753.814:33): avc:  denied  { module_request } for  pid=1517
>> comm="cryptsetup" kmod="cbc(aes)-all" scontext=system_u:system_r:lvm_t
>> tcontext=system_u:system_r:kernel_t tclass=system
>> Aug 25 18:06:05 dell-studio kernel: [   16.930505] type=1400
>> audit(1345910753.814:34): avc:  denied  { module_request } for  pid=1517
>> comm="cryptsetup" kmod="cbc(aes-asm)" scontext=system_u:system_r:lvm_t
>> tcontext=system_u:system_r:kernel_t tclass=system
>> Aug 25 18:06:05 dell-studio kernel: [   16.930512] type=1400
>> audit(1345910753.814:35): avc:  denied  { module_request } for  pid=1517
>> comm="cryptsetup" kmod="cbc(aes-asm)-all"
>> scontext=system_u:system_r:lvm_t tcontext=system_u:system_r:kernel_t
>> tclass=system
>> Aug 25 18:06:05 dell-studio kernel: [   16.936081] type=1400
>> audit(1345910753.820:36): avc:  denied  { getattr } for  pid=1517
>> comm="cryptsetup" name="/" dev="tmpfs" ino=2970
>> scontext=system_u:system_r:lvm_t tcontext=system_u:object_r:tmpfs_t
>> tclass=filesystem
>> Aug 25 18:06:05 dell-studio kernel: [   17.138342] type=1400
>> audit(1345910754.022:38): avc:  denied  { read } for  pid=1538
>> comm="cryptsetup" name="queue.bin" dev="tmpfs" ino=4265
>> scontext=system_u:system_r:lvm_t
>> tcontext=system_u:object_r:udev_var_run_t tclass=file
>> Aug 25 18:06:05 dell-studio kernel: [   27.701565] type=1400
> The cryptsetup stuff might need some more updates, I only use cryptsetup for
> a small encrypted partition (and not a system partition) and I have most of
> the stuff in-kernel anyway, so no module requests here...
>
> We'll need to look at this when you boot in enforcing mode, since I need the
> error message(s) as well in order to update the policy.
>
> Same is true for most of the remaining denials btw. Some of them definitely
> need to be looked at in advance, like the next set, but most of them will
> need to be reproduced with enforcing mode...
>
>> audit(1345910765.120:46): avc:  denied  { getattr } for  pid=1998
>> comm="console-kit-dae" path="/run/ConsoleKit" dev="tmpfs" ino=5251
>> scontext=system_u:system_r:consolekit_t
>> tcontext=system_u:object_r:initrc_var_run_t tclass=dir
> Need to add in this run directory, haven't done that yet.
>
>> Aug 25 18:06:05 dell-studio kernel: [   28.632129] type=1400
>> audit(1345910765.516:48): avc:  denied  { execute } for  pid=2089
>> comm="dbus-daemon-lau" name="polkitd" dev="sda5" ino=922900
>> scontext=system_u:system_r:system_dbusd_t
>> tcontext=system_u:object_r:policykit_exec_t tclass=file
> Probably needs to be made a dbus domain.
>
>> Aug 25 18:06:06 dell-studio kernel: [   29.168487] type=1400
>> audit(1345910766.052:52): avc:  denied  { write } for  pid=2222
>> comm="mii-tool" path="/run/lock/lmt-req.lock" dev="tmpfs" ino=5314
>> scontext=system_u:system_r:ifconfig_t
>> tcontext=system_u:object_r:var_lock_t tclass=file
>> Aug 25 18:06:06 dell-studio kernel: [   29.168499] type=1400
>> audit(1345910766.052:53): avc:  denied  { write } for  pid=2222
>> comm="mii-tool" path="/run/lock/lmt-invoc.lock" dev="tmpfs" ino=4776
>> scontext=system_u:system_r:ifconfig_t
>> tcontext=system_u:object_r:var_lock_t tclass=file
> Probably legit, but I'm not sure if I need to create an ifconfig_lock_t type
> for this, or just grant in var_lock_t access. Probably the former.
>
>> After logging in, apart all the same mentioned above that repeat
>> themselves, I get a lot of:
>> Aug 25 18:10:25 dell-studio kernel: [  289.004361] type=1400
>> audit(1345911025.905:163): avc:  denied  { search } for  pid=1968
>> comm="dbus-daemon" name="console" dev="tmpfs" ino=5945
>> scontext=system_u:system_r:system_dbusd_t
>> tcontext=system_u:object_r:consolekit_var_run_t tclass=dir
> What does the console dir contain? It's probably in /var/run/ConsoleKit
> (although from your earlier denials I get the impression /var/run/ConsoleKit
> is not correctly labeled, whereas in this denial it is - did you relabel the
> system or some parts of it in between?).

The console dir is outside ConsoleKit:

drwxr-xr-x. 2 root root  system_u:object_r:initrc_var_run_t           80
26 ago 11.32 ConsoleKit
drwxr-xr-x. 2 root root  system_u:object_r:consolekit_var_run_t       60
26 ago 11.32 console

It contains... nothing!

Anyway a restorecon -R /run changed contexts inside it:

drwxr-xr-x. 2 root root  system_u:object_r:consolekit_var_run_t       80
26 ago 11.32 ConsoleKit
drwxr-xr-x. 2 root root  system_u:object_r:pam_var_console_t          60
26 ago 11.32 console

Of course after the policies upgrade I relabeld all the system
(twice!)... But since the /run is a tmpfs dir, and since its contexts
are wrong, should I use the initramfs approach (restorecon before
switching to enforcing)?


>
> I recommend to first work on the default_t and file_t stuff. That shouldn't
> be broken. Then in the denials, look at any denials for "execute", they
> almost always need to be fixed (whereas getattr/read's can often be ignored,
> especially in the beginning).
>
> Then, when booted and logged in, clear the denial log and switch to
> enforcing mode and see what stuff breaks. Then look in the denial log for
> the denials, and give the error messages for the broken applications.
It's exactly what I did in the previous email, after every step I
cleared the log file
>
> When we fixed that, we should then look at the cryptsetup stuff, since you
> need that in order to boot succesfully I guess. Only then can we try to boot
> in enforcing mode (once, until it boots fully).
>
> Wkr,
> 	Sven Vermeulen
>
Thank you again Sven. Paolo.