SElinux

[A.J. Bonnema]

Craig White wrote:
> SELinux stuff isn't hard. But it does take a few minutes of time and
> attention to deal with the 'blocks' that arise - but it is these
> 'blocks' that confirm why it's installed in the first place.
>
>   
Hi Craig,

I disagree. I appreciate the intentions of SELInux and I am focussed at 
understanding and learning SELinux. Possibly SELinux will become easier 
in time as it already has done in FC5. But it is not easy: for people 
like me, it is hard and it is more than a few minutes to "get" SELinux.

Even though I have read the intro of Dan Walsh, his presentation (and 
good word both are!), when I get to practise, I now know how to fix a 
problem. But what I don't know, is whether I am introducing security 
holes doing this.
I will give you two examples of why I think SELinux is tough.

Example1. Scanning my audit records I get avc-messages which I piped 
into audit2why in order to understand them:

type=AVC msg=audit(1143863788.355:233): avc:  denied  { write } for  
pid=5853 comm="squid" name="[35880]" dev=pipefs ino=35880 
scontext=user_u:system_r:squid_t:s0 
tcontext=user_u:system_r:unconfined_t:s0-s0:c0.c255 tclass=fifo_file
    Was caused by:
        Missing or disabled TE allow rule.
        Allow rules may exist but be disabled by boolean settings; check 
boolean settings.
        You can see the necessary allow rules by running audit2allow 
with this audit message as input.

type=AVC msg=audit(1143863788.355:233): avc:  denied  { write } for  
pid=5853 comm="squid" name="[35880]" dev=pipefs ino=35880 
scontext=user_u:system_r:squid_t:s0 
tcontext=user_u:system_r:unconfined_t:s0-s0:c0.c255 tclass=fifo_file
    Was caused by:
        Missing or disabled TE allow rule.
        Allow rules may exist but be disabled by boolean settings; check 
boolean settings.
        You can see the necessary allow rules by running audit2allow 
with this audit message as input.

type=AVC msg=audit(1143884764.330:326): avc:  denied  { write } for  
pid=18776 comm="squid" name="[79562]" dev=pipefs ino=79562 
scontext=user_u:system_r:squid_t:s0 
tcontext=user_u:system_r:unconfined_t:s0-s0:c0.c255 tclass=fifo_file
    Was caused by:
        Missing or disabled TE allow rule.
        Allow rules may exist but be disabled by boolean settings; check 
boolean settings.
        You can see the necessary allow rules by running audit2allow 
with this audit message as input.

type=AVC msg=audit(1143884764.330:326): avc:  denied  { write } for  
pid=18776 comm="squid" name="[79562]" dev=pipefs ino=79562 
scontext=user_u:system_r:squid_t:s0 
tcontext=user_u:system_r:unconfined_t:s0-s0:c0.c255 tclass=fifo_file
    Was caused by:
        Missing or disabled TE allow rule.
        Allow rules may exist but be disabled by boolean settings; check 
boolean settings.
        You can see the necessary allow rules by running audit2allow 
with this audit message as input.

Now, it seems obvious to me, that I can get rid of this message by 
running audit2allow and adding that to the policy. But before I do that, 
I would like to make a well thought through decision as to whether this 
poses a security risk if I fix it this way.

allow squid_t unconfined_t:fifo_file write;

Now: I have no idea, what the security implications of this is......

Example 2.

Apr  2 07:17:03 athene kernel: audit(1143955023.872:69): avc:  denied  { 
read write } for  pid=13366 comm="squid" name="rpmpkgs" dev=dm-0 
ino=11207591 scontext=system_u:system_r:squid_t:s0 
tcontext=system_u:object_r:var_log_t:s0 tclass=file
    Was caused by:
        Missing or disabled TE allow rule.
        Allow rules may exist but be disabled by boolean settings; check 
boolean settings.
        You can see the necessary allow rules by running audit2allow 
with this audit message as input.

Obviously, squid does something with rpmpkg..........?!

audit2allow says: allow squid_t var_log_t:file { read write };

But what am I doing here? I have really no idea.  Is it doing something 
to /var/log files or is it doing something to the packages? I will have 
to investigate more to understand this one.

So I don't know whether I should compile these allows into the policy 
(still have to check how to do that, but that's beside the point).
I simply don't know what the implications are. I don't even know if 
these are real problems.

My point being: SELinux is certainly worth understanding and worth the 
effort, but to some people (non-admins) it *is* tough.
SELinux may not be hard for the well seasoned admin, but it is for me 
(and I am putting in the effort and I am not finished by a long shot).

Guus.

-- 
A.J. Bonnema, Leiden The Netherlands,
user #328198 (Linux Counter http://counter.li.org)