From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <46CC8233.7020605@redhat.com> Date: Wed, 22 Aug 2007 14:36:35 -0400 From: Daniel J Walsh MIME-Version: 1.0 To: jwcart2@tycho.nsa.gov CC: "Christopher J. PeBenito" , SELinux , Steve Smalley Subject: Re: Question concerning building policy modules References: <1187203804.26375.69.camel@moss-lions.epoch.ncsc.mil> <46CB51E8.5020603@redhat.com> <1187800281.20340.34.camel@moss-lions.epoch.ncsc.mil> <46CC68D4.3070001@redhat.com> <1187802068.20340.46.camel@moss-lions.epoch.ncsc.mil> In-Reply-To: <1187802068.20340.46.camel@moss-lions.epoch.ncsc.mil> Content-Type: text/plain; charset=ISO-8859-1 Sender: owner-selinux@tycho.nsa.gov List-Id: selinux@tycho.nsa.gov -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 James Carter wrote: > On Wed, 2007-08-22 at 12:48 -0400, Daniel J Walsh wrote: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> James Carter wrote: >>> On Tue, 2007-08-21 at 16:58 -0400, Daniel J Walsh wrote: >>>> James Carter wrote: >>>>> Why isn't the Makefile and other information needed to build a module >>>>> separately in the appropriate /usr/share/selinux/ >>>>> directory? This seems like the logical place for that information. The >>>>> (not very well documented) "install-headers" make target in the >>>>> refpolicy Makefile does this. >>>>> >>>>> Instead, the information to build a module for Fedora is in >>>>> the /usr/share/selinux/devel directory. This directory would seem to be >>>>> independent of the policy type, even though it is only for building >>>>> Fedora policies. This seems confusing. The devel directory should have >>>>> stuff that all policies need or could use. >>>>> >>>>> Wouldn't it make sense that if I wanted to build a module for the >>>>> current policy, I would use the Makefile in devel which would look >>>>> at /etc/selinux/config and include the Makefile for the current policy, >>>>> but if I wanted to compile for a particular policy, I would just use the >>>>> Makefile in its /usr/share directory? >>>>> >>>>> >>>> This is an old argument, between strict and targeted policy. I did not >>>> like the idea of building >>>> policy modules different for each type of policy, Since almost everyone >>>> is exactly the same or would not work on different policies. This seems >>>> to be proven to be correct as we move to strict/targeted policy merge. >>>> >>>> So you add a level of complexity with very little value. Just imagine a >>>> third party shipping multiple policies for the >>>> same package depending on an infinite number of policy packages. >>>> >>>> targeted, strict, mls, olpc, CDS-ABC. >>>> >>>> And almost guaranteed the same policy package would work for all or the >>>> package will only really work on one (MLS). So I went with the least >>>> common denominator and only ship one devel package. All interfaces for >>>> all packages ship. >>> On a different note, what is the policy going to be called when the >>> difference between strict and targeted is only whether a certain module >>> is loaded or not? Will there only be one policy package? Or maybe >>> there will be policy-mcs and policy-mls packages? >>> >>> >> We will be shipping just targeted policy and allow you to define any >> types of users you want. > > Steve tells me that the name "targeted" is not going away, since > libselinux uses that name as the default policy name. > >> Removing the unconfined.pp file will remove >> all of the unconfined domains. As an alternative, you can change the >> __default__ to a confined user type and then not allow users to login as >> unconfined users. (I find this much more interesting.) > > It is. > Is it working now? I was under the impression that there were still some issues to be worked out. > I don't know what you mean by is is working now? Rawhide-F8/Test1 policy has my version of the strict/targeted merge. It supports login user types of unconfined_t, sysadm_t, staff_t, user_t as well as guest_t (terminal only, least priv user), and xguest_t (Xwindows Least Priv user, with Firefox transition) As well as super user types logadm_t, webadm_t, auditadm_t. I have not tried to remove the unconfined.pp to see what happens. I have removed a lot of unconfined domains in this version of policy. (gdm, xdm, ldconfig, modutils, sshd) are all confined now. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFGzIIyrlYvE4MpobMRAoyCAJ0QNoCi/izOsnqxQ1iesJcHwZc1jACfSd6B EHwfeh+hdyThXIL+d1asnx8= =HwSZ -----END PGP SIGNATURE----- -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with the words "unsubscribe selinux" without quotes as the message.