From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from lists.gentoo.org ([140.105.134.102] helo=robin.gentoo.org) by nuthatch.gentoo.org with esmtp (Exim 4.50) id 1EbTYp-00040x-7i for garchives@archives.gentoo.org; Mon, 14 Nov 2005 01:55:07 +0000 Received: from robin.gentoo.org (localhost [127.0.0.1]) by robin.gentoo.org (8.13.5/8.13.5) with SMTP id jAE1rRBf013378; Mon, 14 Nov 2005 01:53:27 GMT Received: from mta4.adelphia.net (mta4.adelphia.net [68.168.78.184]) by robin.gentoo.org (8.13.5/8.13.5) with ESMTP id jAE1rPbc006795 for ; Mon, 14 Nov 2005 01:53:26 GMT Received: from homer.edgehp.net ([69.171.210.251]) by mta11.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with ESMTP id <20051114015112.SFVD19306.mta11.adelphia.net@homer.edgehp.net> for ; Sun, 13 Nov 2005 20:51:12 -0500 Received: from [192.168.154.40] (anastasia.edgehp.net [192.168.154.40]) by homer.edgehp.net (Postfix) with ESMTP id 3BE695A89D for ; Sun, 13 Nov 2005 20:49:19 -0500 (EST) Message-ID: <4377ED93.2090408@edgehp.net> Date: Sun, 13 Nov 2005 20:51:15 -0500 From: Dale Pontius User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.7.12) Gecko/20050920 X-Accept-Language: en-us, en Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-hardened@gentoo.org Reply-to: gentoo-hardened@lists.gentoo.org MIME-Version: 1.0 To: gentoo-hardened@lists.gentoo.org Subject: Re: [gentoo-hardened] SELinux n00b questions References: <435A6E83.15754.A4A6C273@pageexec.freemail.hu> <435A7CA9.4596.A4DE07A0@pageexec.freemail.hu> <1129999068.31615.69.camel@localhost.localdomain> <1130002276.8908.28.camel@alto> <1130002902.5415.5.camel@localhost.localdomain> <1130004616.8908.38.camel@alto> <435BCE52.2060503@edgehp.net> <1130367544.20289.21.camel@gorn.pebenito.net> <43602E6A.5090505@edgehp.net> <1130728797.25301.67.camel@gorn.pebenito.net> In-Reply-To: <1130728797.25301.67.camel@gorn.pebenito.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Archives-Salt: 814f0c06-e879-4566-898b-1dcfdf138d21 X-Archives-Hash: a1ef94205a110f3c9290bf8067025e03 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: > > > >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) > > > >> 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. >>>>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@gentoo.org mailing list