Re: [gentoo-hardened] SELinux n00b questions

[Chris PeBenito]

On Wed, 2005-10-26 at 21:33 -0400, Dale Pontius wrote:
> Chris PeBenito wrote:
> >On Sun, 2005-10-23 at 13:54 -0400, Dale Pontius wrote:
> >
> >>I decided to remove it and install syslog-ng. That appeared to work at
> >>first. But as far as I can tell, nothing has been logged since the first
> >>time I put the systeminto enforcing mode.
> >
> >Need to see some denials to better understand whats going on.>
> >
> I get no denials. Once I go enforcing, I get no logging, whatsoever.
> Even after switching back to non-enforcing, logging doesn't start
> up, again.
>
> However, I think I've got a clue. My basic system has 4 partitions:
> / (root) - ext3
> swap
> /home - xfs (I planned for maildirs and news spool to end up, here.)
> /tmpvar - ext3
>
> I suspect the last entry is my problem. The tmpvar partition has
> 3 directories, tmp, var, and chroot. From the root directory, all
> 3 of those entries are symlinks into tmpvar. The idea was to keep
> root read-mostly, possibly read-only, and have the read/write stuff
> on tmpvar.
>
> However, if I do a ls -Z / and look at tmpvar, tmp, and var I see:
> lrwxr-xr-x  root     root     system_u:object_r:default_t      tmp
> (->../tmpvar/tmp)
> drwxr-xr-x  root     root     system_u:object_r:default_t      tmpvar
> lrwxr-xr-x  root     root     system_u:object_r:var_t          var
> (->../tmpvar/var)
> If I look inside /var, everything is system_u:object_r:default_t. I
> suspect that last part is wrong, and they should have been var_t.
>
> Does this sound like it might be my problem?

Default_t is a label you never want to see.  It means that when
labeling, the file had no match in file_contexts.  You need to add
matches for all of the files in /tmpvar/var and /tmpvar/tmp since they
are in nonstandard locations.  You can add them to
file_contexts/misc/local.fc (creating it is ok).  You can look at the
other .fc's for more info.

> One workaround might be to mount the volume as /var, and then
> symlink /tmp and /chroot into directories there, since they appear
> to have no special labelling.

No, you'll just have to have a different nonstandard labeling
configuration.  /var will be right, but you'll still have to add matches
for tmp and chroot.  However, this is probably the easiest to do,
since /tmp has few matches to fix whereas /var has many, and you have to
provide matches for /chroot anyway.

> Another possiblity might be to us bind mounts instead of symlinks.

This won't help in this case since setfiles will ignore bind mounts.

> >>2: Can't ssh in when the system is enforcing. I've checked the sestatus
> >>-v results, and everything looks ok. I've never seen a bogus console or
> >>log message, but then again, see (1). Here's what I get:
> >>user1@here ~ $ ssh -v user2@there
> >
> >Again, need to see some denials on the server, and logs from sshd if
> >they have anything interesting other than the failed login message.
> >
> Again, no logging, no denials.

Won't be able to fix this until logging is fixed.

>  I did notice one anomoly, going through
> the FAQ. Everything was correct according to "sestatus -v" except that
> there was no file context entry for /sbin/unix_chkpwd. In fact, there was
> no file at all called /sbin/unix_chkpwd, but there was a
> /usr/sbin/unix_chkpwd.

An entry for /usr/sbin/unix_chkpwd just needs to be added
in /etc/sestatus.conf.  /sbin/unix_chkpwd was moved to /usr/sbin.

> >>3: There isn't much about "standard practice".
> >>What kinds of admin tasks can I perform while the system is enforcing?
> >>What kinds of admin tasks do I have to drop out of enforcing for?
> >
> >The goal is to always enforce.  Ideally, you should never have to switch
> >to permissive to do admin tasks.
> >
> This includes updating packages? I believe I've seen something fly by
> about relabeling individual packages.

If you merge apache for example, but the apache policy isn't loaded,
it's files won't have the right context.  You have to relabel it before
using it, which is what you're being warned about.

> >>I presume emerging a new policy requres "make load". What requires "make
> >>relabel"?
> >
> >You should generally relabel after switching from permissive back to
> >enforcing.  That may also mean restarting if processes aren't in the
> >right context.  Other than that, you shouldn't need a complete relabel
> >except in recovery type situations.  Or massive policy changes.
> >
> >
> You do "make relabel" while in enforcing mode? I inferred from the
> handbook that it should be done before changing over.

Very much depends on the state of the system, and the circumstances.
Generally, the shorter amount of time in permissive, the better.

> >>What about things that don't have a policy? Like dovecot, leafnode, etc?
> >>On my old system I ran things chroot'ed. Can I still, under SELinux?
> >
> >Our policy is a little stagnant, since the NSA example policy will be on
> >its way out, and we will be switching to Reference Policy
> >(http://serefpolicy.sf.net/) when its ready in a couple months.  It will
> >be a significanly easier policy to manage and develop.  It'll also bring
> >along with it the targeted policy, for desktops.
> >
> >You can run stuff chrooted, but it will likely require extra policy work
> >to get things labeled right.  Though, with a good MAC system like
> >SELinux, the usefulness of chroot is questionable.
> >
> At some point I'd like to learn more about writing policy, if only
> because that may be what it takes to get leafnode support. In the
> meantime, will my software with no policy work, and what are the
> implications?

Any access that is not explicitly allowed is denied.  Without a proper
policy, the process will be running in some other context, and thus be
subject to those rules.  Unless its a pretty simple program, it will
most likely be broken.

> As for chroot, I'd like to consider SELinux another layer, not a silver
> bullet. That says I'd like to keep the chroot, even if it means doing
> the policy work myself, someday.

-- 
Chris PeBenito
<pebenito@g.o>
Developer,
Hardened Gentoo Linux
Embedded Gentoo Linux
 
Public Key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE6AF9243
Key fingerprint = B0E6 877A 883F A57A 8E6A  CB00 BC8E E42D E6AF 9243