RE: db conflict ?

RE: db conflict ?

[Westerman, Mark]

While we are on the subject.

Could you think about placing the policy sources
into the /usr/local/selinux Directory

(i.e.
	/usr/local/selinux/policy
	/usr/local/selinux/setfiles
	/usr/local/selinux/share/doc/examples/policy
	/usr/local/selinux/share/doc/examples/setfiles


For new version of selinux the install could look and 
see if there is a /usr/local/selinux/policy and setfiles
if the directories are present the install will populate then
with the example policy. If the directories are present just
overwrite the /usr/local/selinux/share/doc/example files.


Mark  

--
You have received this message because you are subscribed to the selinux 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.

Re: db conflict ?

[Russell Coker]

On Fri, 12 Apr 2002 19:37, Westerman, Mark wrote:
> Could you think about placing the policy sources
> into the /usr/local/selinux Directory
>
> (i.e.
> 	/usr/local/selinux/policy
> 	/usr/local/selinux/setfiles
> 	/usr/local/selinux/share/doc/examples/policy
> 	/usr/local/selinux/share/doc/examples/setfiles

I don't like any of that.

/usr/local is for the local sysadmin to copy files into, not for packaged 
software.

> For new version of selinux the install could look and
> see if there is a /usr/local/selinux/policy and setfiles
> if the directories are present the install will populate then
> with the example policy. If the directories are present just
> overwrite the /usr/local/selinux/share/doc/example files.

That's mostly what I'm doing with my Debian packages, but with /etc/selinux.

-- 
If you send email to me or to a mailing list that I use which has >4 lines
of legalistic junk at the end then you are specifically authorizing me to do
whatever I wish with the message and all other messages from your domain, by
posting the message you agree that your long legalistic sig is void.

--
You have received this message because you are subscribed to the selinux 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.

RE: db conflict ?

[Stephen Smalley]

On Fri, 12 Apr 2002, Westerman, Mark wrote:

> Could you think about placing the policy sources
> into the /usr/local/selinux Directory
>
> For new version of selinux the install could look and
> see if there is a /usr/local/selinux/policy and setfiles
> if the directories are present the install will populate then
> with the example policy. If the directories are present just
> overwrite the /usr/local/selinux/share/doc/example files.

This is fine with me.  It merely involves adding a new target to the
policy and setfiles Makefiles to install the sources for the
configurations and then adjusting the README and quickinstall target to
include that step.

--
Stephen D. Smalley, NAI Labs
ssmalley@nai.com




--
You have received this message because you are subscribed to the selinux 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.

Re: db conflict ?

[Russell Coker]

On Fri, 12 Apr 2002 21:17, Stephen Smalley wrote:
> On Fri, 12 Apr 2002, Westerman, Mark wrote:
> > Could you think about placing the policy sources
> > into the /usr/local/selinux Directory
> >
> > For new version of selinux the install could look and
> > see if there is a /usr/local/selinux/policy and setfiles
> > if the directories are present the install will populate then
> > with the example policy. If the directories are present just
> > overwrite the /usr/local/selinux/share/doc/example files.
>
> This is fine with me.  It merely involves adding a new target to the
> policy and setfiles Makefiles to install the sources for the
> configurations and then adjusting the README and quickinstall target to
> include that step.

This is no benefit for me, and may actually just add work as I have to remove 
your code.

To do this in Debian packages I have to do this all myself, and I expect that 
the same applies to RPMs.  So essentially if you do the same thing in the 
upstream you'll possibly benefit Slackware users, but no-one else.

Also we need more than this.  We need code to detect changes in the sample 
policy and to offer the users conveniant ways of tracking them.

-- 
If you send email to me or to a mailing list that I use which has >4 lines
of legalistic junk at the end then you are specifically authorizing me to do
whatever I wish with the message and all other messages from your domain, by
posting the message you agree that your long legalistic sig is void.

--
You have received this message because you are subscribed to the selinux 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.

Re: db conflict ?

[Howard Holm]

Bringing up again a proposal of mine from April 3rd, I suggest that we
put the "example" policy in /usr/share/selinux/policy/default/ and
compile the policy in automated scripts from
/usr/share/selinux/policy/current/.  When creating current, it should
be a link to default.  If the admin changes the link or removes it
in favor of an actuall local directory then all that happens when an
automated script installs new default policy language and recompiles
and installs "current" is that the real current policy is reinstalled
if it is different than the default.  If it is a link to the default,
then the updated default policy is compliled and installed.  This
seems to be a good compromise between not arbitrarily replacing a
local administrative policy while still allowing the majority of
people who use the default policy to have it automatically maintained
and added to when adding new packages.

On Fri, Apr 12, 2002 at 10:11:48PM +0200, Russell Coker wrote:
> On Fri, 12 Apr 2002 21:17, Stephen Smalley wrote:
> > On Fri, 12 Apr 2002, Westerman, Mark wrote:
> > > Could you think about placing the policy sources
> > > into the /usr/local/selinux Directory
> > >
> > > For new version of selinux the install could look and
> > > see if there is a /usr/local/selinux/policy and setfiles
> > > if the directories are present the install will populate then
> > > with the example policy. If the directories are present just
> > > overwrite the /usr/local/selinux/share/doc/example files.
> >
> > This is fine with me.  It merely involves adding a new target to the
> > policy and setfiles Makefiles to install the sources for the
> > configurations and then adjusting the README and quickinstall target to
> > include that step.
> 
> This is no benefit for me, and may actually just add work as I have to remove 
> your code.
> 
> To do this in Debian packages I have to do this all myself, and I expect that 
> the same applies to RPMs.  So essentially if you do the same thing in the 
> upstream you'll possibly benefit Slackware users, but no-one else.
> 
> Also we need more than this.  We need code to detect changes in the sample 
> policy and to offer the users conveniant ways of tracking them.

--
Howard Holm <hdholm@epoch.ncsc.mil>
Secure Systems Research Office
National Security Agency

--
You have received this message because you are subscribed to the selinux 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.

Re: db conflict ?

[Russell Coker]

On Fri, 12 Apr 2002 22:25, Howard Holm wrote:
> Bringing up again a proposal of mine from April 3rd, I suggest that we
> put the "example" policy in /usr/share/selinux/policy/default/ and
> compile the policy in automated scripts from
> /usr/share/selinux/policy/current/.  When creating current, it should
> be a link to default.  If the admin changes the link or removes it
> in favor of an actuall local directory then all that happens when an
> automated script installs new default policy language and recompiles
> and installs "current" is that the real current policy is reinstalled
> if it is different than the default.  If it is a link to the default,
> then the updated default policy is compliled and installed.  This
> seems to be a good compromise between not arbitrarily replacing a
> local administrative policy while still allowing the majority of
> people who use the default policy to have it automatically maintained
> and added to when adding new packages.

I like this idea, apart from one issue.

Symbolically linking to default does not work well with packaging systems, so 
I'll use "cp -a" instead.

One benefit of this is that it allows for easily creating several sets of 
sample configurations that could be used.

-- 
If you send email to me or to a mailing list that I use which has >4 lines
of legalistic junk at the end then you are specifically authorizing me to do
whatever I wish with the message and all other messages from your domain, by
posting the message you agree that your long legalistic sig is void.

--
You have received this message because you are subscribed to the selinux 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.

Re: db conflict ?

[Howard Holm]

Could you elaborate on the problems with symbolic links.  My understanding
(perhaps flawed) of RPMS is that it's possible to create a configuration
alterable symbolic link.  (i.e., a symbolic link marked as a configuration
file so that if it's altered, RPM won't restore it when upgrading the
package.)  As little as I know about RPM, I know dramatically less about
Debian packaging, so I really don't know what the situation might be for
.debs.

As I mentioned in my response to Mark W., I think cp -a might loose a lot
of the benefits of the link if I understand you correctly.

On Fri, Apr 12, 2002 at 11:01:41PM +0200, Russell Coker wrote:
> On Fri, 12 Apr 2002 22:25, Howard Holm wrote:
> > Bringing up again a proposal of mine from April 3rd, I suggest that we
> > put the "example" policy in /usr/share/selinux/policy/default/ and
> > compile the policy in automated scripts from
> > /usr/share/selinux/policy/current/.  When creating current, it should
> > be a link to default.  If the admin changes the link or removes it
> > in favor of an actuall local directory then all that happens when an
> > automated script installs new default policy language and recompiles
> > and installs "current" is that the real current policy is reinstalled
> > if it is different than the default.  If it is a link to the default,
> > then the updated default policy is compliled and installed.  This
> > seems to be a good compromise between not arbitrarily replacing a
> > local administrative policy while still allowing the majority of
> > people who use the default policy to have it automatically maintained
> > and added to when adding new packages.
> 
> I like this idea, apart from one issue.
> 
> Symbolically linking to default does not work well with packaging systems, so 
> I'll use "cp -a" instead.
> 
> One benefit of this is that it allows for easily creating several sets of 
> sample configurations that could be used.

--
Howard Holm <hdholm@epoch.ncsc.mil>
Secure Systems Research Office
National Security Agency

--
You have received this message because you are subscribed to the selinux 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.

Re: db conflict ?

[Howard Holm]

I think I agree with Russell that binary packages shouldn't be installing
things in /usr/local/.  Perhaps we can add an environment variable for the
"prefix" that will default to /usr/local/ but can be set to /usr by
package maintainers.  I really think the right answer for policy source is
in /usr/share which by FHS standards should be sharable between
architectures (and I believe the policy source should be.)  Of course, the
policy binary has to be on the root partition for booting purposes, but
I think it's best if for machines that are sharing /usr within an
architecture and /usr/share between architectures, we let them put policy
source in /usr/share/.  I can't envision a situation where you would
need to recompile policy on a system too crippled to mount /usr/share/.

I'm not sure why Russell decided on /usr/share/doc/selinux/examples/policy/.
I probably would have put the policy directory higher in the hierarchy
something like /usr/share/selinux/policy/ maybe, but that's not a big issue.

On Fri, Apr 12, 2002 at 03:17:05PM -0400, Stephen Smalley wrote:
> On Fri, 12 Apr 2002, Westerman, Mark wrote:
> 
> > Could you think about placing the policy sources
> > into the /usr/local/selinux Directory
> >
> > For new version of selinux the install could look and
> > see if there is a /usr/local/selinux/policy and setfiles
> > if the directories are present the install will populate then
> > with the example policy. If the directories are present just
> > overwrite the /usr/local/selinux/share/doc/example files.
> 
> This is fine with me.  It merely involves adding a new target to the
> policy and setfiles Makefiles to install the sources for the
> configurations and then adjusting the README and quickinstall target to
> include that step.

--
Howard Holm <hdholm@epoch.ncsc.mil>
Secure Systems Research Office
National Security Agency

--
You have received this message because you are subscribed to the selinux 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.

Re: db conflict ?

[Dale Amon]

On Fri, Apr 12, 2002 at 04:18:20PM -0400, Howard Holm wrote:
> things in /usr/local/.  Perhaps we can add an environment variable for the
> "prefix" that will default to /usr/local/ but can be set to /usr by
> package maintainers.  I really think the right answer for policy source is
> in /usr/share which by FHS standards should be sharable between
> architectures (and I believe the policy source should be.)  Of course, the
> policy binary has to be on the root partition for booting purposes, but
> I think it's best if for machines that are sharing /usr within an
> architecture and /usr/share between architectures, we let them put policy
> source in /usr/share/.  I can't envision a situation where you would
> need to recompile policy on a system too crippled to mount /usr/share/.

I was playing around with this over Christmas but got swamped with
other things. What you want is for your build script to use "prefix" so
package maintainers can build using:

	configure prefix=/

If you let the default be /usr/local/, then anyone who builds direct
will install to /usr/local.

The problem I ran across was that the various selinux utils have
all sorts of different vars for configure; and also to do it right
you often need to regen the configure script from configure.in.
Some of the utils use just Makefile; others use configure/automake.
It's a real mess.




--
You have received this message because you are subscribed to the selinux 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.

Re: db conflict ?

[Stephen Smalley]

I wanted to raise a few other issues with regard to this topic and
how/whether it should affect the upstream distribution of SELinux.
At present, our installation procedure doesn't install the policy or file
contexts sources at all, just the compiled policy and the created
persistent label mappings.  If we want to change the upstream
distribution, I have a few questions and concerns aside from the
location in the filesystem hierarchy:

1) When installing the policy and file contexts sources, do we want to
keep them in separate directories as in the distribution (policy,
setfiles), or do we want to merge them together as in Russell Coker's
Debian selinux package?  I'd prefer to keep them separate, especially
since we have now partitioned file contexts into many files as well.
They can live under a common top-level directory, but I'd like to keep
each within its own subdirectory.  Does that seem reasonable?

2) For policy, we can simply copy the policy directory and its Makefile,
and the Makefile targets should work fine after relocation, since the
build and install of checkpolicy is already separated under the 'module'
directory due to its dependencies on the SELinux module.  However, the
setfiles directory contains both the setfiles program sources and the file
contexts configuration, and the Makefile targets build setfiles and
the file_contexts file and then run setfiles on file_contexts.  Hence, at
present, the setfiles program is "private" to the setfiles directory and
is not installed at all.  If we install the file contexts sources, I
would expect us to install the .fc configuration files and a Makefile that
runs an installed setfiles program on them.  This will require something
other than just copying the setfiles directory (i.e. omit the setfiles
program source files and replace the Makefile with a different one),
unless we restructure it within our own distribution to isolate the
program from the configuration (e.g. have separate setfiles and file_contexts
directories, 'make install' in setfiles will build and install the
setfiles program, 'make relabel' in file_contexts will build the file
contexts configuration and run the installed setfiles program on it).
Does the latter change seem reasonable?

3) At present, our installation procedure always builds and installs the
distribution policy and file contexts configurations.  Howard mentioned
always building and installing the local policy, which might be a link
to the example policy or might be a locally-customized policy.  However,
I think we typically want people to merge any customizations into the
distribution policy and install it when upgrading SELinux from the
upstream distribution, as there may be incompatible changes.  At present,
almost everyone uses some kind of locally-customized policy at least to
set up policy/users (and often to enable X support or add new domains), so
if we merely check to see whether they have made _any_ local
customizations, we will almost always use their local policy, which may
not be a good thing.

--
Stephen D. Smalley, NAI Labs
ssmalley@nai.com







--
Stephen D. Smalley, NAI Labs
ssmalley@nai.com



--
You have received this message because you are subscribed to the selinux 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.

Re: db conflict ?

[Russell Coker]

On Thu, 18 Apr 2002 16:54, Stephen Smalley wrote:
> distribution, I have a few questions and concerns aside from the
> location in the filesystem hierarchy:

Incidentally I've been running with /usr/share/selinux/policy/default and 
/usr/share/selinux/policy/current for a few days now.  It seems that the 
directory is inconveniantly long (why not "/usr/share/selinux" instead of 
"/usr/share/selinux/policy"?).  Also I am going to create a symlink 
/etc/selinux that points to the policy.

> 1) When installing the policy and file contexts sources, do we want to
> keep them in separate directories as in the distribution (policy,
> setfiles), or do we want to merge them together as in Russell Coker's
> Debian selinux package?  I'd prefer to keep them separate, especially
> since we have now partitioned file contexts into many files as well.
> They can live under a common top-level directory, but I'd like to keep
> each within its own subdirectory.  Does that seem reasonable?

Why not just have a file_contexts directory under the main policy directory?

I think that having a single Makefile do them both is the best way to do it.  
In my current code base it will compile the policy before doing a relabel.

Also with the new file_contexts scheme of separate files then the same 
Makefile needs to be used so it can determine which .fc files to use 
something like the following:
FC_FILES=$(pathsubst domains/program/%.te,file_contexts/%.fc, $(wildcard 
domains/program/*.te))

Then I was thinking of having a rule to compile the set of fc files to use 
into one file and compare it to the previous version - then if there's a 
change it does a "make relabel", otherwise nothing.

> runs an installed setfiles program on them.  This will require something
> other than just copying the setfiles directory (i.e. omit the setfiles
> program source files and replace the Makefile with a different one),
> unless we restructure it within our own distribution to isolate the
> program from the configuration (e.g. have separate setfiles and
> file_contexts directories, 'make install' in setfiles will build and
> install the setfiles program, 'make relabel' in file_contexts will build
> the file contexts configuration and run the installed setfiles program on
> it). Does the latter change seem reasonable?

Sounds fine to me.

> 3) At present, our installation procedure always builds and installs the
> distribution policy and file contexts configurations.  Howard mentioned
> always building and installing the local policy, which might be a link
> to the example policy or might be a locally-customized policy.  However,
> I think we typically want people to merge any customizations into the
> distribution policy and install it when upgrading SELinux from the
> upstream distribution, as there may be incompatible changes.  At present,
> almost everyone uses some kind of locally-customized policy at least to
> set up policy/users (and often to enable X support or add new domains), so
> if we merely check to see whether they have made _any_ local
> customizations, we will almost always use their local policy, which may
> not be a good thing.

I agree.

I think we need some perl programs to manage this.  At the install time (or 
at any time afterwards) the user should be able to delete policy files from 
the current tree and not have them reappear.

Once the .te file has been deleted the matching .fc file must be disregarded 
ar relabel time.

An upgrade should list files that have changed and allow a choice of 
wholesale change application or applying/rejecting changes on a per-file 
basis after seeing a "diff -u" of the changes.

If the upstream file has not changed (IE if I'm reinstalling the same version 
of the upstream code that I already had) then it must not prompt me to change 
things where the files I'm using are different from the distribution files.

-- 
If you send email to me or to a mailing list that I use which has >4 lines
of legalistic junk at the end then you are specifically authorizing me to do
whatever I wish with the message and all other messages from your domain, by
posting the message you agree that your long legalistic sig is void.

--
You have received this message because you are subscribed to the selinux 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.

Re: db conflict ?

[Stephen Smalley]

On Thu, 18 Apr 2002, Russell Coker wrote:

> Why not just have a file_contexts directory under the main policy directory?
>
> I think that having a single Makefile do them both is the best way to do it.
> In my current code base it will compile the policy before doing a relabel.
>
> Also with the new file_contexts scheme of separate files then the same
> Makefile needs to be used so it can determine which .fc files to use
> something like the following:
> FC_FILES=$(pathsubst domains/program/%.te,file_contexts/%.fc, $(wildcard
> domains/program/*.te))

I've moved the file contexts configuration under policy/file_contexts in
our tree and changed the policy Makefile to cover both policy builds and
relabeling.  The setfiles directory now merely contains the setfiles
program sources and a Makefile to build and install it.  I used your
definition above (except pathsubt->patsubst), and it appears to work
correctly with the partitioned file contexts.

--
Stephen D. Smalley, NAI Labs
ssmalley@nai.com




--
You have received this message because you are subscribed to the selinux 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.

RE: db conflict ?

[Westerman, Mark]

On Monday, April 15, 2002 9:40 AM, Holm, Howard wrote:

> > The binary package will install the logrotate into
> > it normal (for Redhat at least) location.
> > I will have rpm do an uninstall of the
> > previous version of logrotate then install the 
> > NSA modified logrotate. The NSA modified version will 
> > insert a conflict to the normal logrotate.
> 
> I'm not sure what you mean by "have rpm do an uninstall"
> I would think that a "supercedes: logrotate" and maybe
> "provides: logrotate" would cause the replacement to be
> automatic and cause less confusion for other packages
> that might depend on logrotate than a "conflicts" would.
> 
You have a very good point. I did not think about requires:
I did not see supercedes: tag in my documentation, but I did 
see provides: tag. 

Mark
 

--
You have received this message because you are subscribed to the selinux 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.

RE: db conflict ?

[Westerman, Mark]

Ok,

How about this.

For a binary RPM package.
I will rename all added utils from the NSA
i.e 
logrotate-3.5.9 to logrotate-selinux-3.5.9

The binary package will install the logrotate into
it normal (for Redhat at least) location.
I will have rpm do an uninstall of the
previous version of logrotate then instll the 
NSA modified logrotate. The NSA modified version will 
insert a conflict to the normal logrotate.


When changes for the modified packages are migrated
upstream with the standard source then the modified
NSA packages can be deleted

Standard Example Policy will install to 

/usr/share/doc/selinux/examples/policy/

(Howard, I agree with Russell on the
 example policy directory, that is where 
 standard examples go)

if the Directory

/etc/selinux/policy
/etc/selinux/setfiles

do not exist I will install the example policy into
the respective directories. If they do exist I will
treat the install as an upgrade and not touch the
touch the /etc/selinux directory structure


This will require a single user mode installation



> -----Original Message-----
> From: Howard Holm [mailto:hdholm@epoch.ncsc.mil]
> Sent: Friday, April 12, 2002 3:18 PM
> To: Stephen Smalley
> Cc: Westerman, Mark; Russell Coker; Tom; SELinux@tycho.nsa.gov
> Subject: Re: db conflict ?
> 
> 
> I think I agree with Russell that binary packages shouldn't 
> be installing
> things in /usr/local/.  Perhaps we can add an environment 
> variable for the
> "prefix" that will default to /usr/local/ but can be set to /usr by
> package maintainers.  I really think the right answer for 
> policy source is
> in /usr/share which by FHS standards should be sharable between
> architectures (and I believe the policy source should be.)  
> Of course, the
> policy binary has to be on the root partition for booting 
> purposes, but
> I think it's best if for machines that are sharing /usr within an
> architecture and /usr/share between architectures, we let 
> them put policy
> source in /usr/share/.  I can't envision a situation where you would
> need to recompile policy on a system too crippled to mount 
> /usr/share/.
> 
> I'm not sure why Russell decided on 
> /usr/share/doc/selinux/examples/policy/.
> I probably would have put the policy directory higher in the hierarchy
> something like /usr/share/selinux/policy/ maybe, but that's 
> not a big issue.
> 
> On Fri, Apr 12, 2002 at 03:17:05PM -0400, Stephen Smalley wrote:
> > On Fri, 12 Apr 2002, Westerman, Mark wrote:
> > 
> > > Could you think about placing the policy sources
> > > into the /usr/local/selinux Directory
> > >
> > > For new version of selinux the install could look and
> > > see if there is a /usr/local/selinux/policy and setfiles
> > > if the directories are present the install will populate then
> > > with the example policy. If the directories are present just
> > > overwrite the /usr/local/selinux/share/doc/example files.
> > 
> > This is fine with me.  It merely involves adding a new target to the
> > policy and setfiles Makefiles to install the sources for the
> > configurations and then adjusting the README and 
> quickinstall target to
> > include that step.
> 
> --
> Howard Holm <hdholm@epoch.ncsc.mil>
> Secure Systems Research Office
> National Security Agency
> 

--
You have received this message because you are subscribed to the selinux 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.

Re: db conflict ?

[Howard Holm]

On Fri, Apr 12, 2002 at 03:33:44PM -0500, Westerman, Mark wrote:
> Ok,
> 
> How about this.
> 
> For a binary RPM package.
> I will rename all added utils from the NSA
> i.e 
> logrotate-3.5.9 to logrotate-selinux-3.5.9
> 
> The binary package will install the logrotate into
> it normal (for Redhat at least) location.
> I will have rpm do an uninstall of the
> previous version of logrotate then instll the 
> NSA modified logrotate. The NSA modified version will 
> insert a conflict to the normal logrotate.

I'm not sure what you mean by "have rpm do an uninstall"
I would think that a "supercedes: logrotate" and maybe
"provides: logrotate" would cause the replacement to be
automatic and cause less confusion for other packages
that might depend on logrotate than a "conflicts" would.

> When changes for the modified packages are migrated
> upstream with the standard source then the modified
> NSA packages can be deleted
> 
> Standard Example Policy will install to 
> 
> /usr/share/doc/selinux/examples/policy/
> 
> (Howard, I agree with Russell on the
>  example policy directory, that is where 
>  standard examples go)
> 
> if the Directory
> 
> /etc/selinux/policy
> /etc/selinux/setfiles
> 
> do not exist I will install the example policy into
> the respective directories. If they do exist I will
> treat the install as an upgrade and not touch the
> touch the /etc/selinux directory structure
> This will require a single user mode installation

I'm not sure I I'm not understanding you or you and
Russell aren't understanding me.  The reason I thought
that (by default) a link would be good in
/usr/share/doc/selinux/examples/policy is that it
allows the policy to be built by packages containing
new policy unconditionally.  If the policy has been
replaced by a local policy it is rebuilt, but nothing
is changed.  However, if the policy hasn't been
modified locally, any updates are automatically
included.  It was my understanding (although I'm not
an RPM expert) that the link could be "labeled" as
a configuration file in the RPM and thus if it is
altered locally, RPM won't complain or replace it.

Maybe I'm still not awake after the weekend, I'm not
sure why this would require a single user mode
installation,  If the RPM is reloading the policy
it may fail the first time (when the new kernel
hasn't yet been booted, but I don't see why this
couldn't be handled gracefully by the RPM.  It doesn't
seem any worse than most kernel upgrades (which also
require a reboot to complete.)

> > -----Original Message-----
> > From: Howard Holm [mailto:hdholm@epoch.ncsc.mil]
> > Sent: Friday, April 12, 2002 3:18 PM
> > To: Stephen Smalley
> > Cc: Westerman, Mark; Russell Coker; Tom; SELinux@tycho.nsa.gov
> > Subject: Re: db conflict ?
> > 
> > 
> > I think I agree with Russell that binary packages shouldn't 
> > be installing
> > things in /usr/local/.  Perhaps we can add an environment 
> > variable for the
> > "prefix" that will default to /usr/local/ but can be set to /usr by
> > package maintainers.  I really think the right answer for 
> > policy source is
> > in /usr/share which by FHS standards should be sharable between
> > architectures (and I believe the policy source should be.)  
> > Of course, the
> > policy binary has to be on the root partition for booting 
> > purposes, but
> > I think it's best if for machines that are sharing /usr within an
> > architecture and /usr/share between architectures, we let 
> > them put policy
> > source in /usr/share/.  I can't envision a situation where you would
> > need to recompile policy on a system too crippled to mount 
> > /usr/share/.
> > 
> > I'm not sure why Russell decided on 
> > /usr/share/doc/selinux/examples/policy/.
> > I probably would have put the policy directory higher in the hierarchy
> > something like /usr/share/selinux/policy/ maybe, but that's 
> > not a big issue.
> > 
> > On Fri, Apr 12, 2002 at 03:17:05PM -0400, Stephen Smalley wrote:
> > > On Fri, 12 Apr 2002, Westerman, Mark wrote:
> > > 
> > > > Could you think about placing the policy sources
> > > > into the /usr/local/selinux Directory
> > > >
> > > > For new version of selinux the install could look and
> > > > see if there is a /usr/local/selinux/policy and setfiles
> > > > if the directories are present the install will populate then
> > > > with the example policy. If the directories are present just
> > > > overwrite the /usr/local/selinux/share/doc/example files.
> > > 
> > > This is fine with me.  It merely involves adding a new target to the
> > > policy and setfiles Makefiles to install the sources for the
> > > configurations and then adjusting the README and 
> > quickinstall target to
> > > include that step.

--
Howard Holm <hdholm@epoch.ncsc.mil>
Secure Systems Research Office
National Security Agency

--
You have received this message because you are subscribed to the selinux 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.

RE: db conflict ?

[Westerman, Mark]

Where every they want to put the selinux files I don't care.
I am in the process of build an rpm package (80%) complete.
I am trying to keep close to a standard NSA installation as possible.
The policy and setfiles do not belong with the source, Plus
with the rpm packages I am building, unless you install the source
rpm the source will not be there. So I am left with a question of where
to put the files. Since the NSA wants to put things in /usr/local/selinux
I will keep with that for now. If you can convince them to put them other
places OK with me.

Since you and built a Debian package I would also like keep it similar
to yours.  

What is you directory structure ? (include utils)

Mark,

> -----Original Message-----
> From: Russell Coker [mailto:russell@coker.com.au]
> Sent: Friday, April 12, 2002 1:04 PM
> To: Westerman, Mark; 'Stephen Smalley'; Howard Holm
> Cc: Tom; SELinux@tycho.nsa.gov
> Subject: Re: db conflict ?
> 
> 
> On Fri, 12 Apr 2002 19:37, Westerman, Mark wrote:
> > Could you think about placing the policy sources
> > into the /usr/local/selinux Directory
> >
> > (i.e.
> > 	/usr/local/selinux/policy
> > 	/usr/local/selinux/setfiles
> > 	/usr/local/selinux/share/doc/examples/policy
> > 	/usr/local/selinux/share/doc/examples/setfiles
> 
> I don't like any of that.
> 
> /usr/local is for the local sysadmin to copy files into, not 
> for packaged 
> software.
> 
> > For new version of selinux the install could look and
> > see if there is a /usr/local/selinux/policy and setfiles
> > if the directories are present the install will populate then
> > with the example policy. If the directories are present just
> > overwrite the /usr/local/selinux/share/doc/example files.
> 
> That's mostly what I'm doing with my Debian packages, but 
> with /etc/selinux.
> 
> -- 
> If you send email to me or to a mailing list that I use which 
> has >4 lines
> of legalistic junk at the end then you are specifically 
> authorizing me to do
> whatever I wish with the message and all other messages from 
> your domain, by
> posting the message you agree that your long legalistic sig is void.
> 

--
You have received this message because you are subscribed to the selinux 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.

Re: db conflict ?

[Russell Coker]

[-- Attachment #1: Type: text/plain, Size: 1222 bytes --]

On Fri, 12 Apr 2002 20:13, Westerman, Mark wrote:
> Where every they want to put the selinux files I don't care.
> I am in the process of build an rpm package (80%) complete.
> I am trying to keep close to a standard NSA installation as possible.
> The policy and setfiles do not belong with the source, Plus
> with the rpm packages I am building, unless you install the source
> rpm the source will not be there.

Having the policy db instead of the source sounds like a really bad idea to 
me.  If nothing else the source is smaller.

> So I am left with a question of where
> to put the files. Since the NSA wants to put things in /usr/local/selinux
> I will keep with that for now. If you can convince them to put them other
> places OK with me.

I've attached a list of all the files I use, everything under /etc/selinux is 
copied from /usr/share/doc/selinux/examples.  Also I've attached 
/etc/selinux/Makefile.

-- 
If you send email to me or to a mailing list that I use which has >4 lines
of legalistic junk at the end then you are specifically authorizing me to do
whatever I wish with the message and all other messages from your domain, by
posting the message you agree that your long legalistic sig is void.

[-- Attachment #2: list --]
[-- Type: text/plain, Size: 13995 bytes --]

/.
/etc
/etc/devfs
/etc/devfs/conf.d
/etc/devfs/conf.d/selinux
/etc/pam.d
/etc/pam.d/run_init
/etc/pam.d/newrole
/etc/security
/etc/security/dpkg_context
/etc/security/default_context
/etc/security/default_type
/etc/security/apt-get_context
/etc/security/cron_context
/etc/security/dselect_context
/etc/security/initrc_context
/lib
/lib/devfsd
/lib/devfsd/devfsd-se.so
/usr
/usr/bin
/usr/bin/chsid
/usr/bin/schfn
/usr/bin/schsh
/usr/bin/load_policy
/usr/bin/spasswd
/usr/bin/checkpolicy
/usr/bin/newrole
/usr/bin/avc_toggle
/usr/bin/lchsid
/usr/bin/list_sids
/usr/bin/chsidfs
/usr/bin/avc_enforcing
/usr/sbin
/usr/sbin/se_dpkg
/usr/sbin/run_init
/usr/sbin/setfiles
/usr/share
/usr/share/doc
/usr/share/doc/selinux
/usr/share/doc/selinux/copyright
/usr/share/doc/selinux/examples
/usr/share/doc/selinux/examples/policy
/usr/share/doc/selinux/examples/policy/tmp
/usr/share/doc/selinux/examples/policy/rbac
/usr/share/doc/selinux/examples/policy/initial_sids
/usr/share/doc/selinux/examples/policy/Makefile
/usr/share/doc/selinux/examples/policy/README.gz
/usr/share/doc/selinux/examples/policy/types
/usr/share/doc/selinux/examples/policy/types/device.te
/usr/share/doc/selinux/examples/policy/types/devpts.te
/usr/share/doc/selinux/examples/policy/types/nfs.te
/usr/share/doc/selinux/examples/policy/types/file.te.gz
/usr/share/doc/selinux/examples/policy/types/procfs.te
/usr/share/doc/selinux/examples/policy/types/network.te
/usr/share/doc/selinux/examples/policy/types/security.te
/usr/share/doc/selinux/examples/policy/users
/usr/share/doc/selinux/examples/policy/net_contexts
/usr/share/doc/selinux/examples/policy/domains
/usr/share/doc/selinux/examples/policy/domains/admin.te
/usr/share/doc/selinux/examples/policy/domains/user.te
/usr/share/doc/selinux/examples/policy/domains/program
/usr/share/doc/selinux/examples/policy/domains/program/snort.te
/usr/share/doc/selinux/examples/policy/domains/program/pump.te
/usr/share/doc/selinux/examples/policy/domains/program/initrc.te.gz
/usr/share/doc/selinux/examples/policy/domains/program/courier.te.gz
/usr/share/doc/selinux/examples/policy/domains/program/speedmgmt.te
/usr/share/doc/selinux/examples/policy/domains/program/dictd.te
/usr/share/doc/selinux/examples/policy/domains/program/radius.te
/usr/share/doc/selinux/examples/policy/domains/program/login.te.gz
/usr/share/doc/selinux/examples/policy/domains/program/crontab.te
/usr/share/doc/selinux/examples/policy/domains/program/cups.te
/usr/share/doc/selinux/examples/policy/domains/program/sendmail.te
/usr/share/doc/selinux/examples/policy/domains/program/su.te
/usr/share/doc/selinux/examples/policy/domains/program/kmod.te
/usr/share/doc/selinux/examples/policy/domains/program/dpkg.te
/usr/share/doc/selinux/examples/policy/domains/program/ipchains.te
/usr/share/doc/selinux/examples/policy/domains/program/sound.te
/usr/share/doc/selinux/examples/policy/domains/program/rpcd.te
/usr/share/doc/selinux/examples/policy/domains/program/passwd.te
/usr/share/doc/selinux/examples/policy/domains/program/selopt.te
/usr/share/doc/selinux/examples/policy/domains/program/modutil.te
/usr/share/doc/selinux/examples/policy/domains/program/rshd.te
/usr/share/doc/selinux/examples/policy/domains/program/ipsec.te
/usr/share/doc/selinux/examples/policy/domains/program/rlogind.te
/usr/share/doc/selinux/examples/policy/domains/program/syslogd.te
/usr/share/doc/selinux/examples/policy/domains/program/mail.te
/usr/share/doc/selinux/examples/policy/domains/program/portmap.te
/usr/share/doc/selinux/examples/policy/domains/program/crond.te.gz
/usr/share/doc/selinux/examples/policy/domains/program/tcpd.te
/usr/share/doc/selinux/examples/policy/domains/program/utempter.te
/usr/share/doc/selinux/examples/policy/domains/program/mesg.te
/usr/share/doc/selinux/examples/policy/domains/program/radvd.te
/usr/share/doc/selinux/examples/policy/domains/program/ldconfig.te
/usr/share/doc/selinux/examples/policy/domains/program/sshd.te
/usr/share/doc/selinux/examples/policy/domains/program/atd.te
/usr/share/doc/selinux/examples/policy/domains/program/kcheckpass.te
/usr/share/doc/selinux/examples/policy/domains/program/netutils.te
/usr/share/doc/selinux/examples/policy/domains/program/kernel.te
/usr/share/doc/selinux/examples/policy/domains/program/gatekeeper.te
/usr/share/doc/selinux/examples/policy/domains/program/getty.te
/usr/share/doc/selinux/examples/policy/domains/program/gpg.te
/usr/share/doc/selinux/examples/policy/domains/program/gpm.te
/usr/share/doc/selinux/examples/policy/domains/program/squid.te
/usr/share/doc/selinux/examples/policy/domains/program/slapd.te
/usr/share/doc/selinux/examples/policy/domains/program/ftpd.te
/usr/share/doc/selinux/examples/policy/domains/program/mount.te
/usr/share/doc/selinux/examples/policy/domains/program/lpd.te
/usr/share/doc/selinux/examples/policy/domains/program/lpr.te
/usr/share/doc/selinux/examples/policy/domains/program/automount.te
/usr/share/doc/selinux/examples/policy/domains/program/ntp.te
/usr/share/doc/selinux/examples/policy/domains/program/run_deb.te
/usr/share/doc/selinux/examples/policy/domains/program/xserver.te
/usr/share/doc/selinux/examples/policy/domains/program/rpm.te
/usr/share/doc/selinux/examples/policy/domains/program/ifconfig.te
/usr/share/doc/selinux/examples/policy/domains/program/ssh.te
/usr/share/doc/selinux/examples/policy/domains/program/dmesg.te
/usr/share/doc/selinux/examples/policy/domains/program/nscd.te
/usr/share/doc/selinux/examples/policy/domains/program/fsadm.te
/usr/share/doc/selinux/examples/policy/domains/program/hwclock.te
/usr/share/doc/selinux/examples/policy/domains/program/netscape.te
/usr/share/doc/selinux/examples/policy/domains/program/cardmgr.te
/usr/share/doc/selinux/examples/policy/domains/program/xfs.te
/usr/share/doc/selinux/examples/policy/domains/program/logrotate.te
/usr/share/doc/selinux/examples/policy/domains/program/apmd.te
/usr/share/doc/selinux/examples/policy/domains/program/newrole.te
/usr/share/doc/selinux/examples/policy/domains/program/xdm.te.gz
/usr/share/doc/selinux/examples/policy/domains/program/inetd.te
/usr/share/doc/selinux/examples/policy/domains/program/ypbind.te
/usr/share/doc/selinux/examples/policy/domains/program/gnome-pty-helper.te
/usr/share/doc/selinux/examples/policy/domains/program/postfix.te
/usr/share/doc/selinux/examples/policy/domains/program/klogd.te
/usr/share/doc/selinux/examples/policy/domains/program/ping.te
/usr/share/doc/selinux/examples/policy/domains/program/init.te
/usr/share/doc/selinux/examples/policy/domains/program/apache.te.gz
/usr/share/doc/selinux/examples/policy/domains/program/dhcpc.te
/usr/share/doc/selinux/examples/policy/domains/program/dhcpd.te
/usr/share/doc/selinux/examples/policy/domains/program/pppd.te
/usr/share/doc/selinux/examples/policy/domains/program/run_init.te
/usr/share/doc/selinux/examples/policy/domains/program/named.te
/usr/share/doc/selinux/examples/policy/domains/program/devfsd.te
/usr/share/doc/selinux/examples/policy/constraints
/usr/share/doc/selinux/examples/policy/assert.te
/usr/share/doc/selinux/examples/policy/access_vectors
/usr/share/doc/selinux/examples/policy/security_classes
/usr/share/doc/selinux/examples/policy/devfs_contexts
/usr/share/doc/selinux/examples/policy/fs_contexts
/usr/share/doc/selinux/examples/policy/macros
/usr/share/doc/selinux/examples/policy/macros/admin_macros.te.gz
/usr/share/doc/selinux/examples/policy/macros/global_macros.te.gz
/usr/share/doc/selinux/examples/policy/macros/user_macros.te.gz
/usr/share/doc/selinux/examples/policy/macros/program
/usr/share/doc/selinux/examples/policy/macros/program/netscape_macros.te.gz
/usr/share/doc/selinux/examples/policy/macros/program/ssh_macros.te
/usr/share/doc/selinux/examples/policy/macros/program/xserver_macros.te
/usr/share/doc/selinux/examples/policy/macros/program/crontab_macros.te
/usr/share/doc/selinux/examples/policy/macros/program/gpg_macros.te
/usr/share/doc/selinux/examples/policy/macros/program/lpr_macros.te
/usr/share/doc/selinux/examples/policy/macros/program/su_macros.te
/usr/share/doc/selinux/examples/policy/macros/program/crond_macros.te
/usr/share/doc/selinux/examples/policy/macros/program/gph_macros.te
/usr/share/doc/selinux/examples/policy/macros/program/sendmail_macros.te
/usr/share/doc/selinux/examples/policy/mls.gz
/usr/share/doc/selinux/examples/policy/initial_sid_contexts
/usr/share/doc/selinux/examples/policy/file_contexts.gz
/usr/share/doc/selinux/changelog.gz
/usr/share/doc/selinux/changelog.Debian.gz
/usr/share/man
/usr/share/man/man1
/usr/share/man/man1/msgwrite.1.gz
/usr/share/man/man1/shmget.1.gz
/usr/share/man/man1/shmwrite.1.gz
/usr/share/man/man1/msgget.1.gz
/usr/share/man/man1/semread.1.gz
/usr/share/man/man1/msgperm.1.gz
/usr/share/man/man1/semget.1.gz
/usr/share/man/man1/newrole.1.gz
/usr/share/man/man1/shmread.1.gz
/usr/share/man/man1/shmsid.1.gz
/usr/share/man/man1/semperm.1.gz
/usr/share/man/man1/run_init.1.gz
/usr/share/man/man1/semwrite.1.gz
/usr/share/man/man1/se_dpkg.1.gz
/usr/share/man/man1/msgread.1.gz
/usr/share/man/man1/msgsid.1.gz
/usr/share/man/man1/shmperm.1.gz
/usr/share/man/man1/semsid.1.gz
/usr/share/man/man8
/usr/share/man/man8/setfiles.8.gz
/usr/sbin/se_dselect
/usr/sbin/se_apt
/usr/share/man/man1/se_apt-get.1.gz
/usr/share/man/man1/se_dselect.1.gz

/etc/selinux
/etc/selinux/mls
/etc/selinux/tmp
/etc/selinux/tmp/load
/etc/selinux/tmp/all.te
/etc/selinux/tmp/all_types.te
/etc/selinux/tmp/all_domains.te
/etc/selinux/rbac
/etc/selinux/policy.conf
/etc/selinux/initial_sids
/etc/selinux/Makefile
/etc/selinux/types
/etc/selinux/types/device.te
/etc/selinux/types/devpts.te
/etc/selinux/types/file.te
/etc/selinux/types/nfs.te
/etc/selinux/types/procfs.te
/etc/selinux/types/network.te
/etc/selinux/types/security.te
/etc/selinux/users
/etc/selinux/net_contexts
/etc/selinux/README
/etc/selinux/domains
/etc/selinux/domains/admin.te
/etc/selinux/domains/user.te
/etc/selinux/domains/program
/etc/selinux/domains/program/snort.te
/etc/selinux/domains/program/pump.te
/etc/selinux/domains/program/speedmgmt.te
/etc/selinux/domains/program/dictd.te
/etc/selinux/domains/program/radius.te
/etc/selinux/domains/program/crontab.te
/etc/selinux/domains/program/cups.te
/etc/selinux/domains/program/sendmail.te
/etc/selinux/domains/program/su.te
/etc/selinux/domains/program/kmod.te
/etc/selinux/domains/program/dpkg.te
/etc/selinux/domains/program/ipchains.te
/etc/selinux/domains/program/sound.te
/etc/selinux/domains/program/rpcd.te
/etc/selinux/domains/program/passwd.te
/etc/selinux/domains/program/selopt.te
/etc/selinux/domains/program/modutil.te
/etc/selinux/domains/program/rshd.te
/etc/selinux/domains/program/ipsec.te
/etc/selinux/domains/program/rlogind.te
/etc/selinux/domains/program/syslogd.te
/etc/selinux/domains/program/mail.te
/etc/selinux/domains/program/portmap.te
/etc/selinux/domains/program/tcpd.te
/etc/selinux/domains/program/utempter.te
/etc/selinux/domains/program/mesg.te
/etc/selinux/domains/program/sysstat.te
/etc/selinux/domains/program/radvd.te
/etc/selinux/domains/program/ldconfig.te
/etc/selinux/domains/program/sshd.te
/etc/selinux/domains/program/atd.te
/etc/selinux/domains/program/courier.te
/etc/selinux/domains/program/authbind.te
/etc/selinux/domains/program/kcheckpass.te
/etc/selinux/domains/program/netutils.te
/etc/selinux/domains/program/kernel.te
/etc/selinux/domains/program/gatekeeper.te
/etc/selinux/domains/program/initrc.te
/etc/selinux/domains/program/getty.te
/etc/selinux/domains/program/gpg.te
/etc/selinux/domains/program/gpm.te
/etc/selinux/domains/program/squid.te
/etc/selinux/domains/program/slapd.te
/etc/selinux/domains/program/ftpd.te
/etc/selinux/domains/program/mount.te
/etc/selinux/domains/program/lpd.te
/etc/selinux/domains/program/lpr.te
/etc/selinux/domains/program/automount.te
/etc/selinux/domains/program/ntp.te
/etc/selinux/domains/program/traceroute.te
/etc/selinux/domains/program/run_deb.te
/etc/selinux/domains/program/xserver.te
/etc/selinux/domains/program/rpm.te
/etc/selinux/domains/program/ifconfig.te
/etc/selinux/domains/program/ssh.te
/etc/selinux/domains/program/dmesg.te
/etc/selinux/domains/program/nscd.te
/etc/selinux/domains/program/fsadm.te
/etc/selinux/domains/program/hwclock.te
/etc/selinux/domains/program/netscape.te
/etc/selinux/domains/program/cardmgr.te
/etc/selinux/domains/program/xdm.te
/etc/selinux/domains/program/xfs.te
/etc/selinux/domains/program/logrotate.te
/etc/selinux/domains/program/nss-ldap.te
/etc/selinux/domains/program/login.te
/etc/selinux/domains/program/apmd.te
/etc/selinux/domains/program/newrole.te
/etc/selinux/domains/program/inetd.te
/etc/selinux/domains/program/ypbind.te
/etc/selinux/domains/program/gnome-pty-helper.te
/etc/selinux/domains/program/postfix.te
/etc/selinux/domains/program/klogd.te
/etc/selinux/domains/program/custom.te
/etc/selinux/domains/program/apache.te
/etc/selinux/domains/program/ping.te
/etc/selinux/domains/program/init.te
/etc/selinux/domains/program/dhcpc.te
/etc/selinux/domains/program/dhcpd.te
/etc/selinux/domains/program/crond.te
/etc/selinux/domains/program/pppd.te
/etc/selinux/domains/program/run_init.te
/etc/selinux/domains/program/named.te
/etc/selinux/domains/program/devfsd.te
/etc/selinux/constraints
/etc/selinux/assert.te
/etc/selinux/access_vectors
/etc/selinux/security_classes
/etc/selinux/devfs_contexts
/etc/selinux/fs_contexts
/etc/selinux/macros
/etc/selinux/macros/global_macros.te
/etc/selinux/macros/admin_macros.te
/etc/selinux/macros/user_macros.te
/etc/selinux/macros/program
/etc/selinux/macros/program/netscape_macros.te
/etc/selinux/macros/program/ssh_macros.te
/etc/selinux/macros/program/xserver_macros.te
/etc/selinux/macros/program/crontab_macros.te
/etc/selinux/macros/program/gpg_macros.te
/etc/selinux/macros/program/lpr_macros.te
/etc/selinux/macros/program/su_macros.te
/etc/selinux/macros/program/crond_macros.te
/etc/selinux/macros/program/gph_macros.te
/etc/selinux/macros/program/sendmail_macros.te
/etc/selinux/policy
/etc/selinux/initial_sid_contexts
/etc/selinux/file_contexts

[-- Attachment #3: Makefile --]
[-- Type: text/plain, Size: 2100 bytes --]

#
# Makefile for the security policy.
#
# Targets:
# 
# policy - compile the policy configuration.
# install - compile and install the policy configuration.
# load    - compile, install, and load the policy configuration.
#
# The default target is 'policy'.
#

# Set to y if MLS is enabled in the module.
MLS=n

BINDIR = /usr/bin
LOADPOLICY  = $(BINDIR)/load_policy
CHECKPOLICY = $(BINDIR)/checkpolicy

POLICYFILES = $(addprefix /etc/selinux/,security_classes initial_sids access_vectors)
ifeq ($(MLS),y)
POLICYFILES += mls
endif
POLICYFILES += tmp/all.te rbac
POLICYFILES += users
POLICYFILES += constraints 
POLICYFILES += initial_sid_contexts fs_contexts devfs_contexts net_contexts

TESTPOLICYFILES = $(subst tmp/all.te,tmp/test_all.te,$(POLICYFILES))

policy:  policy.conf $(CHECKPOLICY)
	$(CHECKPOLICY) -o $@ policy.conf

policy.conf: $(POLICYFILES) macros/* macros/program/*
	m4 -Imacros -s $^ > policy.conf

install /ss_policy: policy
	install -m 644 -o root -g root policy /ss_policy
	-chsid system_u:object_r:policy_config_t /ss_policy

load tmp/load: /ss_policy
	-$(BINDIR)/load_policy /ss_policy
	touch tmp/load

relabel: file_contexts tmp/load
	setfiles -m file_contexts `mount | awk '/(ext[23]|reiserfs)/{print $$3}'`

testpolicy:  testpolicy.conf 
	$(CHECKPOLICY) -o $@ testpolicy.conf

testinstall:  testpolicy
	install -m 644 -o root -g root testpolicy /ss_policy

testload:  testinstall
	$(BINDIR)/load_policy /ss_policy

testpolicy.conf: $(TESTPOLICYFILES)
	m4 -Imacros -s $^ > testpolicy.conf

tmp/test_all.te: macros/global_macros.te tmp/all_types.te tmp/all_domains.te tmp/test_domains.te
	cat $^ > $@

tmp/all.te: macros/global_macros.te tmp/all_types.te tmp/all_domains.te assert.te
	cat $^ > $@

tmp/all_types.te: $(wildcard types/*.te)
	cat $^ > $@

tmp/all_domains.te: $(wildcard domains/*.te domains/program/*.te)
	cat $^ > $@

tmp/test_domains.te: $(wildcard domains/test/*.te)
	cat $^ > $@

clean:
	rm -f policy policy.conf 
	rm -f tmp/all.te tmp/all_types.te tmp/all_domains.te tmp/test_domains.te
	rm -f tmp/test_all.te test_all_domains.te testpolicy testpolicy.conf

RE: db conflict ?

[Westerman, Mark]

On Fri, 12 Apr 2002, 12:30 PM Smalley, Stephen wrote:
> 
> On Fri, 12 Apr 2002, Westerman, Mark wrote:
> 
> > Since you must create ...security why on the top
> > of every file system why not put it in there ?
> 
> The per-filesystem ...security directories are for the persistent label
> mappings.  They also have a different type, and should be  distinguished
> from the compiled policy configuration.
> 
> 

The ...security/policy directory would have a type of policy_conf_t and
the program the would install a new policy would only need to have read 
permissions on file_label_t. This directory would only exist on the root
file system and not on the other filesystems. This would keep to a minimum 
differences in the FHS (v2.2).

Mark

--
You have received this message because you are subscribed to the selinux 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.

RE: db conflict ?

[Stephen Smalley]

On Fri, 12 Apr 2002, Westerman, Mark wrote:

> The ...security/policy directory would have a type of policy_conf_t and
> the program the would install a new policy would only need to have read
> permissions on file_label_t. This directory would only exist on the root
> file system and not on the other filesystems. This would keep to a minimum
> differences in the FHS (v2.2).

I'd prefer to not mix the persistent label mapping directory with the
compiled policy, even if using a separate subdirectory.

--
Stephen D. Smalley, NAI Labs
ssmalley@nai.com




--
You have received this message because you are subscribed to the selinux 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.

RE: db conflict ?

[Westerman, Mark]

Since you must create ...security why on the top
of every file system why not put it in there ?



> -----Original Message-----
> From: Stephen Smalley [mailto:sds@tislabs.com]
> Sent: Friday, April 12, 2002 12:13 PM
> To: Howard Holm
> Cc: Russell Coker; Tom; SELinux@tycho.nsa.gov
> Subject: Re: db conflict ?
> 
> 
> 
> On Fri, 12 Apr 2002, Howard Holm wrote:
> 
> > I think adding a magic number to the policy file is 
> probably a good idea.
> > I'm not quite as sure about the file name containing a 
> version number, but
> > it's probably a good idea as well.  My reading of the FHS 
> (v2.2) is that
> > it prohibits /selinux/.  My suggestion would be 
> /etc/security/policy/ or
> > /etc/security/policies/ with the thought that there might 
> be at least
> > multiple versions in the directory so plural might be appropriate.
> 
> I primarily want to keep it separate from the policy sources 
> (/etc/selinux
> in Russell's Debian package), yet clearly identified as being
> selinux-specific.  It also needs to stay within the root filesystem,
> although that isn't a problem regardless of whether we go 
> with /selinux or
> /etc/security/selinux or /etc/selinux/policy as the subdirectory name.
> The name for the file itself can be reduced to policy.VERSION 
> once it is
> in a selinux-specific directory (the ss_ prefix was just to avoid
> conflicts with other potential non-SELinux policy files, ss 
> == security
> server).
> 
> --
> Stephen D. Smalley, NAI Labs
> ssmalley@nai.com
> 
> 
> 
> 
> 
> --
> You have received this message because you are subscribed to 
> the selinux 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.
> 

--
You have received this message because you are subscribed to the selinux 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.

RE: db conflict ?

[Stephen Smalley]

On Fri, 12 Apr 2002, Westerman, Mark wrote:

> Since you must create ...security why on the top
> of every file system why not put it in there ?

The per-filesystem ...security directories are for the persistent label
mappings.  They also have a different type, and should be distinguished
from the compiled policy configuration.

--
Stephen D. Smalley, NAI Labs
ssmalley@nai.com




--
You have received this message because you are subscribed to the selinux 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.

db conflict ?

[Tom]

I have just installed a new SELinux test machine. It had an SELinux
earlier, but I deleted that and installed a new one, from the Debian
packages.

During boot, I get this error message:

security:  starting up (compiled Jan 12 2002)
security:  loading policy configuration from /ss_policy
security:  policydb version 8 does not match my version 7
security:  error while loading /ss_policy, cannot initialize.
SELinux:  Could not initialize
Freeing unused kernel memory: 208k freed
Adding Swap: 498004k swap-space (priority -1)
security_context_to_sid: called before initial load_policy on unknown context system_u:object_r:policy_config_t

something looks very wrong here. my /ss_policy is up-to-date:

-rw-r--r--    1 root     root      1291704 Apr 12 11:50 ss_policy

but my "make install" fails:

arkham:/etc/selinux# make install
install -m 644 -o root -g root policy /ss_policy
chsid system_u:object_r:policy_config_t /ss_policy
system_u:object_r:policy_config_t: Invalid argument
make: *** [install] Error 1

so that is probably the source of the problem. anyone got an idea what 
I'm doing wrong? the policy itself looks ok:

arkham:/etc/selinux# checkpolicy
checkpolicy:  loading policy configuration from policy.conf
security:  5 users, 5 roles, 488 types
security:  29 classes, 52901 rules
checkpolicy:  policy configuration loaded

I also have this error:

arkham:/etc/selinux# load_policy /ss_policy
security_load_policy: Invalid argument

maybe it's related. Since this fails, I can't relabel:

arkham:/etc/selinux# make relabel
/usr/bin/load_policy /ss_policy
security_load_policy: Invalid argument
make: *** [tmp/load] Error 2


I did remove the persistent label things:
  rm -rf /...security /var/...security


I'll try a few more things, but I'm afraid the failed make install is
the cause of all troubles, so any help would be appreciated...



-- 
http://web.lemuria.org/pubkey.html
pub  1024D/D88D35A6 2001-11-14 Tom Vogt <tom@lemuria.org>
     Key fingerprint = 276B B7BB E4D8 FCCE DB8F  F965 310B 811A D88D 35A6

--
You have received this message because you are subscribed to the selinux 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.

Re: db conflict ?

[Russell Coker]

On Fri, 12 Apr 2002 12:23, Tom wrote:
> I have just installed a new SELinux test machine. It had an SELinux
> earlier, but I deleted that and installed a new one, from the Debian
> packages.
>
> During boot, I get this error message:
>
> something looks very wrong here. my /ss_policy is up-to-date:
>
> -rw-r--r--    1 root     root      1291704 Apr 12 11:50 ss_policy
>
> but my "make install" fails:
>
> arkham:/etc/selinux# make install
> install -m 644 -o root -g root policy /ss_policy
> chsid system_u:object_r:policy_config_t /ss_policy
> system_u:object_r:policy_config_t: Invalid argument
> make: *** [install] Error 1

That's failing because you aren't running SE Linux at the time.  But that's 
OK, merely having it copied in place by the "install" program is OK if you 
reboot afterwards.

> arkham:/etc/selinux# load_policy /ss_policy
> security_load_policy: Invalid argument

When you're not running SE Linux you can't load the policy, but if you booted 
an SE kernel in debugging mode with an invalid policy file then you should be 
able to use load_policy to enable SE mode.

Here's a quick and dirty hack for /etc/magic to support SE Linux policy:
0       lelong  7       SE Linux policy v7

0       lelong  8       SE Linux policy v8
>4      lelong  =1      MLS
>8      lelong  x       %d symbols
>12     lelong  x       %d ocons

> I did remove the persistent label things:
>   rm -rf /...security /var/...security

That gains you nothing.  The problem here is in the file /ss_policy.

Use file (after updating /etc/magic) to check /etc/selinux/policy, then make 
sure that the right checkpolicy program is getting run (the ancient versions 
would generate the old policy file).  Try "make clean ; make install".

Steve, I think that we need an option in the policy.conf file to specify the 
version of the policydb.  If we add it now then it'll break compatability 
with old versions of checkpolicy (which is desired).  Then we can say
"policy v8" in the config file and count on any older version refusing to 
compile it.

I think that if we already had such a feature then Tom would find his 
problems much easier to solve.

-- 
If you send email to me or to a mailing list that I use which has >4 lines
of legalistic junk at the end then you are specifically authorizing me to do
whatever I wish with the message and all other messages from your domain, by
posting the message you agree that your long legalistic sig is void.

--
You have received this message because you are subscribed to the selinux 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.

Re: db conflict ?

[Tom]

On Fri, Apr 12, 2002 at 02:05:16PM +0200, Russell Coker wrote:
> > arkham:/etc/selinux# make install
> > install -m 644 -o root -g root policy /ss_policy
> > chsid system_u:object_r:policy_config_t /ss_policy
> > system_u:object_r:policy_config_t: Invalid argument
> > make: *** [install] Error 1
> 
> That's failing because you aren't running SE Linux at the time.  But that's 
> OK, merely having it copied in place by the "install" program is OK if you 
> reboot afterwards.

"Running SELinux" means not only having an LSM kernel with the NSA
module loaded running, does it? Because I have that, at least according
to dmesg.


> > arkham:/etc/selinux# load_policy /ss_policy
> > security_load_policy: Invalid argument
> 
> When you're not running SE Linux you can't load the policy, but if you booted 
> an SE kernel in debugging mode with an invalid policy file then you should be 
> able to use load_policy to enable SE mode.

See above. Then again, this may be the db version problem, which I
found lies in the kernel. It appears I had to patch it again after
updating the lsm package, so my bad.

I'm updating the kernel now and will report back when I got it done.
It's a little fight for an unrelated reason, so it may take a while.


> Steve, I think that we need an option in the policy.conf file to specify the 
> version of the policydb.  If we add it now then it'll break compatability 
> with old versions of checkpolicy (which is desired).  Then we can say
> "policy v8" in the config file and count on any older version refusing to 
> compile it.
> 
> I think that if we already had such a feature then Tom would find his 
> problems much easier to solve.

Maybe as simple as an improved output that includes the version number
of the created/checked policy file. Knowing that the problem lies with
the versioning of /ss_policy would've saved me an hour or two.



-- 
http://web.lemuria.org/pubkey.html
pub  1024D/D88D35A6 2001-11-14 Tom Vogt <tom@lemuria.org>
     Key fingerprint = 276B B7BB E4D8 FCCE DB8F  F965 310B 811A D88D 35A6

--
You have received this message because you are subscribed to the selinux 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.

Re: db conflict ?

[Russell Coker]

On Fri, 12 Apr 2002 15:01, Tom wrote:
> > I think that if we already had such a feature then Tom would find his
> > problems much easier to solve.
>
> Maybe as simple as an improved output that includes the version number
> of the created/checked policy file. Knowing that the problem lies with
> the versioning of /ss_policy would've saved me an hour or two.

True.

Also it would be good if we had a signature that can be recognised by file(1).

Having SE Linux code in /etc/magic for 0x6, 0x7, or 0x8, etc as the first 
long of the file is not viable, eventually we'll hit a conflict.

This is why I have intentionally not submitted my /etc/magic changes to the 
maintainer of the "file" package.

-- 
If you send email to me or to a mailing list that I use which has >4 lines
of legalistic junk at the end then you are specifically authorizing me to do
whatever I wish with the message and all other messages from your domain, by
posting the message you agree that your long legalistic sig is void.

--
You have received this message because you are subscribed to the selinux 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.

Re: db conflict ?

[Stephen Smalley]

On Fri, 12 Apr 2002, Russell Coker wrote:

> Having SE Linux code in /etc/magic for 0x6, 0x7, or 0x8, etc as the first
> long of the file is not viable, eventually we'll hit a conflict.
>
> This is why I have intentionally not submitted my /etc/magic changes to the
> maintainer of the "file" package.

Yes, you originally asked for a magic number back in January.  Sorry.  How
about the same magic number we use to distinguish the SELinux module's
system calls and security structures, 0xf97cff8c?  This number follows a
convention suggested by David Wheeler for security modules - see
http://marc.theaimsgroup.com/?l=linux-security-module&m=99842987214848&w=2.

--
Stephen D. Smalley, NAI Labs
ssmalley@nai.com




--
You have received this message because you are subscribed to the selinux 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.

Re: db conflict ?

[Russell Coker]

On Fri, 12 Apr 2002 16:40, Stephen Smalley wrote:
> On Fri, 12 Apr 2002, Russell Coker wrote:
> > Having SE Linux code in /etc/magic for 0x6, 0x7, or 0x8, etc as the first
> > long of the file is not viable, eventually we'll hit a conflict.
> >
> > This is why I have intentionally not submitted my /etc/magic changes to
> > the maintainer of the "file" package.
>
> Yes, you originally asked for a magic number back in January.  Sorry.  How
> about the same magic number we use to distinguish the SELinux module's
> system calls and security structures, 0xf97cff8c?  This number follows a
> convention suggested by David Wheeler for security modules - see
> http://marc.theaimsgroup.com/?l=linux-security-module&m=99842987214848&w=2.

Sure, that sounds fine.

I suggest having that magic number followed by the string "SE Linux" (for 
people with out of date /etc/magic who are forced to use strings(1)), then 
the usual stuff.

-- 
If you send email to me or to a mailing list that I use which has >4 lines
of legalistic junk at the end then you are specifically authorizing me to do
whatever I wish with the message and all other messages from your domain, by
posting the message you agree that your long legalistic sig is void.

--
You have received this message because you are subscribed to the selinux 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.

Re: db conflict ?

[Stephen Smalley]

On Fri, 12 Apr 2002, Russell Coker wrote:

> Steve, I think that we need an option in the policy.conf file to specify the
> version of the policydb.  If we add it now then it'll break compatability
> with old versions of checkpolicy (which is desired).  Then we can say
> "policy v8" in the config file and count on any older version refusing to
> compile it.

The policy.conf file isn't necessarily tied to a particular version of the
policydb (the binary representation).  The change from policydb version 7
to policydb version 8 had no impact on policy.conf, just on the resulting
policy (/ss_policy) file compiled by checkpolicy.

--
Stephen D. Smalley, NAI Labs
ssmalley@nai.com




--
You have received this message because you are subscribed to the selinux 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.

Re: db conflict ?

[Russell Coker]

On Fri, 12 Apr 2002 15:09, Stephen Smalley wrote:
> On Fri, 12 Apr 2002, Russell Coker wrote:
> > Steve, I think that we need an option in the policy.conf file to specify
> > the version of the policydb.  If we add it now then it'll break
> > compatability with old versions of checkpolicy (which is desired).  Then
> > we can say "policy v8" in the config file and count on any older version
> > refusing to compile it.
>
> The policy.conf file isn't necessarily tied to a particular version of the
> policydb (the binary representation).  The change from policydb version 7
> to policydb version 8 had no impact on policy.conf, just on the resulting
> policy (/ss_policy) file compiled by checkpolicy.

I realise that, I'm sorry if I gave the impression that things are otherwise.

However what I would like to do is distribute a package of tools for version 
8 and a policy.conf file to match which is resistant to errors that the user 
may make.

-- 
If you send email to me or to a mailing list that I use which has >4 lines
of legalistic junk at the end then you are specifically authorizing me to do
whatever I wish with the message and all other messages from your domain, by
posting the message you agree that your long legalistic sig is void.

--
You have received this message because you are subscribed to the selinux 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.

Re: db conflict ?

[Stephen Smalley]

On Fri, 12 Apr 2002, Tom wrote:

> I have just installed a new SELinux test machine. It had an SELinux
> earlier, but I deleted that and installed a new one, from the Debian
> packages.
>
> During boot, I get this error message:
>
> security:  starting up (compiled Jan 12 2002)
> security:  loading policy configuration from /ss_policy
> security:  policydb version 8 does not match my version 7
> security:  error while loading /ss_policy, cannot initialize.
> SELinux:  Could not initialize
> Freeing unused kernel memory: 208k freed
> Adding Swap: 498004k swap-space (priority -1)
> security_context_to_sid: called before initial load_policy on unknown context system_u:object_r:policy_config_t

The policydb binary representation changed between the 2001121010 release
(December) and the 2002011718 release (January).  You need to rebuild your
policy configuration with the current version of the checkpolicy policy
compiler, so that the binary representation will be consistent with what
the kernel expects.  Make sure that you have rebuilt checkpolicy from the
new packages and installed it, and then rebuild your policy.

> but my "make install" fails:
>
> arkham:/etc/selinux# make install
> install -m 644 -o root -g root policy /ss_policy
> chsid system_u:object_r:policy_config_t /ss_policy
> system_u:object_r:policy_config_t: Invalid argument
> make: *** [install] Error 1

This is harmless (not the cause of your problem), although it differs from
the upstream SELinux distribution.  Russell appears to have modified the
policy Makefile to always try to relabel /ss_policy after each install,
and the chsid will fail when you install SELinux on a non-SELinux kernel
(but this doesn't matter in that case).  We have a separate relabel target
in the policy Makefile for this purpose (so you can do 'make install
relabel' in policy when on a SELinux kernel, or just 'make install' when
on a non-SELinux kernel).  We have the same kind of support in the utils
Makefile so you can do 'make install relabel' in utils as well when
re-installing the modified daemons and utilities on a SELinux kernel.  It
looks like Russell changed the policy Makefile's relabel target to refer
to setfiles so that he could unify the policy and setfiles Makefiles.

> arkham:/etc/selinux# checkpolicy
> checkpolicy:  loading policy configuration from policy.conf
> security:  5 users, 5 roles, 488 types
> security:  29 classes, 52901 rules
> checkpolicy:  policy configuration loaded

The policy.conf file may be fine, but if you are running the wrong version
of checkpolicy, you'll generate the wrong binary representation.  You need
to build and install the new version of checkpolicy and then build your
policy.

> I also have this error:
>
> arkham:/etc/selinux# load_policy /ss_policy
> security_load_policy: Invalid argument

load_policy only works on a SELinux kernel, since you can't load a policy
into a non-SELinux kernel.

> maybe it's related. Since this fails, I can't relabel:
>
> arkham:/etc/selinux# make relabel
> /usr/bin/load_policy /ss_policy
> security_load_policy: Invalid argument
> make: *** [tmp/load] Error 2

I assume that this is specific to Russell's modified Makefile.  'make
relabel' for setfiles should work fine on a non-SELinux kernel and
shouldn't try to run load_policy.

> I did remove the persistent label things:
>   rm -rf /...security /var/...security

You only need to do this if you were running the non-LSM version of
SELinux, due to a change in the mappings between the non-LSM and LSM
versions of SELinux.

--
Stephen D. Smalley, NAI Labs
ssmalley@nai.com




--
You have received this message because you are subscribed to the selinux 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.

Re: db conflict ?

[Russell Coker]

On Fri, 12 Apr 2002 15:06, Stephen Smalley wrote:
> > but my "make install" fails:
> >
> > arkham:/etc/selinux# make install
> > install -m 644 -o root -g root policy /ss_policy
> > chsid system_u:object_r:policy_config_t /ss_policy
> > system_u:object_r:policy_config_t: Invalid argument
> > make: *** [install] Error 1
>
> This is harmless (not the cause of your problem), although it differs from
> the upstream SELinux distribution.  Russell appears to have modified the
> policy Makefile to always try to relabel /ss_policy after each install,

Yes.

Although I now think that the correct thing to do is to have a 
file_auto_trans() rule to do it.

> re-installing the modified daemons and utilities on a SELinux kernel.  It
> looks like Russell changed the policy Makefile's relabel target to refer
> to setfiles so that he could unify the policy and setfiles Makefiles.

Correct.  In the next version I'll amend this so that it doesn't abort the 
install.

> The policy.conf file may be fine, but if you are running the wrong version
> of checkpolicy, you'll generate the wrong binary representation.  You need
> to build and install the new version of checkpolicy and then build your
> policy.

Which is surprising.  My package installs it unconditionally in /usr/bin and 
then calls it with a fully qualified path.  So I don't know how this problem 
occurred.

> > maybe it's related. Since this fails, I can't relabel:
> >
> > arkham:/etc/selinux# make relabel
> > /usr/bin/load_policy /ss_policy
> > security_load_policy: Invalid argument
> > make: *** [tmp/load] Error 2
>
> I assume that this is specific to Russell's modified Makefile.  'make
> relabel' for setfiles should work fine on a non-SELinux kernel and
> shouldn't try to run load_policy.

I am changing this to have it run load_policy if it believes that it's 
necessary, but to ignore the return code.

-- 
If you send email to me or to a mailing list that I use which has >4 lines
of legalistic junk at the end then you are specifically authorizing me to do
whatever I wish with the message and all other messages from your domain, by
posting the message you agree that your long legalistic sig is void.

--
You have received this message because you are subscribed to the selinux 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.

Re: db conflict ?

[Stephen Smalley]

On Fri, 12 Apr 2002, Russell Coker wrote:

> Although I now think that the correct thing to do is to have a
> file_auto_trans() rule to do it.

The problem with using a file_type_auto_trans rule to label /ss_policy is
that you don't want all files created by sysadm_t in the root directory to
end up with policy_config_t.  However, we could relocate /ss_policy into
a subdirectory of the root directory, and label that subdirectory with
policy_config_t so that subsequent installs will always pick up that type
automatically without needing any type transition rules.

--
Stephen D. Smalley, NAI Labs
ssmalley@nai.com








--
You have received this message because you are subscribed to the selinux 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.

Re: db conflict ?

[Russell Coker]

On Fri, 12 Apr 2002 16:07, Stephen Smalley wrote:
> On Fri, 12 Apr 2002, Russell Coker wrote:
> > Although I now think that the correct thing to do is to have a
> > file_auto_trans() rule to do it.
>
> The problem with using a file_type_auto_trans rule to label /ss_policy is
> that you don't want all files created by sysadm_t in the root directory to
> end up with policy_config_t.

In normal operation there is no reason for creating any file other than 
ss_policy in the root directory.

Installing a new kernel creates a new /vmlinux symlink, but I can easily 
write some policy to not do the auto_trans thing for lnk_file objects.

> However, we could relocate /ss_policy into
> a subdirectory of the root directory, and label that subdirectory with
> policy_config_t so that subsequent installs will always pick up that type
> automatically without needing any type transition rules.

So what directory would we use?  /etc/selinux?

-- 
If you send email to me or to a mailing list that I use which has >4 lines
of legalistic junk at the end then you are specifically authorizing me to do
whatever I wish with the message and all other messages from your domain, by
posting the message you agree that your long legalistic sig is void.

--
You have received this message because you are subscribed to the selinux 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.

Re: db conflict ?

[Stephen Smalley]

On Fri, 12 Apr 2002, Russell Coker wrote:

> So what directory would we use?  /etc/selinux?

Probably not.  You are using /etc/selinux to store the policy source
files, right (and using the policy_src_t type)?  It seems preferable to
keep the compiled policy in a separate directory and type
(policy_config_t).  That should ultimately allow us to set up a direct
pipeline enforced by the kernel from the policy sources through
checkpolicy to the compiled policy.  I was thinking of a direct
subdirectory of /, e.g. /selinux.

--
Stephen D. Smalley, NAI Labs
ssmalley@nai.com




--
You have received this message because you are subscribed to the selinux 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.

Re: db conflict ?

[Russell Coker]

On Fri, 12 Apr 2002 16:48, Stephen Smalley wrote:
> On Fri, 12 Apr 2002, Russell Coker wrote:
> > So what directory would we use?  /etc/selinux?
>
> Probably not.  You are using /etc/selinux to store the policy source
> files, right (and using the policy_src_t type)?

I was not using policy_src_t as it's not referenced in file_contexts.  My 
next version will change this.

> It seems preferable to
> keep the compiled policy in a separate directory and type
> (policy_config_t).  That should ultimately allow us to set up a direct
> pipeline enforced by the kernel from the policy sources through
> checkpolicy to the compiled policy.  I was thinking of a direct
> subdirectory of /, e.g. /selinux.

OK, that'll do.

Also while we're at it could we make the file names be 
"/selinux/ss_policy.%d", policy_version?

Then when we change policy versions we can easily switch between kernels that 
implement different versions of policy.

-- 
If you send email to me or to a mailing list that I use which has >4 lines
of legalistic junk at the end then you are specifically authorizing me to do
whatever I wish with the message and all other messages from your domain, by
posting the message you agree that your long legalistic sig is void.

--
You have received this message because you are subscribed to the selinux 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.

Re: db conflict ?

[Howard Holm]

I think adding a magic number to the policy file is probably a good idea.
I'm not quite as sure about the file name containing a version number, but
it's probably a good idea as well.  My reading of the FHS (v2.2) is that
it prohibits /selinux/.  My suggestion would be /etc/security/policy/ or
/etc/security/policies/ with the thought that there might be at least
multiple versions in the directory so plural might be appropriate.

On Fri, Apr 12, 2002 at 05:12:52PM +0200, Russell Coker wrote:
> On Fri, 12 Apr 2002 16:48, Stephen Smalley wrote:
> > On Fri, 12 Apr 2002, Russell Coker wrote:
> > > So what directory would we use?  /etc/selinux?
> >
> > Probably not.  You are using /etc/selinux to store the policy source
> > files, right (and using the policy_src_t type)?
> 
> I was not using policy_src_t as it's not referenced in file_contexts.  My 
> next version will change this.
> 
> > It seems preferable to
> > keep the compiled policy in a separate directory and type
> > (policy_config_t).  That should ultimately allow us to set up a direct
> > pipeline enforced by the kernel from the policy sources through
> > checkpolicy to the compiled policy.  I was thinking of a direct
> > subdirectory of /, e.g. /selinux.
> 
> OK, that'll do.
> 
> Also while we're at it could we make the file names be 
> "/selinux/ss_policy.%d", policy_version?
> 
> Then when we change policy versions we can easily switch between kernels that 
> implement different versions of policy.
 
--
Howard Holm <hdholm@epoch.ncsc.mil>
Secure Systems Research Office
National Security Agency

--
You have received this message because you are subscribed to the selinux 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.

Re: db conflict ?

[Russell Coker]

On Fri, 12 Apr 2002 19:01, Howard Holm wrote:
> I think adding a magic number to the policy file is probably a good idea.
> I'm not quite as sure about the file name containing a version number, but
> it's probably a good idea as well.  My reading of the FHS (v2.2) is that
> it prohibits /selinux/.  My suggestion would be /etc/security/policy/ or
> /etc/security/policies/ with the thought that there might be at least
> multiple versions in the directory so plural might be appropriate.

/etc/security/policy sounds good to me.

Having multiple versions of the same policy does not require a plural (IMHO). 
The plural would be required if we had a choice of policies that differed in 
some way other than the version number.

-- 
If you send email to me or to a mailing list that I use which has >4 lines
of legalistic junk at the end then you are specifically authorizing me to do
whatever I wish with the message and all other messages from your domain, by
posting the message you agree that your long legalistic sig is void.

--
You have received this message because you are subscribed to the selinux 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.

Re: db conflict ?

[Stephen Smalley]

On Fri, 12 Apr 2002, Howard Holm wrote:

> I think adding a magic number to the policy file is probably a good idea.
> I'm not quite as sure about the file name containing a version number, but
> it's probably a good idea as well.  My reading of the FHS (v2.2) is that
> it prohibits /selinux/.  My suggestion would be /etc/security/policy/ or
> /etc/security/policies/ with the thought that there might be at least
> multiple versions in the directory so plural might be appropriate.

I primarily want to keep it separate from the policy sources (/etc/selinux
in Russell's Debian package), yet clearly identified as being
selinux-specific.  It also needs to stay within the root filesystem,
although that isn't a problem regardless of whether we go with /selinux or
/etc/security/selinux or /etc/selinux/policy as the subdirectory name.
The name for the file itself can be reduced to policy.VERSION once it is
in a selinux-specific directory (the ss_ prefix was just to avoid
conflicts with other potential non-SELinux policy files, ss == security
server).

--
Stephen D. Smalley, NAI Labs
ssmalley@nai.com





--
You have received this message because you are subscribed to the selinux 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.

Re: db conflict ?

[Tom]

It looks like I solved the problem, at least it now boots and appears
to run fine, except that I can't log in remotely, but ssh localhost
works. I'll inspect that later.

It appears the problem was mostly mine, possibly with a feature request
for better error handling/reporting.

My kernel was db version 7, the tools 8. The reason being that I did
update all packages, including the lsm kernel patch, but did not re-apply
it correctly. Or at least that's what I suspect. After cleaning the
kernel sources and starting from scratch, it worked fine.

So from what I have seen, it looks like all the Debian packages did
exactly what they should do, except that uninstalling the old flask
package did not clear out /etc/selinux, even though I uninstalled doing
purge (i.e. _ not - in dselect).


One thing that I noticed during this setup was that the patched login
and ssh tools do not appear to work if they run on a non-lsm kernel.
While this is probably the right thing to do security-wise, it also
means that keeping a non-SELinux kernel as "rescue system" on-disk
doesn't help a thing.
As said: Security-wise I understand this, but maybe there is a better
way, at least for development purposes?


I'll go and spank sshd now. :)

Thanks to everyone for the quick help and the work done.

-- 
http://web.lemuria.org/pubkey.html
pub  1024D/D88D35A6 2001-11-14 Tom Vogt <tom@lemuria.org>
     Key fingerprint = 276B B7BB E4D8 FCCE DB8F  F965 310B 811A D88D 35A6

--
You have received this message because you are subscribed to the selinux 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.

Re: db conflict ?

[Stephen Smalley]

On Fri, 12 Apr 2002, Tom wrote:

> One thing that I noticed during this setup was that the patched login
> and ssh tools do not appear to work if they run on a non-lsm kernel.
> While this is probably the right thing to do security-wise, it also
> means that keeping a non-SELinux kernel as "rescue system" on-disk
> doesn't help a thing.

I can't speak for the Debian selinux packages, but the upstream SELinux
modified daemons and utilities run fine on non-SELinux kernels and non-LSM
kernels.  They simply fall back to the ordinary processing in that case.

--
Stephen D. Smalley, NAI Labs
ssmalley@nai.com




--
You have received this message because you are subscribed to the selinux 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.

Re: db conflict ?

[Russell Coker]

On Fri, 12 Apr 2002 16:21, Stephen Smalley wrote:
> On Fri, 12 Apr 2002, Tom wrote:
> > One thing that I noticed during this setup was that the patched login
> > and ssh tools do not appear to work if they run on a non-lsm kernel.
> > While this is probably the right thing to do security-wise, it also
> > means that keeping a non-SELinux kernel as "rescue system" on-disk
> > doesn't help a thing.
>
> I can't speak for the Debian selinux packages, but the upstream SELinux
> modified daemons and utilities run fine on non-SELinux kernels and non-LSM
> kernels.  They simply fall back to the ordinary processing in that case.

That is my aim too, and as of my last test they worked.

I'll have to test the latest versions of those packages.

-- 
If you send email to me or to a mailing list that I use which has >4 lines
of legalistic junk at the end then you are specifically authorizing me to do
whatever I wish with the message and all other messages from your domain, by
posting the message you agree that your long legalistic sig is void.

--
You have received this message because you are subscribed to the selinux 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.

Re: db conflict ?

[Tom]

On Fri, Apr 12, 2002 at 10:21:48AM -0400, Stephen Smalley wrote:
> > One thing that I noticed during this setup was that the patched login
> > and ssh tools do not appear to work if they run on a non-lsm kernel.
> > While this is probably the right thing to do security-wise, it also
> > means that keeping a non-SELinux kernel as "rescue system" on-disk
> > doesn't help a thing.
> 
> I can't speak for the Debian selinux packages, but the upstream SELinux
> modified daemons and utilities run fine on non-SELinux kernels and non-LSM
> kernels.  They simply fall back to the ordinary processing in that case.

I didn't spot any differences in the diff file, and I've just looked
through it trying to find my remote login bug.

Anyway, I dig both ways of doing it, and I can always keep a rescue CD
near, I'm just used to having a 2nd kernel around.


-- 
http://web.lemuria.org/pubkey.html
pub  1024D/D88D35A6 2001-11-14 Tom Vogt <tom@lemuria.org>
     Key fingerprint = 276B B7BB E4D8 FCCE DB8F  F965 310B 811A D88D 35A6

--
You have received this message because you are subscribed to the selinux 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.

Re: db conflict ?

[Tom]

On Fri, Apr 12, 2002 at 04:17:29PM +0200, Tom wrote:
> It looks like I solved the problem, at least it now boots and appears
> to run fine, except that I can't log in remotely, but ssh localhost
> works. I'll inspect that later.

Funny thing, I guess I found the revers of "NoRootLogin" :)

Analysis: Logging in via ssh as root works, as a user not. i.e. "ssh
-l tom testmachine" fails, "ssh -l root testmachine" works.

The error message in /var/log/auth.log is:

fatal: Could not obtain SID for user tom


The piece of code that triggers this appears to be:

if (!get_default_user_sid(pw->pw_name, 
			  strlen(pw->pw_name),
			  &scontext,
			  &sid)) {
	fprintf(stderr, "Could not obtain SID for user %s\n",
		pw->pw_name);
	exit(1);
}

so I wonder why this fails, because my /etc/selinux/users says:

user user_u roles user_r;
user root roles { user_r sysadm_r };
user tom roles { user_r sysadm_r };

so tom should be more than covered. or am I just being dumb again?


-- 
http://web.lemuria.org/pubkey.html
pub  1024D/D88D35A6 2001-11-14 Tom Vogt <tom@lemuria.org>
     Key fingerprint = 276B B7BB E4D8 FCCE DB8F  F965 310B 811A D88D 35A6

--
You have received this message because you are subscribed to the selinux 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.

Re: db conflict ?

[Stephen Smalley]

On Fri, 12 Apr 2002, Tom wrote:

> Analysis: Logging in via ssh as root works, as a user not. i.e. "ssh
> -l tom testmachine" fails, "ssh -l root testmachine" works.
>
> The error message in /var/log/auth.log is:
>
> fatal: Could not obtain SID for user tom
>
>
> The piece of code that triggers this appears to be:
>
> if (!get_default_user_sid(pw->pw_name,
> 			  strlen(pw->pw_name),
> 			  &scontext,
> 			  &sid)) {
> 	fprintf(stderr, "Could not obtain SID for user %s\n",
> 		pw->pw_name);
> 	exit(1);
> }
>
> so I wonder why this fails, because my /etc/selinux/users says:
>
> user user_u roles user_r;
> user root roles { user_r sysadm_r };
> user tom roles { user_r sysadm_r };
>
> so tom should be more than covered. or am I just being dumb again?

You also need an entry for tom in /etc/security/default_context.  This
configuration file will be obsoleted in the future, but we're still
waiting on a developer at NSA to finish the support necessary to eliminate
it.

--
Stephen D. Smalley, NAI Labs
ssmalley@nai.com




--
You have received this message because you are subscribed to the selinux 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.

Re: db conflict ?

[Tom]

On Fri, Apr 12, 2002 at 11:11:16AM -0400, Stephen Smalley wrote:
> You also need an entry for tom in /etc/security/default_context.  This
> configuration file will be obsoleted in the future, but we're still
> waiting on a developer at NSA to finish the support necessary to eliminate
> it.

Works like charm. Thanks for helping a dumb newbie, I'll leave you
alone now and try to compile a policy based on the /var/log/messages
entries. That'll be fun. :)


-- 
http://web.lemuria.org/pubkey.html
pub  1024D/D88D35A6 2001-11-14 Tom Vogt <tom@lemuria.org>
     Key fingerprint = 276B B7BB E4D8 FCCE DB8F  F965 310B 811A D88D 35A6

--
You have received this message because you are subscribed to the selinux 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.

Re: db conflict ?

[Tom]

On Fri, Apr 12, 2002 at 11:11:16AM -0400, Stephen Smalley wrote:
> > so tom should be more than covered. or am I just being dumb again?
> 
> You also need an entry for tom in /etc/security/default_context.  This
> configuration file will be obsoleted in the future, but we're still
> waiting on a developer at NSA to finish the support necessary to eliminate
> it.

actually, one more question: What am I doing wrong if the generic user
entries don't work? i.e. I create a new user - can't log in remotely. I
add him to /etc/security/default_context - still no luck. I add him to
the policy (/etc/selinux/users) and it works.

sounds like not good for systems with many users, so what is the right
way to do it?


-- 
http://web.lemuria.org/pubkey.html
pub  1024D/D88D35A6 2001-11-14 Tom Vogt <tom@lemuria.org>
     Key fingerprint = 276B B7BB E4D8 FCCE DB8F  F965 310B 811A D88D 35A6

--
You have received this message because you are subscribed to the selinux 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.

Re: db conflict ?

[Stephen Smalley]

On Fri, 12 Apr 2002, Tom wrote:

> actually, one more question: What am I doing wrong if the generic user
> entries don't work? i.e. I create a new user - can't log in remotely. I
> add him to /etc/security/default_context - still no luck. I add him to
> the policy (/etc/selinux/users) and it works.

At present, if you want to use the generic user support, you also need an
entry for user_u in /etc/security/default_context (i.e.
user_u:user_r:user_t).  Such an entry is in the example default_context
file in the upstream SELinux distribution.

--
Stephen D. Smalley, NAI Labs
ssmalley@nai.com





--
You have received this message because you are subscribed to the selinux 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.

Re: db conflict ?

[Tom]

On Fri, Apr 12, 2002 at 12:35:46PM -0400, Stephen Smalley wrote:
> At present, if you want to use the generic user support, you also need an
> entry for user_u in /etc/security/default_context (i.e.
> user_u:user_r:user_t).  Such an entry is in the example default_context
> file in the upstream SELinux distribution.

I have that. However, trying to log in via ssh fails with the same SID
error message I had earlier for tom when I didn't have tom in the
default_context. So this was my first idea - but not luck. I also do
have that user_u in the users role file (I didn't modify the default
very much yet).


-- 
http://web.lemuria.org/pubkey.html
pub  1024D/D88D35A6 2001-11-14 Tom Vogt <tom@lemuria.org>
     Key fingerprint = 276B B7BB E4D8 FCCE DB8F  F965 310B 811A D88D 35A6

--
You have received this message because you are subscribed to the selinux 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.

Re: db conflict ?

[Stephen Smalley]

On Fri, 12 Apr 2002, Tom wrote:

> I have that. However, trying to log in via ssh fails with the same SID
> error message I had earlier for tom when I didn't have tom in the
> default_context. So this was my first idea - but not luck. I also do
> have that user_u in the users role file (I didn't modify the default
> very much yet).

Seems to work here for me.  I added a user who has no entry in
policy/users or /etc/security/default_contexts, then logged in
as that user using ssh and ended up with my context as
user_u:user_r:user_t.  Again, this is with the upstream distribution, not
the Debian selinux package.

--
Stephen D. Smalley, NAI Labs
ssmalley@nai.com




--
You have received this message because you are subscribed to the selinux 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.

Re: db conflict ?

[Tom]

On Fri, Apr 12, 2002 at 01:04:36PM -0400, Stephen Smalley wrote:
> Seems to work here for me.  I added a user who has no entry in
> policy/users or /etc/security/default_contexts, then logged in
> as that user using ssh and ended up with my context as
> user_u:user_r:user_t.  Again, this is with the upstream distribution, not
> the Debian selinux package.

ok, I'll check again. I didn't notice any differences between the
upstream and the debian version of ssh when I checked the diffs earlier
today.


-- 
http://web.lemuria.org/pubkey.html
pub  1024D/D88D35A6 2001-11-14 Tom Vogt <tom@lemuria.org>
     Key fingerprint = 276B B7BB E4D8 FCCE DB8F  F965 310B 811A D88D 35A6

--
You have received this message because you are subscribed to the selinux 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.

Re: db conflict ?

[Stephen Smalley]

On Fri, 12 Apr 2002, Tom wrote:

> ok, I'll check again. I didn't notice any differences between the
> upstream and the debian version of ssh when I checked the diffs earlier
> today.

The differences might be in libsecure rather than directly in ssh.

--
Stephen D. Smalley, NAI Labs
ssmalley@nai.com




--
You have received this message because you are subscribed to the selinux 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.

Re: db conflict ?

[Russell Coker]

On Fri, 12 Apr 2002 17:01, Tom wrote:
> On Fri, Apr 12, 2002 at 04:17:29PM +0200, Tom wrote:
> > It looks like I solved the problem, at least it now boots and appears
> > to run fine, except that I can't log in remotely, but ssh localhost
> > works. I'll inspect that later.
>
> Funny thing, I guess I found the revers of "NoRootLogin" :)

Do you have an entry in /etc/security/default_context?

I think this may be a bug, but haven't looked into it deeply enough.

-- 
If you send email to me or to a mailing list that I use which has >4 lines
of legalistic junk at the end then you are specifically authorizing me to do
whatever I wish with the message and all other messages from your domain, by
posting the message you agree that your long legalistic sig is void.

--
You have received this message because you are subscribed to the selinux 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.