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)
