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
--
[email protected] mailing list
