Re: [gentoo-hardened] Newbee alarm....

[Sven Vermeulen]

On Thu, Nov 03, 2011 at 01:22:40AM +0100, Nico Baggus wrote:
> Well.. at least is nice to introduce one-self.
>
> Hi, I am a self-employed OpenVMS Cluster/systems manager by profession and
> run some linux on the side.
>
> I am new to selinux on gentoo although I run Gentoo for some years now
> after migrating from some Slackware based mess, through Redhat (until 9),
> and felt at home with gentoo.
>
> I started using hardened recently and found quite some messages in the
> audit log... enough to not warrent moving to enforcing.
>
> I'll post some findings after this.

Hi Nico,

Welcome in the world of Security Enhanced Linux. I am very glad to see you
are trying to get it working, and I can promise you that it will be a
challenging road. SELinux is a Mandatory Access Control system that is very
flexible, yet also very cumbersome and detailed. 

Now, in your other mails you are focusing on the AVC logs that you got from
running in permissive mode. That is fine, but will also cloud your view on
what you need and what you see. After all, there could be AVC denials that
are cosmetic (you should ignore them).

But the most difficult part you'll notice is to "read" these AVC denials. It
is not sufficient to just run audit2allow against them all and hope for the
best. If you do that, your system might work for a while, but you could have
opened up privileges that shouldn't be there in the first place.

For that reason, it is *very* *important* to look at each denial by itself,
figure out what is happening here, look for related denials and only /then/
on how to resolve it.

For instance, look at the following denials (I picked two from a whole bunch
since those two are related):

{ create } comm="mkdir" name=".test.1390"
scontext=system_u:system_r:initrc_t
tcontext=system_u:object_r:var_log_t tclass=dir  

{ rmdir } comm="rmdir" name=".test.1390" dev=vda4 ino=16285
scontext=system_u:system_r:initrc_t tcontext=system_u:object_r:var_log_t
tclass=dir

You can imagine them being related since they both work on the same object
(a directory called ".test.1390"). Also, because of the name syntax, it is
probably created using mktemp or so. And since the context of the directory
is var_log_t, it is easily deducable that it is in /var/log.

As it turns out, these rules are triggered by /etc/init.d/bootmisc (hence
the source context of initrc_t) which tests to see if it can write to a
directory (/var/log). Although I can think this is a wrong approach here
(after all, the bootmisc script doesn't seem to create directories in
/var/log, only files like /var/log/dmesg) it is something that is a "valid"
situation.

Resolving this can be done in three ways (well, there are probably more)

(1.) Have bootmisc updated so that /var/log isn't "tested" with the
     "dir_writeable" check, but with a proper file create check
(2.) Have initrc_t enhanced so that it can create initrc_var_log_t labeled
     directories, and give it the proper privileges to create such directories
(3.) Give initrc_t the manage privileges for var_log_t directories (which is
     somewhat what would happen if we throw audit2allow against the lines)

These are also in order of preference. As you can see, (3.) is last (but
easiest).

For each denial we get, we need to perform a similar analysis. Just pointing
out which denials we get isn't enough (but it is a start). Showing the
audit2allow "fixes" doesn't help us with anything though :-( They are meant
as a resolution, but since we do not know the problem we can't just accept
that.

For many denials, I personally also require that they are reproduced when
running in enforcing mode. Initially, that might not be possible on your
system so we first need to focus then on the denials that are "more
obvious".

If you ever want to try out enforcing mode, just boot in permissive, log in
as root and ensure that "id -Z" returns something like
"root:sysadm_r:sysadm_t", and *not* kernel_t, initrc_t, locallogin_t or
anything else. Only when your context is sysadm_t, then you can run
"setenforce 1" to switch to enforcing mode.

Keep that terminal logged on, work around a bit. If you get stuck, switch
back to the terminal, type in "setenforce 0" and you are back in permissive.

Wkr,
	Sven Vermeulen