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
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.
> 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 ]
> 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.
> 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?).
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.
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
