From: cpebenito@tresys.com (Christopher J. PeBenito)
Date: Fri, 19 Feb 2010 14:01:42 -0500
Subject: [refpolicy] Changing build.conf defaults?
In-Reply-To: <4B7EDE7D.8030405@gmail.com>
References: <1266602439.32011.88.camel@moss-pluto.epoch.ncsc.mil>
	<1266603950.11694.188.camel@gorn.columbia.tresys.com>
	<1266575669.5199.10.camel@linux-dbym.site>
	<1266604986.11694.193.camel@gorn.columbia.tresys.com>
	<4B7EDE7D.8030405@gmail.com>
Message-ID: <1266606102.11694.196.camel@gorn.columbia.tresys.com>
To: refpolicy@oss.tresys.com
List-Id: refpolicy.oss.tresys.com

On Fri, 2010-02-19 at 10:54 -0800, Justin P. mattock wrote:
> On 02/19/2010 10:43 AM, Christopher J. PeBenito wrote:
> > On Fri, 2010-02-19 at 02:34 -0800, Justin P. Mattock wrote:
> >> On Fri, 2010-02-19 at 13:25 -0500, Christopher J. PeBenito wrote:
> >>> On Fri, 2010-02-19 at 13:00 -0500, Stephen Smalley wrote:
> >>>> I was wondering whether it would make sense to change the refpolicy
> >>>> build.conf defaults to more closely reflect the actual settings in use
> >>>> in modern distributions.  In particular, I was thinking that we are long
> >>>> past the point where it makes sense to make MONOLITHIC=n the default
> >>>> given that:
> >>>> - all modern distros with SELinux use modular/managed policy, and
> >>>> - semodule, semanage, and even setsebool -P will only work if using
> >>>> modular/managed policy these days.
> >>>>
> >>>> Changing the default would eliminate at least one case of common user
> >>>> error when building from upstream refpolicy on a modern distribution.
> >>>>
> >>>> Any objections to changing that default upstream?
> >>>
> >>> I don't.  But I'll wait for a while before changing it to see if anyone
> >>> objects.
> >>
> >> no objections here.
> >> building a binary policy is easier
> >> than monolithic(especially in a distro environment).
> >> i.g. no need for the source to add user/login
> >> just semanage.
> >
> > One thing that I had always hoped was that semanage_expand would be able
> > to output all of the necessary files, so that a monolithic build in
> > refpolicy would just be a superset of modular build.  In other words, a
> > monolithic refpolicy build would build a modular policy then link and
> > expand the modules.  Then a lot of the makefile complexity could be
> > dropped.  However, semodule_expand doesn't output file_contexts, at a
> > minimum.
> >
> 
> 
> been using monolithic for a while, and just sat down
> and got the whole binary build up and running
> (still a bit hazzy with the user/login).
> 
> but in regards to what(hopefully I'm seeing this)your saying
> is if loading a monolithic have semanage have the ability to
> example: /usr/sbin/semanage -DB to a monolithic and/or adjust user/login.
> just like binary without the need for the source.
> (well need for the source to do the initial install)
> 
> if so.. that would be nice, i.g. with the suse thing
> they have monolithic(if above was possible)I would not have had to
> download any source to add login/user etc... just make the changes there 
> on the spot like binary.

No, I'm just speaking of the build environment, not runtime.  I should
have responded to my previous email rather than to yours.

-- 
Chris PeBenito
Tresys Technology, LLC
(410) 290-1411 x150