selinux adventures/troubles

[Michal Jaegermann]

On Sat, Dec 27, 2008 at 06:43:58AM -0500, Daniel J Walsh wrote:
> Michal Jaegermann wrote:
> > 
> > So far, AFAICT, when installing a machine "from scratch", and while
> > keeping a layout as plain as possible, then selinux is rather
> > expected to work; at least decently enough.  The picture becomes
> > entirely diferent when you are trying to upgrade a distro.  What
> > results of such exercise will be I am unable to predict.
...
> > This works but I am getting every
> > time "Unable to get valid context for root" and in /var/log/secure:
> > "pam_selinux(sshd:session): Security context
> > system_u:system_r:logrotate_t:s0-s0:c0.c1023 is not allowed for
> > system_u:system_r:logrotate_t:s0-s0:c0.c1023".
> > Eh?  What this is supposed to mean?

> /root is supposed to be labelled admin_home_t and most confined
> applications are not allowed to read/write anything in this directory.

> So procmail_t should not be allowed by default to read/write
> admin_home_t.

As a matter of fact it was not and it is still not doing that.  Here
procmail is used to reclassify and to send further mail, using less
blunt means that an alias in /etc/aliases (and ensuring that any
"outside" mail to root would land in /dev/null), and in this
particular case it happens that none of these mails ends up in
subdirectories of /root/.  If and where procmail writes its
temporary files, which apparently triggered some complaints, I
really cannot tell without diving into sources.  Besides even if
root procmail would be storing some mails locally then who says that
it would have to do that below /root/?  Only this is not here nor
there.  I can work around this particular issue, although this would
add extra complications and in more involved cases such hacks would
be highly undesirable, but this was not the real question.  This was
just a specific example of what was triggered by an upgrade.

> If for some reason you want procmail to deliver files to
> root, you can add a custom module, as you seem to have indicated that
> you have.

Yes, I did and the only effect was a slight change in complaints
with 'allow2why' now playing dumb so now what I can do?

That still does not explain why I am seeing, for example,
"system_u:system_r:logrotate_t:s0-s0:c0.c1023 is not allowed for
system_u:system_r:logrotate_t:s0-s0:c0.c1023" with logwatch later
producing mulitiple "NULL security context for user, but SELinux in
permissive mode, continuing ()" and none of tools which I have
giving me any clues why.  It is possible that I do not know where
to look but I only see in audit.log entries with "res=failed"
immediately followed by "res=success" in the next line.  What
other catastrophies are still lurking there it remains to be seen.

The real question was why I am running an upgrade on one machine and
I am ending up with a disaster and apparently the same action
elsewhere has entirely different effects and if there is anything I
can do about it.  Only now you are implying that what works is
really broken.  That is nice to know.

> Why /root on the other machine is labeled user_home_t is a
> bug.  Not sure why this is happening.  Do you have an entry in your
> /etc/passwd with a UID > 500 with /root as a home dir?

Of course not.  The only entries in /etc/passwd with /root for
a home directory look as follows:

root:x:0:0:root:/root:/bin/bash
operator:x:11:0:operator:/root:/sbin/nologin

> I have changed
> the tools that setup homedir labeling to not modify /root but I am not
> sure if this has gotten into F10 yet.

I only know that running 'restorecon -Rv /root' on either of these
two "example" machine does not change anything even if labelling is
different.  OTOH in none of these cases an initial labelling was
created "by hand".

> The reason we want to protect /root from confined domains, is to stop
> them from modifying /root/.bashrc or other files that the admin could be
> tricked into executing.

The old principle says "if you will disallow dumb things then you
will block smart things as well" and necessity of complicated
workarounds open its own security holes - possibly more disastrous
than what you were trying to guard against in the first place.

   Michal