RE: SELinux RPM Version

RE: SELinux RPM Version

[Westerman, Mark]

On Friday, April 19, 2002 5:37 PM, Russell Coker wrote:

> >
> > /etc/selinux/policy	The main policy directory
> > If the directory does not exist then the rpm
> > packages will create it and install example policy files.
> >
> > /etc/selinux/setfiles	Same for the policy directory
> 
> The setfiles policy will be under the same directory in the 
> next upstream and  that's what I'm doing in my Debian package, 
> you may want to do the same.

Will make the change

> 
> > The example policy is installed
> > /usr/share/doc/selinux/examples/policy
> 
> I'm now using /usr/share/selinux/policy/default for the default.
> 
> > Flask files
> > /usr/lib/flask
> 
> What files?

access_vectors, initial_sids, and security_classes

> Here's my current locations:
> /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/se_dpkg		
	Not included in the rpm version
> /usr/sbin/run_init		
	will change to this location
> /usr/sbin/setfiles		
	will change to this location
> /usr/sbin/se_apt-get
	What is this ?	
> /usr/sbin/se_dselect
 	What is this ?

> > All packages such as
> > fileutils-4.1-4
> >
> > have been renamed to
> >
> > fileutils-selinux-4.1-4
> >
> > This packages provides: fileutils
> 
> Currently I'm just using an incrementally higher version number for my 
> packages while determining whether the changes can go into 
> the main packages.


I am going to keep my naming method of the modified utilities. 
I think using a higher version number is confusing to an end user. I will
keep with <utility>-selinux-<version>-<release> naming convention.
I will add Obsoletes: to the rpm spec files and see if the --replacefiles
in needed for an install. 



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: SELinux RPM Version

[Tom]

On Mon, Apr 22, 2002 at 07:19:22AM -0500, Westerman, Mark wrote:
> > /usr/sbin/se_apt-get
> 	What is this ?	
> > /usr/sbin/se_dselect
>  	What is this ?

apt-get and dselect are the Debian package-management tools. my guess
is that russel has created se-aware versions.


-- 
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: SELinux RPM Version

[Russell Coker]

On Mon, 22 Apr 2002 14:19, Westerman, Mark wrote:
> > > Flask files
> > > /usr/lib/flask
> >
> > What files?
>
> access_vectors, initial_sids, and security_classes

Good idea, I'll do that in my next package.

> > /usr/sbin/se_dpkg
>
> 	Not included in the rpm version
>
> > /usr/sbin/se_apt-get
>
> 	What is this ?
>
> > /usr/sbin/se_dselect
>
>  	What is this ?

These are programs that are similar to run_init that run the Debian package 
management tools in a different context.  Currently I'm running these tools 
in the system_r role so that they can run /etc/init.d scripts in the correct 
context.  Also these programs re-authenticate the user, as we are 
re-authenticating for minor things like restarting a daemon we must also do 
so for more important actions such as upgrading the entire system!

I would send you the source for these programs, but it's just a trivial hack 
to run_init, and I'm not sure I like the current way it's working.

I think you'll need something like this for rpm to work correctly.  Also the 
Connectiva people will surely want the se_apt-get functionality.

> > Currently I'm just using an incrementally higher version number for my
> > packages while determining whether the changes can go into
> > the main packages.
>
> I am going to keep my naming method of the modified utilities.
> I think using a higher version number is confusing to an end user. I will
> keep with <utility>-selinux-<version>-<release> naming convention.
> I will add Obsoletes: to the rpm spec files and see if the --replacefiles
> in needed for an install.

I'll do the same for cases where I can't get the changes in the main package.

I expect to get the SE patches into the main Debian packages for stat, kdm, 
procps as soon as I get the selinux-small archive to compile on non-Intel 
architectures.

-- 
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: SELinux RPM Version

[Russell Coker]

On Mon, 22 Apr 2002 23:15, Russell Coker wrote:
> On Mon, 22 Apr 2002 14:19, Westerman, Mark wrote:
> > > > Flask files
> > > > /usr/lib/flask
> > >
> > > What files?
> >
> > access_vectors, initial_sids, and security_classes
>
> Good idea, I'll do that in my next package.

Hang on, shouldn't we use /usr/lib/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: SELinux RPM Version

[Russell Coker]

On Mon, 22 Apr 2002 14:19, Westerman, Mark wrote:
> > Here's my current locations:

Here's my current list of sbin files:

/usr/sbin/se_dpkg
/usr/sbin/load_policy
/usr/sbin/run_init
/usr/sbin/checkpolicy
/usr/sbin/setfiles
/usr/sbin/se_apt-get
/usr/sbin/se_dselect

-- 
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: SELinux RPM Version

[Westerman, Mark]

On Thursday, April 25, 2002 8:51 AM, Russell Coker wrote:

> On Thu, 25 Apr 2002 14:48, Westerman, Mark wrote:
> > In the Filesystem Hierarchy Standard (FHS) document for the
> > Linux Standard Base.
> >
> > "Any program or package which contains or requires data the doesn't
> > need to modified should store that data in /usr/share. "
> >
> > the doc subdirectory if for "Miscellaneous documentation"
> 
> IMHO that means that /usr/share/selinux is better than 
> /usr/share/doc/selinux 
> for the sample policy files.
> 

While it is true that the policy do not contain any comments per say,
the fact that the examples show you an "example policy" in 
itself is documentation. I have use the term 
self documentation code. 

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: SELinux RPM Version

[Westerman, Mark]

In the Filesystem Hierarchy Standard (FHS) document for the 
Linux Standard Base.

"Any program or package which contains or requires data the doesn't
need to modified should store that data in /usr/share. "

the doc subdirectory if for "Miscellaneous documentation"

I do not consider the examples/policy to be required 
by the selinux package. I look at the example
policy as being documentation. That is why
I will be keeping the
/usr/share/doc/selinux/example/.......
Directory Structure.

The /etc/selinux/policy directory is created 
and can be modified. 

This data in /usr/share is for read-only. That is
why a symbolic link is not created. 

I will keep with the Linux Standard Base
Filesystem Hierarchy Standard and
keep.

/usr/share/doc/seliunx 
directory structure.

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: SELinux RPM Version

[Russell Coker]

On Thu, 25 Apr 2002 14:48, Westerman, Mark wrote:
> In the Filesystem Hierarchy Standard (FHS) document for the
> Linux Standard Base.
>
> "Any program or package which contains or requires data the doesn't
> need to modified should store that data in /usr/share. "
>
> the doc subdirectory if for "Miscellaneous documentation"

IMHO that means that /usr/share/selinux is better than /usr/share/doc/selinux 
for the sample policy files.

Sample policy files are not documentation, they don't even have much in the 
way of comments!

> I do not consider the examples/policy to be required
> by the selinux package. I look at the example
> policy as being documentation. That is why
> I will be keeping the
> /usr/share/doc/selinux/example/.......
> Directory Structure.

I agree that the sample policy is not required by the selinux package, which 
is why I am now planning to split it out into a separate package.

I am thinking of having selinux suggest the virtual package "selinux-policy" 
which will be provided by both "selinux-policy-default" in my packages, and a 
"selinux-policy-firewall" for the firewall policy that has been recently 
discussed here.

> The /etc/selinux/policy directory is created
> and can be modified.

OK.  I'll change my package back to using /etc/selinux as the location for 
the files.

> This data in /usr/share is for read-only. That is
> why a symbolic link is not created.
>
> I will keep with the Linux Standard Base
> Filesystem Hierarchy Standard and
> keep.
>
> /usr/share/doc/seliunx
> directory structure.

I will keep with the LSB and keep /usr/share/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: SELinux RPM Version

[Reino Wallin]

tor 2002-04-25 klockan 15.51 skrev Russell Coker:
> On Thu, 25 Apr 2002 14:48, Westerman, Mark wrote:
> > In the Filesystem Hierarchy Standard (FHS) document for the
> > Linux Standard Base.
> >
> > "Any program or package which contains or requires data the doesn't
> > need to modified should store that data in /usr/share. "
> >
> > the doc subdirectory if for "Miscellaneous documentation"
> 
> IMHO that means that /usr/share/selinux is better than /usr/share/doc/selinux 
> for the sample policy files.
> 
> Sample policy files are not documentation, they don't even have much in the 
> way of comments!
> 
I would agree with Russell here, and that is what Howard Holm suggested
as well.

> > The /etc/selinux/policy directory is created
> > and can be modified.
> 
> OK.  I'll change my package back to using /etc/selinux as the location for 
> the files.
> 
I like Marks concept here, so it seems we all agree on this.

Reino


--
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: SELinux RPM Version

[John Summerfield]

> On Thu, 25 Apr 2002 14:48, Westerman, Mark wrote:
> > In the Filesystem Hierarchy Standard (FHS) document for the
> > Linux Standard Base.
> >
> > "Any program or package which contains or requires data the doesn't
> > need to modified should store that data in /usr/share. "
> >
> > the doc subdirectory if for "Miscellaneous documentation"
> 
> IMHO that means that /usr/share/selinux is better than /usr/share/doc/selinux
>  
> for the sample policy files.
> 
> Sample policy files are not documentation, they don't even have much in the 
> way of comments!

Surely they are not data required for the application's operation!

I agree with Mark that they are documentation regardless of the commentary, and 
that they belong in /usr/share/doc/selinux (or /usr/share/doc/selinux-%{release}-
%{release})

qt-devel is one of many packages that does this, and 
/usr/share/doc/qt-devel-2.3.1/examples/examples.pro is not exactly replete with 
comments.




-- 
Cheers
John Summerfield

Microsoft's most solid OS: http://www.geocities.com/rcwoolley/

Note: mail delivered to me is deemed to be intended for me, for my disposition.

==============================
If you don't like being told you're wrong,
	be right!




-- 
Cheers
John Summerfield

Microsoft's most solid OS: http://www.geocities.com/rcwoolley/

Note: mail delivered to me is deemed to be intended for me, for my disposition.

==============================
If you don't like being told you're wrong,
	be right!




--
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: SELinux RPM Version

[Westerman, Mark]

On Wednesday, April 24, 2002 7:37 AM, Stephen Smalley wrote:

> The file contexts configuration has been moved under the policy directory,
> within a subdirectory named file_contexts, and the Makefile rules for the
> policy and relabeling have been merged into a single policy/Makefile.  The
> setfiles directory in the source tree now only contains the setfiles
> program sources along with a Makefile to build and install the
> setfiles program when SELinux is installed, and this step 
> occurs prior to running 'make relabel' in the policy directory.
> 
I have been palnning to ask this, since the file_contexts have been
move back to the policy directory, did you create a setfiles directory
or just move the file_contexts to the policy directory ?

I move the file_contexts to the policy directory and created an
entry into the Makefile call relabelfs  'make relabelfs' to 
relabel the file system.


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: SELinux RPM Version

[Stephen Smalley]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 1392 bytes --]


On Wed, 24 Apr 2002, Westerman, Mark wrote:

> I have been palnning to ask this, since the file_contexts have been
> move back to the policy directory, did you create a setfiles directory
> or just move the file_contexts to the policy directory ?
>
> I move the file_contexts to the policy directory and created an
> entry into the Makefile call relabelfs  'make relabelfs' to
> relabel the file system.

Last month, shortly after the last public release, we partitioned file
contexts into a collection of *.fc files with a similar organization to
the policy program domains to make it easy to manage the file contexts
for individual program domains
(http://marc.theaimsgroup.com/?l=selinux&m=101655275415635&w=2).  These
files were originally located in setfiles/{types.fc,program/*.fc}, and the
setfiles Makefile generated a setfiles/file_contexts file from these
files.  Recently, we relocated the types.fc and program/*.fc files under a
new policy/file_contexts directory and revised the policy Makefile to
generate a policy/file_contexts/file_contexts file from the right set of
.fc files based on the set of .te files present in policy/domains/program
(http://marc.theaimsgroup.com/?l=selinux&m=101924792620498&w=2).  These
changes were all based on public discussions on the selinux list.
Our current policy Makefile is attached.

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





[-- Attachment #2: Type: TEXT/PLAIN, Size: 2603 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.
# relabel - relabel filesystems based on the file contexts configuration.
#
# The default target is 'policy'.
#

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

BINDIR = /usr/local/selinux/bin
LOADPOLICY  = $(BINDIR)/load_policy
CHECKPOLICY = $(BINDIR)/checkpolicy
SETFILES = $(BINDIR)/setfiles

POLICYVER := policy.$(shell $(CHECKPOLICY) -V)
INSTALLDIR = /etc/security/selinux
LOADPATH = $(INSTALLDIR)/$(POLICYVER)

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

FC = file_contexts/file_contexts
FCFILES=file_contexts/types.fc $(patsubst domains/program/%.te,file_contexts/program/%.fc, $(wildcard domains/program/*.te))


policy: $(POLICYVER)

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

install: $(POLICYVER)
	mkdir -p $(INSTALLDIR)
	install -m 644 -o root -g root $(POLICYVER) $(LOADPATH)

load: install
	$(BINDIR)/load_policy $(LOADPATH)

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

program_used_flags.te: $(wildcard domains/program/*.te) domains/program
	( cd domains/program/ ; for n in *.te ; do echo "define(\`$$n')"; done ) > $@

macro_used_flags.te: $(wildcard macros/program/*.te) macros/program
	( cd macros/program/ ; for n in *.te ; do echo "define(\`$$n')"; done ) > $@

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

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

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

relabel:  $(FC) $(SETFILES)
	$(SETFILES) $(FC) `mount | awk '/(ext[23]|reiserfs)/{print $$3}'`
	touch relabel

reset:  $(FC) $(SETFILES)
	$(SETFILES) -R $(FC) `mount | awk '/(ext[23]|reiserfs)/{print $$3}'`

$(FC): $(FCFILES) file_contexts/program
	cat $(FCFILES) > $@

clean:
	rm -f $(POLICYVER) policy.conf 
	rm -f program_used_flags.te macro_used_flags.te
	rm -f all.te all_types.te all_domains.te 
	rm -f $(FC) relabel
 
-include test.mk

RE: SELinux RPM Version

[Westerman, Mark]

On Wednesday, April 24, 2002 7:18 AM, Russell Coker wrote

> On Tue, 23 Apr 2002 19:44, Westerman, Mark wrote:
> > > According to the recent discussions, isn't
> > > /usr/share/selinux/policy/default
> > > the correct install path for the example policy?
> 
> That is the path used by my Debian packages.
> 
> > After much discussion on this subject it was decided
> > that the example policy resideds in
> >
> > /usr/share/doc/selinux/examples/policy
> 
> On the 12th of April Howard Holm convinced me to use 
> /usr/share/selinux/policy as the old 
> /usr/share/doc/selinux/examples/policy 
> directory that I (and only I) had been using was inconveniantly long.
> 
> I changed my packages that day and don't plan to change them back.
> 
Your orginal was corecct the /usr/share/doc/<package> is
90% of the packages put there examples. The /usr/share/<package>
is where most packages put information for packages to run.

I will keep  /usr/share/doc/selinux/examples/policy 
for the examples policies

I have also added /usr/share/selinux
for extra program such as the newrules.pl
that was posted to the list awhile back. 

By move the examples it confuses the extra programs
I might give out with the package.


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: SELinux RPM Version

[Westerman, Mark]

On Tuesday, April 23, 2002 11:39 AM, Reino Wallin wrote:
> > 
> > Current Configuration.
> > 
> > /etc/selinux/policy	The main policy directory 
> > If the directory does not exist then the rpm 
> > packages will create it and install example policy files.
> > 
> > /etc/selinux/setfiles	Same for the policy directory
> > 
> > The example policy is installed
> > /usr/share/doc/selinux/examples/policy
> > 
> According to the recent discussions, isn't  
> /usr/share/selinux/policy/default
> the correct install path for the example policy?

After much discussion on this subject it was decided 
that the example policy resideds in

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

The real policy

/etc/selinux/policy

The rpm verions will create and populate 
/etc/selinux/policy 
if it does not exist.

Policy maker should not touch 
/etc/selinux/policy 
in a package install. My plan is to 
create a script that the security 
administrator can run to install 
a new policy.

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: SELinux RPM Version

[Reino Wallin]

tis 2002-04-23 klockan 19.44 skrev Westerman, Mark:
> 
> After much discussion on this subject it was decided 
> that the example policy resideds in
> 
> /usr/share/doc/selinux/examples/policy
> 
OK. Would then /usr/share/doc/selinux/examples/policy/firewall and 
/usr/share/doc/selinux/examples/setfiles/firewall be correct paths for
the firewall policy and its file_contexts? 

> Policy maker should not touch 
> /etc/selinux/policy 
> in a package install. My plan is to 
> create a script that the security 
> administrator can run to install 
> a new policy.
As soon as you have something that you are willing to share. I would
like to have a copy of it.

Reino



--
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: SELinux RPM Version

[Stephen Smalley]

On 23 Apr 2002, Reino Wallin wrote:

> OK. Would then /usr/share/doc/selinux/examples/policy/firewall and
> /usr/share/doc/selinux/examples/setfiles/firewall be correct paths for
> the firewall policy and its file_contexts?

The file contexts configuration has been moved under the policy directory,
within a subdirectory named file_contexts, and the Makefile rules for the
policy and relabeling have been merged into a single policy/Makefile.  The
setfiles directory in the source tree now only contains the setfiles
program sources along with a Makefile to build and install the
setfiles program when SELinux is installed, and this step occurs prior to
running 'make relabel' in the policy directory.

--
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: SELinux RPM Version

[Russell Coker]

On Tue, 23 Apr 2002 19:44, Westerman, Mark wrote:
> > According to the recent discussions, isn't
> > /usr/share/selinux/policy/default
> > the correct install path for the example policy?

That is the path used by my Debian packages.

> After much discussion on this subject it was decided
> that the example policy resideds in
>
> /usr/share/doc/selinux/examples/policy

On the 12th of April Howard Holm convinced me to use 
/usr/share/selinux/policy as the old /usr/share/doc/selinux/examples/policy 
directory that I (and only I) had been using was inconveniantly long.

I changed my packages that day and don't plan to change them back.

Incidentally my original decision to use 
/usr/share/doc/selinux/examples/policy was made before any discussion of the 
matter (back when people were still trying to convince me that I shold use 
/usr/local for everything).

> The real policy
>
> /etc/selinux/policy

I currently have /etc/selinux be a symbolic link pointing at 
/usr/share/selinux/policy/current on my system (haven't yet changed the 
package to automatically create such a link).  Again this was at Howard's 
suggestion so that if /usr/share is shared between multiple similar machines 
then they can share the same security 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: SELinux RPM Version

[Reino Wallin]

ons 2002-04-24 klockan 14.17 skrev Russell Coker:
> 
> On the 12th of April Howard Holm convinced me to use 
> /usr/share/selinux/policy as the old /usr/share/doc/selinux/examples/policy 
> directory that I (and only I) had been using was inconveniantly long.
> 
My intention is to use the directory Howard Holm suggested, so I'll put the firewall policy 
in /usr/share/selinux/policy/firewall

> > The real policy
> >
> > /etc/selinux/policy
> 
> I currently have /etc/selinux be a symbolic link pointing at 
> /usr/share/selinux/policy/current on my system (haven't yet changed the 
> package to automatically create such a link).  Again this was at Howard's 
> suggestion so that if /usr/share is shared between multiple similar machines 
> then they can share the same security policy.
> 

I like Howards suggestion and ability to share the policy. However, I
thought he suggested /etc/security/policy to link to the real policy, or
even keep the real policy files. I might have missed something here
though. This is not that important to me rigth now anyway.

Reino



--
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: SELinux RPM Version

[Russell Coker]

On Thu, 25 Apr 2002 00:38, Reino Wallin wrote:
> I like Howards suggestion and ability to share the policy. However, I
> thought he suggested /etc/security/policy to link to the real policy, or
> even keep the real policy files. I might have missed something here
> though. This is not that important to me rigth now anyway.

/etc/security/selinux is the new location for the compiled policy files 
loaded by the kernel.

I recall that /etc/selinux/policy was suggested, but I think that's too many 
levels of directories.

-- 
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: SELinux RPM Version

[Westerman, Mark]

On Monday, April 22, 2002 4:38 PM Russell Coker wrote:

> On Mon, 22 Apr 2002 14:40, Westerman, Mark wrote:
> > Current SELinux package
> > 	selinux-<kernel version>-<NSA Release number>
> > 	Current planed release:
> > 		selinux-2.4.18-2002031409.i386.rpm
> > 		selinux-dev-2.4.18-2002031409.i838.rpm
> 
> Why have the kernel version in the package name?  The NSA is  only making 
> releases for the latest kernel.  I've backported a couple of  the changes
to 
> an older kernel, but AFAIK no-one else is doing so.

While it is true that the NSA is only making releases for the latest kernel
we might need in the future the older version. A user might not want to
upgrade there kernel version. If is not to hard to keep the kernel version
I think it just adds to less confusion.

> Also the relevant thing is not the kernel version but the 
> policy version.  
> 
> What we need to eventually do is split checkpolicy out into a 
> separate package so we can have multiple versions installed, then we 
> need to have the ability to compile multiple versions and load the version

> that matches the  kernel (how do we determine the policy version in the
running 
> kernel?).
> 
> Maybe the load_policy program should be able to look at a  directory full
of 
> policy files and load the one that matches the kernel policy version?
> 
> > If future releases of selinux I think we should sub-divided into
> > more packages
> > 	selinux-kernel-<kernel version>-<NSA Release number>
> > 	selinux-policy-<version number>-<release>
> > 	selinxu-utils-<version number>-<release>
> > 		To include newrole, run_init and ......
> > 		Or a separate rpm for utility ?
> 
> Why split the sample policy from the utilities?  Why would 
> you use one 
> without the other?
>

There might be different verions of a policy. Such as a policy
for just bind (i.e. a DNS server only). If we have package for
policy then maybe different policies will be built. 
  

--
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: SELinux RPM Version

[Russell Coker]

On Tue, 23 Apr 2002 14:24, Westerman, Mark wrote:
> > Why have the kernel version in the package name?  The NSA is  only making
> > releases for the latest kernel.  I've backported a couple of  the changes
>
> to
>
> > an older kernel, but AFAIK no-one else is doing so.
>
> While it is true that the NSA is only making releases for the latest kernel
> we might need in the future the older version. A user might not want to
> upgrade there kernel version. If is not to hard to keep the kernel version
> I think it just adds to less confusion.

Choosing not to update the kernel is not related to the choice of which 
version of the selinux package to use (apart from the checkpolicy program and 
it's relationship to the policy version used by the kernel).

Therefore putting a kernel version in the name of the "selinux" package will 
lead users to believe that there is a dependency when in fact none exists.

> > > If future releases of selinux I think we should sub-divided into
> > > more packages
> > > 	selinux-kernel-<kernel version>-<NSA Release number>
> > > 	selinux-policy-<version number>-<release>
> > > 	selinxu-utils-<version number>-<release>
> > > 		To include newrole, run_init and ......
> > > 		Or a separate rpm for utility ?
> >
> > Why split the sample policy from the utilities?  Why would
> > you use one
> > without the other?
>
> There might be different verions of a policy. Such as a policy
> for just bind (i.e. a DNS server only). If we have package for
> policy then maybe different policies will be built.

There is nothing preventing other packages from installing their own 
directories in /usr/share/selinux/policy and putting appropriate policy files 
in them!

However splitting it out would mean that people who don't want the default 
policy can save 622K of disk space (for the case of the policy files I 
distribute), so I may split it for that reason.

-- 
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: SELinux RPM Version

[Westerman, Mark]

On Friday, April 19, 2002 6:08 PM, Howard Holm wrote:


> That is excellent news.  I think that will make things a lot easier
> for many people.  Do you have a plan for "naming" the release?
> SELinux is a complicated case since there are source/RPM/deb
> releases for the parts of SELinux (e.g., fileutils) which may
> need to be different for different "base" distributions (e.g.,
> RedHat 7.1, Red Hat 7.3) and which may have both stable and
> developmental kernel versions.  The best I've been able to
> come up with so far (and I'm not very happy with it so I hope
> you've come up with something better) is to name "Packages" in
> the SourceForge, not RPM sense, something like:
> 
> Red Hat 7.2 SELinux Stable
> Red Hat 7.2 SELinux Developer
> Debian Woody SELinux Stable
> Debian Woody SELinux Developer
> 
Current SELinux package
	selinux-<kernel version>-<NSA Release number>
	Current planed release:
		selinux-2.4.18-2002031409.i386.rpm
		selinux-dev-2.4.18-2002031409.i838.rpm
	This package contains all Selinux programs
	such as the policy files, newrole, and setfiles.
	Where dev is for development mode kernel.

The modified utilities are in a separate package.
	fileutils-selinux-4.1-4.i386.rpm

If future releases of selinux I think we should sub-divided into
more packages
	selinux-kernel-<kernel version>-<NSA Release number>
	selinux-policy-<version number>-<release>
	selinxu-utils-<version number>-<release>
		To include newrole, run_init and ......
		Or a separate rpm for utility ?

For the policy maker
	selinux-policy-<policy name>-<version number>-<release>

> I think if you use both Provides: fileutils-4.1-4 and
> Obsoletes: fileutils-4.1-4 you don't need to --replacefiles
> and fileutils-4.2 won't automatically upgrade (you'll have
> to use a fileutils-selinux-4.2 or a fileutils-4.2 which
> obsoletes fileutils-selinux).  At least that's how I read
> the CHANGES file and dependencies files in /usr/share/doc/rpm-4.0.3
> (look at 2.4.7 -> 2.4.8 in CHANGES and later.)  Note that I
> have not tested this so I could be wrong about the effect.

I am going to add the Obsoletes, if it works, the to rpms.

Currently there is a question if any package should rebuild the 
policy. The current rpm I am building will only build a policy
if /etc/selinux/policy does not exist. It created it and installs
the example policy. Other wise if /etc/selinux/policy exist the
install will not touch the policy.



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: SELinux RPM Version

[Russell Coker]

On Mon, 22 Apr 2002 14:40, Westerman, Mark wrote:
> Current SELinux package
> 	selinux-<kernel version>-<NSA Release number>
> 	Current planed release:
> 		selinux-2.4.18-2002031409.i386.rpm
> 		selinux-dev-2.4.18-2002031409.i838.rpm

Why have the kernel version in the package name?  The NSA is only making 
releases for the latest kernel.  I've backported a couple of the changes to 
an older kernel, but AFAIK no-one else is doing so.

Also the relevant thing is not the kernel version but the policy version.  

What we need to eventually do is split checkpolicy out into a separate 
package so we can have multiple versions installed, then we need to have the 
ability to compile multiple versions and load the version that matches the 
kernel (how do we determine the policy version in the running kernel?).

Maybe the load_policy program should be able to look at a directory full of 
policy files and load the one that matches the kernel policy version?

> If future releases of selinux I think we should sub-divided into
> more packages
> 	selinux-kernel-<kernel version>-<NSA Release number>
> 	selinux-policy-<version number>-<release>
> 	selinxu-utils-<version number>-<release>
> 		To include newrole, run_init and ......
> 		Or a separate rpm for utility ?

Why split the sample policy from the utilities?  Why would you use one 
without the other?

> Currently there is a question if any package should rebuild the
> policy. The current rpm I am building will only build a policy
> if /etc/selinux/policy does not exist. It created it and installs
> the example policy. Other wise if /etc/selinux/policy exist the
> install will not touch the policy.

Same here.

-- 
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: SELinux RPM Version

[Howard Holm]

On Mon, Apr 22, 2002 at 11:37:54PM +0200, Russell Coker wrote:
> On Mon, 22 Apr 2002 14:40, Westerman, Mark wrote:
> > If future releases of selinux I think we should sub-divided into
> > more packages
> > 	selinux-kernel-<kernel version>-<NSA Release number>
> > 	selinux-policy-<version number>-<release>
> > 	selinxu-utils-<version number>-<release>
> > 		To include newrole, run_init and ......
> > 		Or a separate rpm for utility ?
> 
> Why split the sample policy from the utilities?  Why would you use one 
> without the other?
> 
> > Currently there is a question if any package should rebuild the
> > policy. The current rpm I am building will only build a policy
> > if /etc/selinux/policy does not exist. It created it and installs
> > the example policy. Other wise if /etc/selinux/policy exist the
> > install will not touch the policy.
> 
> Same here.
 
There seem to be a couple of different "mental models" of how SELinux
will work in the future.  I have some thoughts on which I like better,
but am in no better position to predict the future than anyone else.

One model seems to be that SELinux will always be an "add-on" that highly
security aware administrators tune and use based on NSA releases.
Another model has SELinux "distributions" that are out-of-the-box SELinux
and allow security tuning, but are configured "adequately" by default.
Yet another model has SELinux "distributions" with "drop-in" policies
depending on the intended use.

I think if you look at what packagers are proposing you will often see
that they have some specific assumptions from one or more of these models
built in to what they're doing.  The model I've been advocating (which
may or may not be what everyone else wants) is to have SELinux
"distributions" which out-of-the-box understand a small number of policies.
If you don't like those you can build your own policy.  The packaging
implications of that model are that SELinux is not "add-on" packages, but
rather incorporated into all "appropriate" packages for the distribution.
Remember here that a goal of SELinux was that it be transparent to most
applications, only visible when the application would otherwise break a
policy.  Thus, most packages shouldn't require changes.  A second
implication is that adding packages which will require policy changes
should change the system policy unless that policy is not one of the
"standard" policies.

So, clearly there is a reason to separate the policy from the utilities
if you envision different policies being available.  My current thinking
is that each package should contain the policy language necessary for
that package for at least a "default" policy, and probably a few others
(e.g, firewall, server, workstation.)  Frankly, I lean toward putting
the bulk of the non-package specific policy in the filesystem RPM for
Red Hat based distributions, but I suspect that's a radical position
to take.  Equally radical, I advocate some analysis of the "current"
policy (either by system configuration parameter - anyone for
/etc/sysconfig/policy?) or pointer or diff/patch that determines if
"interesting" (i.e., non "users") parts of the policy are default
or not, and installs appropriate changes.  Lastly, if successful, I
expect that SELinux will evolve directly in the mainline kernel and
mainline packages.  So, while new enhancements based on research are
likely to come from NSA from time to time, I expect version X and X+1
of SELinux to differ more based on kernel changes than NSA releases
(in the distant future.)  Thus, I don't expect NSA version numbers
to be interesting over the long term.  This doesn't alter the fact that
in the short term, NSA version numbers are how you "know what you've
got."  Although the kernel usually cycles up at least a release between
NSA versions, we aren't promising that.  It's entirely likely that
if development releases occur (as expected) much faster than stable
releases, that multiple NSA releases with slightly different operation
are built for the same stable kernel version.

I guess the one thought to take away is that there are these different
models, and unless we can all agree on one, perhaps the best thing is
to allow divergence until use in practice demonstrates some convincing
advantages of one model or another.  I wish I had definitive answers,
but I think we're in largely uncharted waters - SELinux is a set of
distribution neutral changes that nevertheless make pervasive changes
in a distribution.  It's hard to know the best way to package it.

--
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: SELinux RPM Version

[Dale Amon]

On Mon, Apr 22, 2002 at 08:03:07PM -0400, Howard Holm wrote:

> I guess the one thought to take away is that there are these different
> models, and unless we can all agree on one, perhaps the best thing is
> to allow divergence until use in practice demonstrates some convincing
> advantages of one model or another.  I wish I had definitive answers,
> but I think we're in largely uncharted waters - SELinux is a set of
> distribution neutral changes that nevertheless make pervasive changes
> in a distribution.  It's hard to know the best way to package it.

They may not be as disparate as you fear. Many products will start from
Debian or a package (binary or source) set too make updates easy; it's
really hell and rather costly to diverge too far from the upstream
maintainer's code base, so the economics are driven by that unless
you've a really big operation behind you.

Perhaps the way to think of it is this:

upstream   package              product
main.      main.                maint.
Smalley -> ----      (TGZ) ->   ----             -> end user
           Coker     (DEB)      specialist dists
           Westerman (RPM)      pkg solutions



--
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.

SELinux RPM Version

[Westerman, Mark]

I expect to release a beta version to sourceforge 
of an rpm package of SELinux next week.

Current Configuration.

/etc/selinux/policy	The main policy directory 
If the directory does not exist then the rpm 
packages will create it and install example policy files.

/etc/selinux/setfiles	Same for the policy directory

The example policy is installed
/usr/share/doc/selinux/examples/policy


Flask files
/usr/lib/flask

Libsecure
/usr/lib/libsecure.a

All the added programs for selinux such as newrole
will be install into /usr/bin

The include directory
/usr/include/selinux

All packages such as 
fileutils-4.1-4

have been renamed to

fileutils-selinux-4.1-4

This packages provides: fileutils

The provides is so other rpms can 
meet requirements. 

All packages have been build for original spec files
with the selinux patch added. So the will install into
normal locations. 

the --replacefiles option must be used when installing.

Comments or suggestions


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: SELinux RPM Version

[Russell Coker]

On Fri, 19 Apr 2002 22:26, Westerman, Mark wrote:
> Current Configuration.
>
> /etc/selinux/policy	The main policy directory
> If the directory does not exist then the rpm
> packages will create it and install example policy files.
>
> /etc/selinux/setfiles	Same for the policy directory

The setfiles policy will be under the same directory in the next upstream and 
that's what I'm doing in my Debian package, you may want to do the same.

> The example policy is installed
> /usr/share/doc/selinux/examples/policy

I'm now using /usr/share/selinux/policy/default for the default.

> Flask files
> /usr/lib/flask

What files?

> Libsecure
> /usr/lib/libsecure.a

Same here.

> All the added programs for selinux such as newrole
> will be install into /usr/bin

Here's my current locations:
/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/se_dpkg
/usr/sbin/run_init
/usr/sbin/setfiles
/usr/sbin/se_apt-get
/usr/sbin/se_dselect

I'll move some of the other programs from /usr/bin to /usr/sbin.

> The include directory
> /usr/include/selinux

Same here.

> All packages such as
> fileutils-4.1-4
>
> have been renamed to
>
> fileutils-selinux-4.1-4
>
> This packages provides: fileutils

Currently I'm just using an incrementally higher version number for my 
packages while determining whether the changes can go into the main 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: SELinux RPM Version

[Howard Holm]

On Fri, Apr 19, 2002 at 03:26:24PM -0500, Westerman, Mark wrote:
> I expect to release a beta version to sourceforge 
> of an rpm package of SELinux next week.

That is excellent news.  I think that will make things a lot easier
for many people.  Do you have a plan for "naming" the release?
SELinux is a complicated case since there are source/RPM/deb
releases for the parts of SELinux (e.g., fileutils) which may
need to be different for different "base" distributions (e.g.,
RedHat 7.1, Red Hat 7.3) and which may have both stable and
developmental kernel versions.  The best I've been able to
come up with so far (and I'm not very happy with it so I hope
you've come up with something better) is to name "Packages" in
the SourceForge, not RPM sense, something like:

Red Hat 7.2 SELinux Stable
Red Hat 7.2 SELinux Developer
Debian Woody SELinux Stable
Debian Woody SELinux Developer

and within each have "Releases" like 1.23SF that contain
files like fileutils-selinux-4.1-1.{tar.gz,src.rpm,i386.rpm,i686.rpm}

Among the drawbacks are that a new "release" to fix some
problem in a particular package (e.g., fileutils) requires
re-releasing all the files in the "release" which will
contain perhaps dozens of various .rpm files. I used a
completely different version numbering scheme to avoid
confusion with NSA base releases, but that makes it difficult
to know which NSA base release 1.23SF is based on.
 
> Current Configuration.
> 
> /etc/selinux/policy	The main policy directory 
> If the directory does not exist then the rpm 
> packages will create it and install example policy files.
> 
> /etc/selinux/setfiles	Same for the policy directory
> 
> The example policy is installed
> /usr/share/doc/selinux/examples/policy
> 
> 
> Flask files
> /usr/lib/flask

I'm not sure which files you mean to go here.  I think of
"Flask" largely as the kernel modifications, and they shouldn't
need a separate home.  It's Friday, what files am I forgetting?
 
> Libsecure
> /usr/lib/libsecure.a
> 
> All the added programs for selinux such as newrole
> will be install into /usr/bin
> 
> The include directory
> /usr/include/selinux
> 
> All packages such as 
> fileutils-4.1-4
> 
> have been renamed to
> 
> fileutils-selinux-4.1-4
> 
> This packages provides: fileutils
> 
> The provides is so other rpms can 
> meet requirements. 
> 
> All packages have been build for original spec files
> with the selinux patch added. So the will install into
> normal locations. 
> 
> the --replacefiles option must be used when installing.

I think if you use both Provides: fileutils-4.1-4 and
Obsoletes: fileutils-4.1-4 you don't need to --replacefiles
and fileutils-4.2 won't automatically upgrade (you'll have
to use a fileutils-selinux-4.2 or a fileutils-4.2 which
obsoletes fileutils-selinux).  At least that's how I read
the CHANGES file and dependencies files in /usr/share/doc/rpm-4.0.3
(look at 2.4.7 -> 2.4.8 in CHANGES and later.)  Note that I
have not tested this so I could be wrong about the effect.

Ideally, I think you would want a kernel package (kernel-selinux?)
that Provides: selinux (as a virtual package) so that packages
that require selinux (libsecure?) can Require: selinux and things
like, say logrotate, can use triggers to install policy, e.g., (off
the top of my head, so don't rely on it too heavily.)

     %triggerin -- selinux
     # Rebuild the policy with new logrotate files included in the policy
     # when logrotate installed (if selinux already is) or if and when
     # selinux is later installed.
     cd /etc/selinux/policy
     make reload
     make relabel < /usr/share/selinux/examples/filecontexts/logrotate

     %postun
     # Rebuild the policy without the logrotate files when removing
     # logrotate
     cd /etc/selinux/policy
     make reload

Of course, without the default policy being somehow linked to the
current policy this has some problems.   Some logic in a %pre or
%post trigger script may be able to compare the default and
current policies and make alterations to current if they're not
"too" different (e.g., only the users file has changed.)
 
> Comments or suggestions
> 
> 
> Mark
 
--
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: SELinux RPM Version

[Russell Coker]

On Sat, 20 Apr 2002 01:07, Howard Holm wrote:
> developmental kernel versions.  The best I've been able to
> come up with so far (and I'm not very happy with it so I hope
> you've come up with something better) is to name "Packages" in
> the SourceForge, not RPM sense, something like:
>
> Red Hat 7.2 SELinux Stable
> Red Hat 7.2 SELinux Developer
> Debian Woody SELinux Stable
> Debian Woody SELinux Developer

I have no plans to ever upload Debian packages to Sourceforge.

My "selinux" and "linselinux-dev" packages are already in Debian/unstable, 
the packages of modified utilities are on my web site at the moment, I aim to 
eventually get most of them in unstable too.

For the ones that I can't get into the main Debian tree I'll setup my own apt 
source.

> completely different version numbering scheme to avoid
> confusion with NSA base releases, but that makes it difficult
> to know which NSA base release 1.23SF is based on.

This is a problem.  But as we get the SE changes into the upstream 
distribution it'll become less of a problem.

> Ideally, I think you would want a kernel package (kernel-selinux?)
> that Provides: selinux (as a virtual package) so that packages

Do you mean having a kernel-binary package?  If so that's a bad idea.

Having a kernel binary package installed does NOT mean you are running that 
kernel.  You can have several kernels installed and be running any of them.

Also many people don't like packaged kernels and build their own.

But one thing you need is a kernel-patch package for the LSM patch.  I have a 
kernel-patch-2.4-lsm and a kernel-patch-2.5-lsm package.  Then I have the 
main selinux package build-depending on the kernel-patch-2.4-lsm package, it 
extracts the patch itself (doesn't rely on having full kernel source 
available) for the header 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: SELinux RPM Version

[Reino Wallin]

fre 2002-04-19 klockan 22.26 skrev Westerman, Mark:
> I expect to release a beta version to sourceforge 
> of an rpm package of SELinux next week.
> 
> Current Configuration.
> 
> /etc/selinux/policy	The main policy directory 
> If the directory does not exist then the rpm 
> packages will create it and install example policy files.
> 
> /etc/selinux/setfiles	Same for the policy directory
> 
> The example policy is installed
> /usr/share/doc/selinux/examples/policy
> 
According to the recent discussions, isn't  
/usr/share/selinux/policy/default
the correct install path for the example policy?

I am considering to install upcoming releases of the firewall policy in
/usr/share/selinux/policy/firewall
Am I wrong here?
-- 
Reino Wallin, Oribium Labs
reino@oribium.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: SELinux RPM Version

[Russell Coker]

On Tue, 23 Apr 2002 18:39, Reino Wallin wrote:
> fre 2002-04-19 klockan 22.26 skrev Westerman, Mark:
> > I expect to release a beta version to sourceforge
> > of an rpm package of SELinux next week.
> >
> > Current Configuration.
> >
> > /etc/selinux/policy	The main policy directory
> > If the directory does not exist then the rpm
> > packages will create it and install example policy files.
> >
> > /etc/selinux/setfiles	Same for the policy directory
> >
> > The example policy is installed
> > /usr/share/doc/selinux/examples/policy
>
> According to the recent discussions, isn't
> /usr/share/selinux/policy/default
> the correct install path for the example policy?

It's what Howard has suggested and what I am now using for my Debian packages.

> I am considering to install upcoming releases of the firewall policy in
> /usr/share/selinux/policy/firewall

Great!

Now what I am thinking of doing is having a selinux-pol-firewall package to 
contain the files for your policy (and hopefully someone else will take over 
packaging of it as I am busy enough with my own policy).  Now I am 
considering also splitting out the main policy into a selinux-pol-default 
package so that the user can install the sample policy that matches their 
needs.

-- 
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.