Re: [gentoo-hardened] Unsolved AVCs on a hardened/linux/amd64/selinux

[Sven Vermeulen]

On Fri, Mar 02, 2012 at 11:13:17AM +0100, Vincent Brillault wrote:
> I've installed my first SELinux enhanced Gentoo Hardened a few days
> ago.

Congratulations! And thanks for sharing your experiences.

> A lot of avc appears in the logs and I fear that those would crash the
> server if I try to boot in enforcing mode.

It often helps to first boot in permissive, log on as root, run "id -Z" to
make sure you are in sysadm_t (if not, then enforcing will definitely not
work) and then switch to enforcing mode (setenforce 1) and play around a
bit. That way, you don't need to boot immediately in enforcing (that's the
next step).

> First of all, I think that the current policy lakes a context rules for
> ip6tables, I fixed it by adding the following rule (The context used
> here comes from /var/lib/iptables):
> /var/lib/ip6tables(/.*)?    gen_context(system_u:object_r:initrc_tmp_t)

Correct, I'll have this added in rev 5.

> Then, another rule seems to be missing from nginx. I think it's caused
> by a the following line in my configuration: “include
> /etc/nginx/vhosts.d/*.conf;” that result in :
> Mar  2 11:10:47 ***** kernel: [  968.008780] type=1400
> audit(1330683047.439:55): avc:  denied  { read } for  pid=2257
> comm="nginx" name="vhosts.d" dev="sda1" ino=393764
> scontext=system_u:system_r:nginx_t
> tcontext=system_u:object_r:nginx_conf_t tclass=dir
>
> I added the following rule to resolve this avc:
> allow nginx_t nginx_conf_t:dir read;

Correct. I'll add in a "list_dirs_pattern" for this, which includes the read
privilege. Will be included in rev 5.

> I don't have enough experience to understand the following avcs that
> come after every boot (after I log in) :

I'll give feedback on a few, but it would be nice if we could tackle them
one by one, preferably also a bit later when you could (try to) boot in
enforcing mode.

The problem with debugging in permissive is that the system behavior is
different. An earlier denial in enforcing mode might already prevent other
denials to be reached. And it doesn't mean that that denial is wrong - some
things we notice when enabling SELinux is that many applications have weird
behavior...

> Mar  2 10:54:51 ***** kernel: [    3.669361] type=1400
> audit(1330682082.668:3): avc:  denied  { getattr } for  pid=736
> comm="mount" name="/" dev="sysfs" ino=1
> scontext=system_u:system_r:mount_t tcontext=system_u:object_r:sysfs_t
> tclass=filesystem
[... snip other getattr on sysfs_t filesystem class ...]

I have these too, not sure yet why they would be needed. I have yet to play
around and see what the difference is in behavior when enabling or
dontauditing this.

I know that recent GLIBCs do a bit more with sysfs almost by default, but I
thought that was about checking the CPU information, not getting attributes
on the file system...

> Mar  2 10:54:51 ***** kernel: [    7.767982] type=1400
> audit(1330682087.198:6): avc:  denied  { setsched } for  pid=1010
> comm="mount" scontext=system_u:system_r:mount_t
> tcontext=system_u:system_r:kernel_t tclass=process

Hmm, don't have these here.

> Mar  2 10:54:51 ***** kernel: [    8.354336] type=1400
> audit(1330682087.785:7): avc:  denied  { write } for  pid=1062 comm="rm"
> name="console" dev="sda1" ino=423795 scontext=system_u:system_r:initrc_t
> tcontext=system_u:object_r:lib_t tclass=dir

Any idea what it is trying to delete here? I think it is something in
/lib(64)/rc/console (gut feeling) but I don't know what it is. At least, I
don't get those, but that might be because the system doesn't get here in
enforcing mode (i.e. earlier denials are prohibiting it from reaching this
point).

> Mar  2 10:54:51 ***** kernel: [    8.354358] type=1400
> audit(1330682087.785:8): avc:  denied  { remove_name } for  pid=1062
> comm="rm" name="keymap" dev="sda1" ino=393305
> scontext=system_u:system_r:initrc_t tcontext=system_u:object_r:lib_t
> tclass=dir
> Mar  2 10:54:51 ***** kernel: [    8.354373] type=1400
> audit(1330682087.785:9): avc:  denied  { unlink } for  pid=1062
> comm="rm" name="keymap" dev="sda1" ino=393305
> scontext=system_u:system_r:initrc_t tcontext=system_u:object_r:lib_t
> tclass=file

I think these are related with the earlier one.

> Mar  2 10:54:51 ***** kernel: [    8.365926] type=1400
> audit(1330682087.796:10): avc:  denied  { create } for  pid=1063
> comm="mkdir" name=".test.1056" scontext=system_u:system_r:initrc_t
> tcontext=system_u:object_r:var_run_t tclass=dir

This means an init script (source context is "initrc_t") is trying to create
a directory most likely in /var/run. If you could find out which init script
it is? Creating temporary directories there isn't exactly a good practice,
even though I think it is merely checking (in the init script) if the script
can write there.

> Mar  2 10:54:51 ***** kernel: [    8.719682] type=1400
> audit(1330682088.150:11): avc:  denied  { getattr } for  pid=1175
> comm="fuser" path="socket:[1859]" dev="sockfs" ino=1859
> scontext=system_u:system_r:initrc_t tcontext=system_u:system_r:udev_t
> tclass=unix_stream_socket

Probably /etc/init.d/bootmisc (as it is the only feasible init script that
calls fuser) that finds stuff in /var/run and wants to clean them. 

[... snip many other denials ...] 
> I think something about /sys mount point is missing in my fstab but I'm
> unable to find anything about that in the web.

Don't worry, /sys is mounted by default even if you don't define it in your
/etc/fstab.

For more information about SELinux bug reporting, please see
http://www.gentoo.org/proj/en/hardened/selinux-bugreporting.xml

Wkr,
	Sven Vermeulen