Re: [gentoo-hardened] SELinux n00b questions

[Dale Pontius]

Most of this is replies to specific sections, below. But given greater 
functionality, I have
a new question, too.

I decided to try running BIND on the SELinux system. I get this message:
 * Starting named ...
named: capset failed: Operation not permitted: please ensure that the 
capset kernel module is loaded.  see insmod(8)

I've made sure that "commoncap" was built and loaded prior to trying to 
start BIND. A bit
of google searching, and this seemed to have helped everyone else, but 
not me. Or might
this be linked into the fact that I don't have /tmp properly labeled, 
yet? I don't see anything
in /tmp on this system, and looking with "lsof -c named" on another 
system currently
running BIND,I don't see any files in /tmp.

I'm not trying to chroot bind at this point, just get it running.

Chris PeBenito wrote:

> <snip>
>
>
>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.
>
>
Shuffling my partitions worked wonders. Logging now works, and I can ssh 
in while the
system is in enforcing mode. To date, I've just gotten the /var stuff 
into the right place. I
haven't fiddled with /tmp or /chroot yet, but things are much more 
functional. (But not
yet fully)

><snip>
>
>
>> 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.
>
>
I'd changed the entry in /etc/sestatus.conf, (and removed the 
/sbin/unix_chkpwd) and
I believe this is part of getting ssh running while in enforcing mode. 
But it brings up
another question... It appears to me that /etc/sestatus.conf is really 
derived when the
policy is compiled, and that I need to go into the original source in 
order to make this
change persist. Correct? At one point, I could have sworn I saw a 
notation like:
"(/usr)?/sbin/unix_chkpwd" that looks like it should have matched either
"/sbin/unix_chkpwd" or "/usr/sbin/unix_chkpwd". But looking now, I can't 
find it, and
it should have prevented my problem from ever happening.

Along those lines, I should go looking for /tmp and /chroot in the src 
tree, I presume?
Update there and "make load", etc?

>
>
>>>>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.
>
>
Now that I have the /var working right, I can "emerge sync" and "emerge 
-atuvDN world"
without problems. The system spends most of its time in enforcing mode.


<snip>

>>>>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.
>>>
>>>
I see where Fedora Core 3/4 has a policy for Dovecot. Is this likely 
based on the example
policy, in which case I could grab it and try working with it, or is FC4 
likely already on
the Reference Policy?

>>>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.
>>
>>
Just glancing through the policy source, I see where policy provisions 
are already made
for using named and dhcpd chrooted. Obviously I'll need to update for my 
mount mess.

Thanks,
Dale
-- 
gentoo-hardened@g.o mailing list