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: >>[EMAIL PROTECTED] ~ $ ssh -v [EMAIL PROTECTED] >> >> > >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 -- [email protected] mailing list
