Re: [gentoo-hardened] SELinux n00b questions

[Dale Pontius]

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?

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.

Another possiblity might be to us bind mounts instead of symlinks.
A peek around google suggested that "overlabeling" might be a
problem, but other than a nondescript/unused mount point, access
to the directories is exclusive. I'd prefer to keep the separation, and
I'd rather not crack into more partitions, since too many has always
given me slack space in the wrong partition.

>>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. 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.
Nor was there a file context entry for /usr/sbin/unix_chkpwd, although
"ls -Z /usr/sbin/unix_chkpwd" showed the right context. It just wasn't
"active???" For jollies, I copied /usr/sbin/unix_chkpwd to
/sbin/unix_chkpwd,
and did a "make relabel" and got the right label on it, and the file
context
is correct now. But still no-go on ssh while enforcing.

At this point, I'll mention that I'm using 2005.1, and one post dated
during the Summer mentioned that it wasn't quite ready for prime-
time. But given that there were 2004.1 and 2005.1 profiles available,
I had chosen the most recent.

>>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.

>>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 relable" while in enforcing mode? I inferred from the
handbook that it should be done before changing over.

>>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?

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.

Thanks for taking the time to answer. SELinux is a complex-looking
beast, and it's taken me some time to decide to jump in. I guess I'd
consider myself part of the "next wave" where less-than-experts
start to use it.

Dale Pontius
-- 
gentoo-hardened@g.o mailing list