[RFC] Upstream policy handling

[RFC] Upstream policy handling

[Joshua Brindle]

It has been noted in the past that Gentoo policy changes don't often 
come upstream. This has been an issue because the policy has diverged a 
bit from the upstream policy and the changes are generally incompatible 
with those being made elsewhere (and being pushed upstream). For this 
reason I believe the current method of sharing the policy is inadequate. 
The current upstream policy is a compositite of most changes made by 
distros and policy writers who may have different philosophies about how 
the policy should work.

One example is our sysadmfile trim which happened a few weeks ago. Chris 
  PeBenito suggested this on the list only to be scrutinized, we have 
since gone ahead with the changes but based on the feedback here Chris 
felt it a moot point to post the changes. Recently it was suggested by 
another distro (though vetoed by Steve) to make sysadmfile even more 
accessible to non-admins. This illustrates the radical difference in 
policy philosophies.

I feel that distro tunables are undesirable. They bloat the policy in 
unnecessary ways and just don't make sense to me. Downstream vendors 
often apply their own patches to applications, so Gentoo, Debian and 
Redhat would have patchsets for apps rather than the upstream app having 
#ifdef REDHAT ... #elif DEBIAN and so on. (Russel pointed out that some 
apps have this sort of thing in upstream but that doesn't make it 
correct ;) )

Having said that, my suggestion to reconcile these issues and make the 
policy more flexible to downstream movement is to utilize more resources 
which make multiple branch repositories far easier to deal with. 
Specifically I think it would be optimal to set up a policy repository 
at bkbits.net (yes, this is bitkeeper, yes I know about the license, 
will cover that later). In this repository there should be branches for 
each vendor, and the NSA. Obviously each vendor pushes their own policy 
changes into their branch. If the NSA and/or any other vendors like the 
  change they can import that patchset into their own branch. This 
should work well for base-policy changes and also for application policies.

Second, I think the current policy layout might not be optimal for 
sharing of this nature. Since the policy module compiler will be 
available soon now might be the time to reconstruct the policy layout, 
my suggestion is as follows

NSA policy -+
	base-policy -+
		Makefile
		users
		rbac
		genfs_contexts
		...
		domains -+
			admin.te
			...
			programs -+
				(only .te's in base-policy)
		file_contexts -+
			(only .fc's in base-policy)

	applications -+
		apache -+
			apache.te
			apache.fc
			apache_macros.te
		...

Redhat policy -+
	....

Gentoo policy -+
	....

and so on

this would make it much easier to share applications as well.

This would provide a centralized repository for full copies of policy 
from multiple places, and a very easy way to compare them for 
differences. It would also allow us to share policy much more 
effectively while keeping the full policy source available in a central 
place.

So, the bitkeeper caveats would prevent someone from adding a cvs, arch 
or svn policy to the repository, and the other draconian license 
restrictions make it difficult to use, but the features it offers over 
cvs might make it worthwhile anyway. Also it provides a neutral place to 
  host the repository (bkbits), like sourceforge is doing for us currently.

If there are any other suggestions or comments on this I'd like to hear 
them. Obviously the implementation details are up in the air here, and I 
know that some of you can't/won't use bk. If there are suggestions for a 
  better system and a way to host it (preferably neutrally) that would 
be great.


Joshua Brindle

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: [RFC] Upstream policy handling

[Luke Kenneth Casson Leighton]

On Sun, Sep 19, 2004 at 11:07:19AM -0400, Joshua Brindle wrote:

> If there are any other suggestions or comments on this I'd like to hear 
> them. Obviously the implementation details are up in the air here, and I 
> know that some of you can't/won't use bk. If there are suggestions for a 
>  better system and a way to host it (preferably neutrally) that would 
> be great.

 a little understood and even less deployed method of using
 cvs is to checkout a repository with a tag (e.g. NSA) and then
 checkout individual files with a different tag (e.g. REDHAT).

 the REDHAT repository should contain *only* the files that are
 different (or extra).

 first you do a cvs co -r NSA and then you do a cvs update -r REDHAT.

 what happens is that the files in the REDHAT repository overwrite
 those in the mainly NSA local checkout: examination of CVS/Entries
 shows a mixed selection of NSA and REDHAT tags.


 note that you _cannot_ due to a bug do a cvs co followed
 by a cvs update -r REDHAT.  if you then look in valtags
 (in CVSROOT on in this case the sourceforge repository)
 then you will find that there is an entry with two spaces:
 this causes all subsequent cvs operations to fail until the
 file is MANUALLY edited.  yes a bug was raised about this,
 and even a patch produced (several years ago) and no the cvs
 maintainers haven't bothered to fix it.

 a small script could be written to do the checkouts.

 maintainers of the REDHAT repository simply add whatever files that
 are different from the NSA repository to the REDHAT repository.

 one other thing that's useful is of course cvs diff -r NSA to check
 the differences between the REDHAT files and NSA ones: this works
 as expected.

 cvs update also works as expected.

 the only thing is that from a maintenance point of view (commits)
 it will be necessary to write some scripts (to go in CVSROOT)
 that double-check who is allowed to commit to the NSA tag and
 who to the REDHAT one.

 at this point i'd recommend doing the same trick as above, with
 subversion, over cvs any day...

 l.


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: [RFC] Upstream policy handling

[Luke Kenneth Casson Leighton]

On Sun, Sep 19, 2004 at 08:21:08PM +0100, Luke Kenneth Casson Leighton wrote:

>  note that you _cannot_ due to a bug do a cvs co 

 [i.e. cvs co with no tag]

> followed
>  by a cvs update -r REDHAT.  if you then look in valtags

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: [RFC] Upstream policy handling

[Russell Coker]

On Mon, 20 Sep 2004 01:07, Joshua Brindle <method@gentoo.org> wrote:
> The current upstream policy is a compositite of most changes made by
> distros and policy writers who may have different philosophies about how
> the policy should work.

Not really.  The different philosophies are the ones that are totally 
unmergable.  One example was posted here about a year ago that didn't seem to 
have a single domain or type name in common with the NSA policy.

> One example is our sysadmfile trim which happened a few weeks ago. Chris
>   PeBenito suggested this on the list only to be scrutinized, we have

Scrutiny is good!  It's when code is not scrutinised that the quality drops.  
Open Source is about scrutiny of code.

> since gone ahead with the changes but based on the feedback here Chris
> felt it a moot point to post the changes. Recently it was suggested by
> another distro (though vetoed by Steve) to make sysadmfile even more
> accessible to non-admins. This illustrates the radical difference in
> policy philosophies.

No, it demonstrates that Steve knows what's going on, has a plan, and is 
making everyone stick to it.  Convince Steve and your patch goes in to the 
CVS!

> I feel that distro tunables are undesirable. They bloat the policy in
> unnecessary ways and just don't make sense to me. Downstream vendors
> often apply their own patches to applications, so Gentoo, Debian and
> Redhat would have patchsets for apps rather than the upstream app having
> #ifdef REDHAT ... #elif DEBIAN and so on. (Russel pointed out that some
> apps have this sort of thing in upstream but that doesn't make it
> correct ;) )

OK, try maintaining a separate Gentoo policy patch for another year or so and 
see if you still think that distribution specific tunables are a bad 
idea.  ;)

> Specifically I think it would be optimal to set up a policy repository
> at bkbits.net (yes, this is bitkeeper, yes I know about the license,
> will cover that later). In this repository there should be branches for
> each vendor, and the NSA. Obviously each vendor pushes their own policy
> changes into their branch. If the NSA and/or any other vendors like the

The problem is that vendors will introduce bad patches.  Without the 
requirement to get the policy checked off by Steve the quality will drop 
while the number of unmerged patches steadily increases.

-- 
http://www.coker.com.au/selinux/   My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/  Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/    Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/  My home page

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: [RFC] Upstream policy handling

[Joshua Brindle]

Russell Coker wrote:

>On Mon, 20 Sep 2004 01:07, Joshua Brindle <method@gentoo.org> wrote:
>  
>
>>The current upstream policy is a compositite of most changes made by
>>distros and policy writers who may have different philosophies about how
>>the policy should work.
>>    
>>
>
>Not really.  The different philosophies are the ones that are totally 
>unmergable.  One example was posted here about a year ago that didn't seem to 
>have a single domain or type name in common with the NSA policy.
>
>  
>
Using different policy semantics (eg., not having seperate domain and 
file types) is not the same as having different philosophies. The 
philosophy differences I speak of are the differences between, for 
example, Redhat and Gentoo. It's no secret that Redhats primary goal is 
to make SELinux work in the system (and it's a noble goal). Gentoo's 
goal is to make the system secure, and if need be break legacy 
behaviour. These are radical differences.

>>One example is our sysadmfile trim which happened a few weeks ago. Chris
>>  PeBenito suggested this on the list only to be scrutinized, we have
>>    
>>
>
>Scrutiny is good!  It's when code is not scrutinised that the quality drops.  
>Open Source is about scrutiny of code.
>
>  
>
This sort of scrutity was an example of Redhat's vs. Gentoo's policy 
philosophy as above.

>>since gone ahead with the changes but based on the feedback here Chris
>>felt it a moot point to post the changes. Recently it was suggested by
>>another distro (though vetoed by Steve) to make sysadmfile even more
>>accessible to non-admins. This illustrates the radical difference in
>>policy philosophies.
>>    
>>
>
>No, it demonstrates that Steve knows what's going on, has a plan, and is 
>making everyone stick to it.  Convince Steve and your patch goes in to the 
>CVS!
>
>  
>
The Current CVS policy is heavily biased toward Redhat (and their 
SELinux goals). This leaves no room for others (such is why I'm 
suggesting this)

>>I feel that distro tunables are undesirable. They bloat the policy in
>>unnecessary ways and just don't make sense to me. Downstream vendors
>>often apply their own patches to applications, so Gentoo, Debian and
>>Redhat would have patchsets for apps rather than the upstream app having
>>#ifdef REDHAT ... #elif DEBIAN and so on. (Russel pointed out that some
>>apps have this sort of thing in upstream but that doesn't make it
>>correct ;) )
>>    
>>
>
>OK, try maintaining a separate Gentoo policy patch for another year or so and 
>see if you still think that distribution specific tunables are a bad 
>idea.  ;)
>
>  
>
PeBenito has maintained our policy for longer than that.  Distro 
tunables (and indeed many many of the current tunables) are 
fundamentally flawed.
Think about the difficulty of analyzing policy with X number of 
tunables. To do it properly you'd have to analyze X! permutations. Then 
take into account conditionals, and optional modules.

>>Specifically I think it would be optimal to set up a policy repository
>>at bkbits.net (yes, this is bitkeeper, yes I know about the license,
>>will cover that later). In this repository there should be branches for
>>each vendor, and the NSA. Obviously each vendor pushes their own policy
>>changes into their branch. If the NSA and/or any other vendors like the
>>    
>>
>
>The problem is that vendors will introduce bad patches.  Without the 
>requirement to get the policy checked off by Steve the quality will drop 
>while the number of unmerged patches steadily increases.
>
>  
>
eh? vendors would introduce bad patches to their own policy. Obviously 
this can already be done, I'm not sure what you are getting at here.
If vendors are concerned about their patches they'd still be able to 
post them to the list (also the changesets would be available at a 
specific central place for everyone so it would be far easier to see 
what people are doing to the policies, and the differences, etc)

Joshua

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: [RFC] Upstream policy handling

[Russell Coker]

On Mon, 20 Sep 2004 07:11, Joshua Brindle <method@gentoo.org> wrote:
> goal is to make the system secure, and if need be break legacy
> behaviour. These are radical differences.

In Red Hat we are breaking legacy behaviour when necessary.  For example by 
moving away from FAM.

> The Current CVS policy is heavily biased toward Redhat (and their
> SELinux goals). This leaves no room for others (such is why I'm
> suggesting this)

I was writing SE Linux policy for Debian long before anyone who was employed 
by Red Hat was doing any SE Linux work.  Now I work for Red Hat writing SE 
Linux policy and write Debian policy in my spare time.

I don't think that distributions other than Red Hat are being squeezed out.

The Debian goals are closer to Gentoo goals than that of Fedora.  For example 
there is no targeted policy in Debian.

> >OK, try maintaining a separate Gentoo policy patch for another year or so
> > and see if you still think that distribution specific tunables are a bad
> > idea.  ;)
>
> PeBenito has maintained our policy for longer than that.  Distro
> tunables (and indeed many many of the current tunables) are
> fundamentally flawed.
> Think about the difficulty of analyzing policy with X number of
> tunables. To do it properly you'd have to analyze X! permutations. Then
> take into account conditionals, and optional modules.

To be pedantic it would be 2^X not X!.

But you don't need to analyse those combinations.  The people who make the 
distribution need to analyse the default options and the recommended 
configurations (of which there should be a small number), and anyone who 
wants to customise their policy has to analyse it themself.

> >The problem is that vendors will introduce bad patches.  Without the
> >requirement to get the policy checked off by Steve the quality will drop
> >while the number of unmerged patches steadily increases.
>
> eh? vendors would introduce bad patches to their own policy. Obviously
> this can already be done, I'm not sure what you are getting at here.

If the difference between the vendor policy and the NSA policy is small then 
there is less scope for error.

> If vendors are concerned about their patches they'd still be able to
> post them to the list (also the changesets would be available at a
> specific central place for everyone so it would be far easier to see
> what people are doing to the policies, and the differences, etc)

How big are the patches between the Gentoo policy and the NSA policy?

-- 
http://www.coker.com.au/selinux/   My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/  Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/    Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/  My home page

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: [RFC] Upstream policy handling

[Joshua Brindle]

Russell Coker wrote:

>On Mon, 20 Sep 2004 07:11, Joshua Brindle <method@gentoo.org> wrote:
>  
>
>>goal is to make the system secure, and if need be break legacy
>>behaviour. These are radical differences.
>>    
>>
>
>In Red Hat we are breaking legacy behaviour when necessary.  For example by 
>moving away from FAM.
>
>  
>
I wouldn't call FAM legacy behavior.. having something for one release 
and cutting it means it was a mistake, not legacy. The legacy behavior I 
speak of is the sentiment that sysadm should be able to modify files all 
over the system, and users should be able to use any/all resources on 
the machine, etc, etc. The stuff that the targeted policy avoids 
altogether thus preserving said legacy behavior. There are numerous 
instances of this sort of thing in the strict policy as well (like 
widespread (ab)use of sysadmfile).

>>The Current CVS policy is heavily biased toward Redhat (and their
>>SELinux goals). This leaves no room for others (such is why I'm
>>suggesting this)
>>    
>>
>
>I was writing SE Linux policy for Debian long before anyone who was employed 
>by Red Hat was doing any SE Linux work.  Now I work for Red Hat writing SE 
>Linux policy and write Debian policy in my spare time.
>
>  
>
The policy was slanted toward Redhat long before you started working 
there. When I started using SELinux there were already policies for 
Redhat apps like anaconda, all packages were available primarilly as 
rpm's, etc.

>I don't think that distributions other than Red Hat are being squeezed out.
>
>  
>
I didn't say that, but I am saying that the changes we desire to make 
are not ones Redhat would be interested in and therefore would not get 
included in the upstream policy.
(except perhaps as distro tunables which I've already said I believe are 
flawed)

>The Debian goals are closer to Gentoo goals than that of Fedora.  For example 
>there is no targeted policy in Debian.
>
>  
>
Thats great, then having the Gentoo policy in a more centralized place 
that is accessible would be helpful to you in your capacity as Debian 
policy writer.

>>>OK, try maintaining a separate Gentoo policy patch for another year or so
>>>and see if you still think that distribution specific tunables are a bad
>>>idea.  ;)
>>>      
>>>
>>PeBenito has maintained our policy for longer than that.  Distro
>>tunables (and indeed many many of the current tunables) are
>>fundamentally flawed.
>>Think about the difficulty of analyzing policy with X number of
>>tunables. To do it properly you'd have to analyze X! permutations. Then
>>take into account conditionals, and optional modules.
>>    
>>
>
>To be pedantic it would be 2^X not X!.
>  
>
oops, I don't know what I was thinking :) 2^X is what I meant.

>But you don't need to analyse those combinations.  The people who make the 
>distribution need to analyse the default options and the recommended 
>configurations (of which there should be a small number), and anyone who 
>wants to customise their policy has to analyse it themself.
>
>  
>
If you want to be comprehensive in the analysis of the policy yes you 
would need to analyze them all. If you are unwilling to analyze certain 
tunables they should not exist.

>>>The problem is that vendors will introduce bad patches.  Without the
>>>requirement to get the policy checked off by Steve the quality will drop
>>>while the number of unmerged patches steadily increases.
>>>      
>>>
>>eh? vendors would introduce bad patches to their own policy. Obviously
>>this can already be done, I'm not sure what you are getting at here.
>>    
>>
>
>If the difference between the vendor policy and the NSA policy is small then 
>there is less scope for error.
>
>  
>
The same argument could be held for the kernel (and is probably more 
dangerous)  but the FC2 kernel ...
3008 files changed, 183715 insertions(+), 106139 deletions(-)

>>If vendors are concerned about their patches they'd still be able to
>>post them to the list (also the changesets would be available at a
>>specific central place for everyone so it would be far easier to see
>>what people are doing to the policies, and the differences, etc)
>>    
>>
>
>How big are the patches between the Gentoo policy and the NSA policy?
>
>  
>
I'm not totally sure at this moment, Chris will have to say something here
We do have the desire to make sweeping changes to the current policy 
however, these changes would not be possible to merge into the upstream 
policy (though past feedback here suggests they wouldn't be appreciated 
anyway)

Joshua

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: [RFC] Upstream policy handling

[Colin Walters]

On Sun, 2004-09-19 at 19:48 -0400, Joshua Brindle wrote:
> >
> I'm not totally sure at this moment, Chris will have to say something here
> We do have the desire to make sweeping changes to the current policy 
> however, these changes would not be possible to merge into the upstream 
> policy (though past feedback here suggests they wouldn't be appreciated 
> anyway)

As we discussed on IRC, at least for the sysadmfile removals, there's an
easy way to preserve the existing semantics and keep the patch
mergeable: just use another attribute instead of sysadmfile.  



--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: [RFC] Upstream policy handling

[Daniel J Walsh]

I think we do want to start moving strict policy back.  A lot of the 
changes and tunables we added were to make
SELinux work in a mainstream operating system.  This finally led us to 
the targeted policy which can satisfy our
desire to add some SELinux functionality to the Masses without leading 
them to turn it off and worse bury our
support centers with calls.  :^(  I see even targeted policy slowly 
moving toward strict policy over then next few
years as we better undestand how MAC can work in a mainstream operating 
system.

So I have no problem with moving strict policy back towards a more 
strict behavior and the elimination of some tunables.
(Singleuserdomain should be eliminated).  Some of the unlimitedXYZ 
should be removed also, as long as the people using
strict policy can put up with the pain, and it would probably force us 
to fix some more applications. 

As far as the policy having a Red Hat bent, this is because we have 
probably submitted more patches to policy then any other
distro.  

I would like to get to the point that policy-sources would only be 
installed like kernel-sources is now.  IE only required for
developers. 

Allowing sysadmin's to configure policy via booleans is in my opinion a 
much better way to go.

I believe that having Stephen and NSA as being the final Policy CZar is 
the way to go and I worry about distributions, not
submitting the patches to policy for peer review.

Dan

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: [RFC] Upstream policy handling

[Christopher J. PeBenito]

On Sun, 2004-09-19 at 23:33, Colin Walters wrote:
> As we discussed on IRC, at least for the sysadmfile removals, there's an
> easy way to preserve the existing semantics and keep the patch
> mergeable: just use another attribute instead of sysadmfile.  

And my response was that it was not a clean way to do it imo.  I think
sysadmfile is an overused attribute.  You're suggesting adding another
attribute to fix an attribute problem.  The way I did it was to reduce
the sysadmfile types, and then add a tunable that gives back full access
if needed by using { file_type -shadow_t }, which is basically what
sysadmfile is currently.  If there are other references to sysadmfile,
they can also be replaced with the above set.  I don't see how this is
less mergeable.

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



--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: [RFC] Upstream policy handling

[Colin Walters]

On Mon, 2004-09-20 at 08:56 -0400, Christopher J. PeBenito wrote:

> And my response was that it was not a clean way to do it imo.  I think
> sysadmfile is an overused attribute.  You're suggesting adding another
> attribute to fix an attribute problem.  The way I did it was to reduce
> the sysadmfile types, and then add a tunable that gives back full access
> if needed by using { file_type -shadow_t }, which is basically what
> sysadmfile is currently.  If there are other references to sysadmfile,
> they can also be replaced with the above set.  I don't see how this is
> less mergeable.

I'd need to see your patch, but if sysadmfile is really as close to
{ file_type -shadow_t } as you say, then that sounds fine too.



--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

File types that are not sysadmfiles...

[Daniel J Walsh]

grep file_type policy.conf | grep -v sysadmfile | grep "^type "
type device_t, file_type, dev_fs;
type printer_device_t, file_type, device_type, dev_fs;
type shadow_t, file_type;
type policy_config_t, file_type;
type policy_src_t, file_type;
type httpd_php_exec_t, file_type, exec_type;
type lvm_control_t, file_type, device_type, dev_fs;
type rpmbuild_exec_t, file_type, exec_type;
type vmware_user_exec_t, file_type, exec_type;
type vmware_device_t, file_type, device_type, dev_fs;
type vmware_user_var_run_t, file_type, pidfile;
type vmware_user_file_t, homedirfile, file_type;
type vmware_user_conf_t, homedirfile, file_type;
type watchdog_device_t, file_type, device_type, dev_fs;


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: File types that are not sysadmfiles...

[Russell Coker]

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

On Tue, 21 Sep 2004 06:44, Daniel J Walsh <dwalsh@redhat.com> wrote:
> grep file_type policy.conf | grep -v sysadmfile | grep "^type "
> type printer_device_t, file_type, device_type, dev_fs;
> type httpd_php_exec_t, file_type, exec_type;
> type lvm_control_t, file_type, device_type, dev_fs;
> type vmware_user_exec_t, file_type, exec_type;
> type vmware_device_t, file_type, device_type, dev_fs;
> type vmware_user_var_run_t, file_type, pidfile;
> type vmware_user_file_t, homedirfile, file_type;
> type vmware_user_conf_t, homedirfile, file_type;
> type watchdog_device_t, file_type, device_type, dev_fs;

The above are all bugs in the policy.  I have attached a patch that fixes them 
along with a few other minor things.

-- 
http://www.coker.com.au/selinux/   My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/  Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/    Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/  My home page

[-- Attachment #2: diff --]
[-- Type: text/x-diff, Size: 12418 bytes --]

diff -ru /usr/src/se/policy/domains/program/hostname.te ./domains/program/hostname.te
--- /usr/src/se/policy/domains/program/hostname.te	2004-09-16 18:06:45.000000000 +1000
+++ ./domains/program/hostname.te	2004-09-16 21:39:22.000000000 +1000
@@ -1,4 +1,4 @@
-#DESC hostname - show or set the system's host name
+#DESC hostname - show or set the system host name
 #
 # Author: Russell Coker <russell@coker.com.au>
 # X-Debian-Packages: hostname
diff -ru /usr/src/se/policy/domains/program/unused/cups.te ./domains/program/unused/cups.te
--- /usr/src/se/policy/domains/program/unused/cups.te	2004-09-15 16:31:22.000000000 +1000
+++ ./domains/program/unused/cups.te	2004-09-20 07:15:57.000000000 +1000
@@ -27,6 +27,7 @@
 
 allow cupsd_t devpts_t:dir search;
 
+allow cupsd_t device_t:lnk_file read;
 allow cupsd_t printer_device_t:chr_file rw_file_perms;
 allow cupsd_t urandom_device_t:chr_file { getattr read };
 dontaudit cupsd_t random_device_t:chr_file ioctl;
diff -ru /usr/src/se/policy/domains/program/unused/dpkg.te ./domains/program/unused/dpkg.te
--- /usr/src/se/policy/domains/program/unused/dpkg.te	2004-08-28 12:05:02.000000000 +1000
+++ ./domains/program/unused/dpkg.te	2004-09-11 19:48:52.000000000 +1000
@@ -295,9 +295,6 @@
 allow dpkg_t sysadmfile:{ file fifo_file sock_file } create_file_perms;
 allow dpkg_t sysadmfile:lnk_file create_lnk_perms;
 allow dpkg_t device_type:{ chr_file blk_file } getattr;
-ifdef(`devfsd.te', `', `
-allow dpkg_t device_type:{ chr_file blk_file } { create setattr rename };
-')
 dontaudit dpkg_t domain:{ socket unix_dgram_socket udp_socket unix_stream_socket tcp_socket fifo_file rawip_socket packet_socket } getattr;
 allow dpkg_t proc_kmsg_t:file getattr;
 allow dpkg_t root_dir_type:dir getattr;
diff -ru /usr/src/se/policy/domains/program/unused/hald.te ./domains/program/unused/hald.te
--- /usr/src/se/policy/domains/program/unused/hald.te	2004-09-17 22:01:26.000000000 +1000
+++ ./domains/program/unused/hald.te	2004-09-20 08:47:12.000000000 +1000
@@ -34,11 +34,10 @@
 allow hald_t self:capability { net_admin sys_admin };
 can_network(hald_t)
 can_ypbind(hald_t)
-dbusd_client(system, hald_t)
 
 allow hald_t device_t:lnk_file read;
 allow hald_t { fixed_disk_device_t removable_device_t }:blk_file { getattr read ioctl };
-allow hald_t event_device_t:chr_file { getattr read };
+allow hald_t event_device_t:chr_file { getattr read ioctl };
 
 ifdef(`updfstab.te', `
 domain_auto_trans(hald_t, updfstab_exec_t, updfstab_t)
diff -ru /usr/src/se/policy/domains/program/unused/hotplug.te ./domains/program/unused/hotplug.te
--- /usr/src/se/policy/domains/program/unused/hotplug.te	2004-09-11 16:21:44.000000000 +1000
+++ ./domains/program/unused/hotplug.te	2004-09-16 22:01:03.000000000 +1000
@@ -69,6 +69,8 @@
 
 ifdef(`hald.te', `
 allow hotplug_t hald_t:unix_dgram_socket sendto;
+allow hald_t hotplug_etc_t:dir search;
+allow hald_t hotplug_etc_t:file { getattr read };
 ')
 
 # for killall
diff -ru /usr/src/se/policy/domains/program/unused/iptables.te ./domains/program/unused/iptables.te
--- /usr/src/se/policy/domains/program/unused/iptables.te	2004-09-21 14:39:14.000000000 +1000
+++ ./domains/program/unused/iptables.te	2004-08-24 18:16:47.000000000 +1000
@@ -56,7 +56,3 @@
 
 # system-config-network appends to /var/log
 allow iptables_t var_log_t:file { append };
-
-# for /usr/bin/tc
-allow iptables_t self:netlink_route_socket { create getattr bind nlmsg_read nlmsg_write read write };
- 
diff -ru /usr/src/se/policy/domains/program/unused/lvm.te ./domains/program/unused/lvm.te
--- /usr/src/se/policy/domains/program/unused/lvm.te	2004-09-11 16:21:44.000000000 +1000
+++ ./domains/program/unused/lvm.te	2004-09-21 14:41:09.000000000 +1000
@@ -16,7 +16,7 @@
 #
 type lvm_vg_t, file_type, sysadmfile;
 type lvm_metadata_t, file_type, sysadmfile;
-type lvm_control_t, file_type, device_type, dev_fs;
+type lvm_control_t, device_type, dev_fs;
 etcdir_domain(lvm)
 allow lvm_t var_t:dir search;
 lock_domain(lvm)
diff -ru /usr/src/se/policy/domains/program/unused/mta.te ./domains/program/unused/mta.te
--- /usr/src/se/policy/domains/program/unused/mta.te	2004-06-17 15:10:40.000000000 +1000
+++ ./domains/program/unused/mta.te	2004-09-20 02:30:12.000000000 +1000
@@ -48,6 +48,7 @@
 
 # for /var/spool/mail
 ra_dir_file(mta_delivery_agent, mail_spool_t)
+allow mta_delivery_agent mail_spool_t:file create;
 
 # for piping mail to a command
 can_exec(mta_delivery_agent, shell_exec_t)
diff -ru /usr/src/se/policy/domains/program/unused/postfix.te ./domains/program/unused/postfix.te
--- /usr/src/se/policy/domains/program/unused/postfix.te	2004-09-16 18:06:52.000000000 +1000
+++ ./domains/program/unused/postfix.te	2004-09-20 02:30:27.000000000 +1000
@@ -81,6 +81,9 @@
 domain_auto_trans(sysadm_t, postfix_master_exec_t, postfix_master_t)
 allow sysadm_t postfix_master_t:process { noatsecure siginh rlimitinh };
 role_transition sysadm_r postfix_master_exec_t system_r;
+domain_auto_trans(sysadm_mail_t, postfix_master_exec_t, system_mail_t)
+allow system_mail_t sysadm_t:process sigchld;
+allow system_mail_t privfd:fd use;
 ')dnl end direct_sysadm_daemon
 
 allow postfix_master_t privfd:fd use;
@@ -88,10 +91,16 @@
 allow postfix_master_t initrc_devpts_t:chr_file rw_file_perms;
 
 # postfix does a "find" on startup for some reason - keep it quiet
+dontaudit postfix_master_t selinux_config_t:dir search;
 can_exec({ sysadm_mail_t system_mail_t }, postfix_master_exec_t)
+ifdef(`distro_redhat', `
+file_type_auto_trans({ sysadm_mail_t system_mail_t }, postfix_etc_t, etc_aliases_t)
+', `
 file_type_auto_trans({ sysadm_mail_t system_mail_t }, etc_t, etc_aliases_t)
+')
 allow postfix_master_t sendmail_exec_t:file r_file_perms;
 allow postfix_master_t sbin_t:lnk_file { getattr read };
+domain_auto_trans(initrc_t, postfix_master_exec_t, postfix_master_t)
 ifdef(`pppd.te', `
 domain_auto_trans(pppd_t, postfix_master_exec_t, postfix_master_t)
 ')
@@ -338,3 +347,4 @@
 allow postfix_map_t self:capability setgid;
 allow postfix_map_t self:unix_dgram_socket create_socket_perms;
 dontaudit postfix_map_t var_t:dir search;
+can_network(postfix_map_t)
diff -ru /usr/src/se/policy/domains/program/unused/quota.te ./domains/program/unused/quota.te
--- /usr/src/se/policy/domains/program/unused/quota.te	2004-09-16 18:06:53.000000000 +1000
+++ ./domains/program/unused/quota.te	2004-03-06 05:49:35.000000000 +1100
@@ -17,6 +17,10 @@
 role sysadm_r types quota_t;
 allow quota_t admin_tty_type:chr_file { read write };
 
+domain_auto_trans(sysadm_t, quota_exec_t, quota_t)
+role sysadm_r types quota_t;
+allow quota_t admin_tty_type:chr_file { read write };
+
 type quota_flag_t, file_type, sysadmfile;
 type quota_db_t, file_type, sysadmfile;
 
diff -ru /usr/src/se/policy/domains/program/unused/watchdog.te ./domains/program/unused/watchdog.te
--- /usr/src/se/policy/domains/program/unused/watchdog.te	2004-09-11 16:21:45.000000000 +1000
+++ ./domains/program/unused/watchdog.te	2004-09-21 14:40:50.000000000 +1000
@@ -10,7 +10,7 @@
 #
 
 daemon_domain(watchdog, `, privmail')
-type watchdog_device_t, file_type, device_type, dev_fs;
+type watchdog_device_t, device_type, dev_fs;
 
 log_domain(watchdog)
 
diff -ru /usr/src/se/policy/file_contexts/program/fsadm.fc ./file_contexts/program/fsadm.fc
--- /usr/src/se/policy/file_contexts/program/fsadm.fc	2004-08-28 12:05:09.000000000 +1000
+++ ./file_contexts/program/fsadm.fc	2004-09-17 02:39:36.000000000 +1000
@@ -33,3 +33,4 @@
 /usr/bin/raw		--	system_u:object_r:fsadm_exec_t
 /sbin/partx		--	system_u:object_r:fsadm_exec_t
 /usr/bin/partition_uuid	--	system_u:object_r:fsadm_exec_t
+/sbin/partprobe		--	system_u:object_r:fsadm_exec_t
diff -ru /usr/src/se/policy/file_contexts/program/hald.fc ./file_contexts/program/hald.fc
--- /usr/src/se/policy/file_contexts/program/hald.fc	2004-09-15 16:31:23.000000000 +1000
+++ ./file_contexts/program/hald.fc	2004-09-16 21:56:09.000000000 +1000
@@ -2,3 +2,4 @@
 /usr/sbin/hald		--	system_u:object_r:hald_exec_t
 /usr/libexec/hal-hotplug-map -- system_u:object_r:hald_exec_t
 /etc/hal/device.d/printer_remove.hal -- system_u:object_r:hald_exec_t
+/etc/hal/capability.d/printer_update.hal -- system_u:object_r:hald_exec_t
diff -ru /usr/src/se/policy/file_contexts/program/postfix.fc ./file_contexts/program/postfix.fc
--- /usr/src/se/policy/file_contexts/program/postfix.fc	2004-07-13 09:08:05.000000000 +1000
+++ ./file_contexts/program/postfix.fc	2004-09-20 01:15:11.000000000 +1000
@@ -1,5 +1,8 @@
 # postfix
 /etc/postfix(/.*)?		system_u:object_r:postfix_etc_t
+ifdef(`distro_redhat', `
+/etc/postfix/aliases.*		system_u:object_r:etc_aliases_t
+')
 /etc/postfix/postfix-script.* -- system_u:object_r:postfix_exec_t
 /etc/postfix/prng_exch	--	system_u:object_r:postfix_prng_t
 /usr/lib(exec)?/postfix/.*	--	system_u:object_r:postfix_exec_t
diff -ru /usr/src/se/policy/macros/program/rssh_macros.te ./macros/program/rssh_macros.te
--- /usr/src/se/policy/macros/program/rssh_macros.te	2004-08-24 05:46:55.000000000 +1000
+++ ./macros/program/rssh_macros.te	2004-09-19 17:51:46.000000000 +1000
@@ -27,7 +27,7 @@
 base_file_read_access(rssh_$1_t);
 allow rssh_$1_t var_t:dir r_dir_perms;
 r_dir_file(rssh_$1_t, etc_t);
-r_dir_file(rssh_$1_t, etc_runtime_t);
+allow rssh_$1_t etc_runtime_t:file { getattr read };
 r_dir_file(rssh_$1_t, locale_t);
 can_exec(rssh_$1_t, bin_t);
 
diff -ru /usr/src/se/policy/types/device.te ./types/device.te
--- /usr/src/se/policy/types/device.te	2004-09-11 16:21:48.000000000 +1000
+++ ./types/device.te	2004-09-21 14:40:17.000000000 +1000
@@ -62,7 +62,7 @@
 #
 # printer_device_t is the type for printer devices
 #
-type printer_device_t, file_type, device_type, dev_fs;
+type printer_device_t, device_type, dev_fs;
 
 #
 # fixed_disk_device_t is the type of 
diff -ru /usr/src/se/policy/types/devpts.te ./types/devpts.te
--- /usr/src/se/policy/types/devpts.te	2004-09-11 16:21:48.000000000 +1000
+++ ./types/devpts.te	2004-09-21 14:40:27.000000000 +1000
@@ -10,7 +10,7 @@
 #
 # ptmx_t is the type for /dev/ptmx.
 #
-type ptmx_t, file_type, sysadmfile, device_type, dev_fs;
+type ptmx_t, sysadmfile, device_type, dev_fs;
 
 #
 # devpts_t is the type of the devpts file system and 
diff -ru /usr/src/se/policy/types/procfs.te ./types/procfs.te
--- /usr/src/se/policy/types/procfs.te	2004-09-16 18:07:10.000000000 +1000
+++ ./types/procfs.te	2004-09-16 21:49:45.000000000 +1000
@@ -11,7 +11,7 @@
 # proc_t is the type of /proc.
 # proc_kmsg_t is the type of /proc/kmsg.
 # proc_kcore_t is the type of /proc/kcore.
-# proc_mdtat_t is the type of /proc/mdstat.
+# proc_mdstat_t is the type of /proc/mdstat.
 #
 type proc_t, fs_type, proc_fs, root_dir_type;
 type proc_kmsg_t, proc_fs;
--- /usr/src/se/policy/domains/program/unused/apache.te	2004-08-28 12:05:01.000000000 +1000
+++ domains/program/unused/apache.te	2004-09-21 15:04:15.000000000 +1000
@@ -205,7 +205,7 @@
 # PHP Directives
 ##################################################
 
-type httpd_php_exec_t, file_type, exec_type;
+type httpd_php_exec_t, file_type, sysadmfile, exec_type;
 type httpd_php_t, domain;
 
 # Transition from the user domain to this domain.
--- /usr/src/se/policy/domains/program/unused/vmware.te	2004-09-11 16:21:45.000000000 +1000
+++ domains/program/unused/vmware.te	2004-09-21 15:06:29.000000000 +1000
@@ -24,22 +24,22 @@
 #
 # The vmware_user_exec_t type is for the user programs.
 #
-type vmware_user_exec_t, file_type, exec_type;
+type vmware_user_exec_t, file_type, sysadmfile, exec_type;
 
 # Type for vmware devices.
-type vmware_device_t, file_type, device_type, dev_fs;
+type vmware_device_t, device_type, dev_fs;
 
 # Type for files in /var/run when a user starts VMWare
-type vmware_user_var_run_t, file_type, pidfile;
+type vmware_user_var_run_t, file_type, sysadmfile, pidfile;
 
 # The sys configuration used for the /etc/vmware configuration files
-type vmware_sys_conf_t, file_type, sysadmfile;
+type vmware_sys_conf_t, file_type, sysadmfile, sysadmfile;
 
 # The user file type is for files created when the user is running VMWare
-type vmware_user_file_t, homedirfile, file_type;
+type vmware_user_file_t, homedirfile, file_type, sysadmfile;
 
 # The user file type for the VMWare configuration files
-type vmware_user_conf_t, homedirfile, file_type;
+type vmware_user_conf_t, homedirfile, file_type, sysadmfile;
 
 #########################################################################
 # Additional rules to start/stop VMWare

Re: File types that are not sysadmfiles...

[Colin Walters]

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

On Tue, 2004-09-21 at 15:08 +1000, Russell Coker wrote:

> --- /usr/src/se/policy/domains/program/unused/hald.te   2004-09-17
> 22:01:26.000000000 +1000
> +++ ./domains/program/unused/hald.te    2004-09-20 08:47:12.000000000
> +1000
> @@ -34,11 +34,10 @@
>  allow hald_t self:capability { net_admin sys_admin };
>  can_network(hald_t)
>  can_ypbind(hald_t)
> -dbusd_client(system, hald_t)

Why did you do this?  Certainly the HAL daemon is a client of the system
bus...



[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: File types that are not sysadmfiles...

[Russell Coker]

On Wed, 22 Sep 2004 00:42, Colin Walters <walters@redhat.com> wrote:
> On Tue, 2004-09-21 at 15:08 +1000, Russell Coker wrote:
> > --- /usr/src/se/policy/domains/program/unused/hald.te   2004-09-17
> > 22:01:26.000000000 +1000
> > +++ ./domains/program/unused/hald.te    2004-09-20 08:47:12.000000000
> > +1000
> > @@ -34,11 +34,10 @@
> >  allow hald_t self:capability { net_admin sys_admin };
> >  can_network(hald_t)
> >  can_ypbind(hald_t)
> > -dbusd_client(system, hald_t)
>
> Why did you do this?  Certainly the HAL daemon is a client of the system
> bus...

ifdef(`dbusd.te', `
allow hald_t system_dbusd_t:dbus { acquire_svc };
dbusd_client(system, hald_t)
')

In the above policy in hald.te someone had made a type and put dbus.te instead 
of dbusd.te.  As that didn't work as desired someone else apparently put 
dbusd_client(system, hald_t) later on in the policy.  We only need one 
instance of dbusd_client(system, hald_t), so now that the dbus.te bug is 
fixed I'm removing the extra one.

-- 
http://www.coker.com.au/selinux/   My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/  Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/    Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/  My home page

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: File types that are not sysadmfiles...

[Colin Walters]

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

On Wed, 2004-09-22 at 01:25 +1000, Russell Coker wrote:

> ifdef(`dbusd.te', `
> allow hald_t system_dbusd_t:dbus { acquire_svc };
> dbusd_client(system, hald_t)
> ')
> 
> In the above policy in hald.te someone had made a type and put dbus.te instead 
> of dbusd.te.  As that didn't work as desired someone else apparently put 
> dbusd_client(system, hald_t) later on in the policy.  We only need one 
> instance of dbusd_client(system, hald_t), so now that the dbus.te bug is 
> fixed I'm removing the extra one.

Ah ok, good catch then, thanks.


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: File types that are not sysadmfiles...

[Colin Walters]

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

On Tue, 2004-09-21 at 15:08 +1000, Russell Coker wrote:
 
>  # The sys configuration used for the /etc/vmware configuration files
> -type vmware_sys_conf_t, file_type, sysadmfile;
> +type vmware_sys_conf_t, file_type, sysadmfile, sysadmfile;

Also, typo here.

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: File types that are not sysadmfiles...

[James Carter]

Merged.

On Tue, 2004-09-21 at 01:08, Russell Coker wrote:
> On Tue, 21 Sep 2004 06:44, Daniel J Walsh <dwalsh@redhat.com> wrote:
> > grep file_type policy.conf | grep -v sysadmfile | grep "^type "
> > type printer_device_t, file_type, device_type, dev_fs;
> > type httpd_php_exec_t, file_type, exec_type;
> > type lvm_control_t, file_type, device_type, dev_fs;
> > type vmware_user_exec_t, file_type, exec_type;
> > type vmware_device_t, file_type, device_type, dev_fs;
> > type vmware_user_var_run_t, file_type, pidfile;
> > type vmware_user_file_t, homedirfile, file_type;
> > type vmware_user_conf_t, homedirfile, file_type;
> > type watchdog_device_t, file_type, device_type, dev_fs;
> 
> The above are all bugs in the policy.  I have attached a patch that fixes them 
> along with a few other minor things.
-- 
James Carter <jwcart2@epoch.ncsc.mil>
National Security Agency

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: [RFC] Upstream policy handling

[Daniel J Walsh]

Colin Walters wrote:

>On Mon, 2004-09-20 at 08:56 -0400, Christopher J. PeBenito wrote:
>
>  
>
>>And my response was that it was not a clean way to do it imo.  I think
>>sysadmfile is an overused attribute.  You're suggesting adding another
>>attribute to fix an attribute problem.  The way I did it was to reduce
>>the sysadmfile types, and then add a tunable that gives back full access
>>if needed by using { file_type -shadow_t }, which is basically what
>>sysadmfile is currently.  If there are other references to sysadmfile,
>>they can also be replaced with the above set.  I don't see how this is
>>less mergeable.
>>    
>>
>
>I'd need to see your patch, but if sysadmfile is really as close to
>{ file_type -shadow_t } as you say, then that sounds fine too.
>
>  
>
With russells latest patches sysadmfile is the same as file_type 
-shadow_t , so we should be able to have a
tunable to restrict sysadm_r access to sysadmfile.


>
>--
>This message was distributed to subscribers of the selinux mailing list.
>If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
>the words "unsubscribe selinux" without quotes as the message.
>  
>


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: [RFC] Upstream policy handling

[Russell Coker]

On Fri, 24 Sep 2004 02:43, Daniel J Walsh <dwalsh@redhat.com> wrote:
> >I'd need to see your patch, but if sysadmfile is really as close to
> >{ file_type -shadow_t } as you say, then that sounds fine too.
>
> With russells latest patches sysadmfile is the same as file_type
> -shadow_t , so we should be able to have a
> tunable to restrict sysadm_r access to sysadmfile.

Alternatively we could change sysadmfile to be more restrictive and use 
{ file_type -shadow_t } when the need the current sysadmfile behaviour.

The aim of my patch was not to have an attribute that gave the same result as 
{ file_type -shadow_t } but to make things more regular so we've got a 
consistent base for the next stage of development.

-- 
http://www.coker.com.au/selinux/   My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/  Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/    Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/  My home page

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: [RFC] Upstream policy handling

[Luke Kenneth Casson Leighton]

On Mon, Sep 20, 2004 at 07:29:50AM +1000, Russell Coker wrote:

> The Debian goals are closer to Gentoo goals than that of Fedora.  For example 
> there is no targeted policy in Debian.
 
 *lol* - there _is_ no policy for debian - no group has taken clear
 responsibility for it "official" like and said "this is it, this is
 what debian can run with" and i don't believe that is likely to
 happen.

 perhaps there _should_ be a targetted debian policy, it would perhaps
 make how-to-say selinux more acceptable for most debian users?

 l.


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: [RFC] Upstream policy handling

[Russell Coker]

On Mon, 20 Sep 2004 22:25, Luke Kenneth Casson Leighton <lkcl@lkcl.net> wrote:
> On Mon, Sep 20, 2004 at 07:29:50AM +1000, Russell Coker wrote:
> > The Debian goals are closer to Gentoo goals than that of Fedora.  For
> > example there is no targeted policy in Debian.
>
>  *lol* - there _is_ no policy for debian - no group has taken clear
>  responsibility for it "official" like and said "this is it, this is
>  what debian can run with" and i don't believe that is likely to
>  happen.

In Debian each package is owned by a person and that person has virtually 
total control over it.  I own the selinux-policy-default package in Debian, 
so therefore the official default for Debian is strict policy because I say 
so.

Another Debian developer may package the targeted policy, if so then Debian 
will have two policies to choose from, but the strict policy will remain the 
default.

Fedora has targeted policy as the default.  Different aims, different 
user-base, and a different default.

-- 
http://www.coker.com.au/selinux/   My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/  Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/    Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/  My home page

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: [RFC] Upstream policy handling

[Colin Walters]

On Sun, 2004-09-19 at 11:07 -0400, Joshua Brindle wrote:

> The current upstream policy is a compositite of most changes made by 
> distros and policy writers who may have different philosophies about
> how the policy should work.

Agreed, but we should take care in divergence; the upstream maintainers
have a lot of experience here, and the current policy serves as a strong
reference point.  I think Stephen's pointed out bugs in patches from
pretty much everyone...

> One example is our sysadmfile trim which happened a few weeks ago.

Maybe it's just me, but I wasn't all that convinced by Chris' arguments.
For accidental damage, it seems better to encourage people to do as much
as possible as staff_r.  As for malicious programs, I think if you've
run any malicious program as sysadm_r you're pretty much hosed.

How else does the Gentoo policy differ from the NSA example policy?

> If there are any other suggestions or comments on this I'd like to hear 
> them. Obviously the implementation details are up in the air here, and I 
> know that some of you can't/won't use bk. 

Right, "can't" is the operative word here, at least for me.  The
Bitkeeper license prohibits people who work on a competing system from
using the gratis version of Bitkeeper.

> If there are suggestions for a 
>   better system and a way to host it (preferably neutrally) that would 
> be great.

If you are set on this, I suggest GNU Arch.  It is actually better than
Bitkeeper in a number of ways (besides the obvious one of licensing);
for example, it supports cherry-picking (applying individual
changesets), and doesn't require anything other than an unmodified web
server for read access. 

As for hosting, unfortunately Sourceforge doesn't support anything
except CVS.  There is sourcecontrol.net, sort of like the Arch
equivalent of bkbits.net.



--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: [RFC] Upstream policy handling

[Joshua Brindle]

Colin Walters wrote:

>On Sun, 2004-09-19 at 11:07 -0400, Joshua Brindle wrote:
>
>  
>
>>The current upstream policy is a compositite of most changes made by 
>>distros and policy writers who may have different philosophies about
>>how the policy should work.
>>    
>>
>
>Agreed, but we should take care in divergence; the upstream maintainers
>have a lot of experience here, and the current policy serves as a strong
>reference point.  I think Stephen's pointed out bugs in patches from
>pretty much everyone...
>
>  
>
Obviosly, and bouncing questions/ideas off of them are important but 
they won't be around to monitor every policy patch forever. Further, 
I'll agree that the upstream policy serves as a 'comprehensive' 
reference but that policy (the sample policy) was (AFAIK) never meant to 
be used in production, and is useful for making systems work much more 
than making systems analyzably secure.

The divergence is not the problem, if divergence wasn't good then most 
applications wouldn't exist today. There is no compelling need for every 
vendor to shoehorn their policy into the sample, adding bloat and 
causing it's analyzability to go down. Policies whose goals are 
fundamentally different shouldn't have to be combined in an awkward way. 
The solution is to make a central repository for vendors to share their 
policies.

>>One example is our sysadmfile trim which happened a few weeks ago.
>>    
>>
>
>Maybe it's just me, but I wasn't all that convinced by Chris' arguments.
>For accidental damage, it seems better to encourage people to do as much
>as possible as staff_r.  As for malicious programs, I think if you've
>run any malicious program as sysadm_r you're pretty much hosed.
>
>  
>
Thats fine, you need not be convinced, we are going for a more secure 
policy rather than a more userfriendly policy. Every additional 
restriction on sysadm_t means better security. This is our policy goal 
and clearly not yours, showing exactly what the problem is.

>How else does the Gentoo policy differ from the NSA example policy?
>
>  
>
I'll leave this for Chris to answer

>>If there are any other suggestions or comments on this I'd like to hear 
>>them. Obviously the implementation details are up in the air here, and I 
>>know that some of you can't/won't use bk. 
>>    
>>
>
>Right, "can't" is the operative word here, at least for me.  The
>Bitkeeper license prohibits people who work on a competing system from
>using the gratis version of Bitkeeper.
>
>  
>
I figured that might be a problem for someone

>>If there are suggestions for a 
>>  better system and a way to host it (preferably neutrally) that would 
>>be great.
>>    
>>
>
>If you are set on this, I suggest GNU Arch.  It is actually better than
>Bitkeeper in a number of ways (besides the obvious one of licensing);
>for example, it supports cherry-picking (applying individual
>changesets), and doesn't require anything other than an unmodified web
>server for read access. 
>
>As for hosting, unfortunately Sourceforge doesn't support anything
>except CVS.  There is sourcecontrol.net, sort of like the Arch
>equivalent of bkbits.net.
>
>
>  
>
cool, will definately look at this

Joshua

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: [RFC] Upstream policy handling

[Colin Walters]

On Sun, 2004-09-19 at 19:24 -0400, Joshua Brindle wrote:

> Obviosly, and bouncing questions/ideas off of them are important but 
> they won't be around to monitor every policy patch forever. 

I don't know what we'd do without them though...

> Further, 
> I'll agree that the upstream policy serves as a 'comprehensive' 
> reference but that policy (the sample policy) was (AFAIK) never meant to 
> be used in production, 

I think the NSA was more saying that the sample policy is just that, a
sample.  I don't think they were implying you'd be crazy to run it in
production.

> and is useful for making systems work much more 
> than making systems analyzably secure.

I wouldn't really agree with this, particularly since we now have the
targeted policy.  The direction of the sample strict policy has been
returning to lesser privilege.

> The divergence is not the problem, if divergence wasn't good then most 
> applications wouldn't exist today.

Divergence here should be justified well, since it can have a large
effect on system security.

>  There is no compelling need for every 
> vendor to shoehorn their policy into the sample, adding bloat and 
> causing it's analyzability to go down.
>  Policies whose goals are 
> fundamentally different shouldn't have to be combined in an awkward way. 

I'm guessing what you're indirectly referring to is all the (tunable)
weakening that happened to the sample strict policy when Fedora was
first trying to integrate SELinux.  Again, now that we have the targeted
policy things are going back; Dan just asked for the removal of
unlimitedUsers for example.

If this is the problem, I think it's already been solved.

> >Maybe it's just me, but I wasn't all that convinced by Chris' arguments.
> >For accidental damage, it seems better to encourage people to do as much
> >as possible as staff_r.  As for malicious programs, I think if you've
> >run any malicious program as sysadm_r you're pretty much hosed.
> >
> >  
> >
> Thats fine, you need not be convinced, we are going for a more secure 
> policy rather than a more userfriendly policy. Every additional 
> restriction on sysadm_t means better security. 

This feels like handwaving.  sysadm_t is a special domain since it can
circumvent system security in many ways.  Not that restricting it isn't
useful, but the only justification I recall for e.g. preventing sysadm_t
from accessing device files was preventing accidental damage (i.e.
reliability), not security.

> This is our policy goal 
> and clearly not yours, showing exactly what the problem is.

I think we share the goal of security; I'd just like to see better
justification for some of these changes.

In particular I think our time is much better spent on adding policy for
more daemons, tightening the existing ones, and modifying programs to
make them SELinux-aware, rather than adding a few more relatively
trivial restrictions on sysadm_t.



--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: [RFC] Upstream policy handling

[Luke Kenneth Casson Leighton]

On Sun, Sep 19, 2004 at 07:24:43PM -0400, Joshua Brindle wrote:

> The divergence is not the problem, if divergence wasn't good then most 
> applications wouldn't exist today. There is no compelling need for every 
> vendor to shoehorn their policy into the sample, adding bloat and 
> causing it's analyzability to go down. 

... which is, in combination with the earlier responses about not
having divergent repositories, why i mentioned the thing about
multi-tagged CVS.

criteria to satisfy:

	1) the sample "strict" policy must be managed
	   exclusively by stephen et al.

	2) the sample "strict" policy should not include
	   absolutely everything [auditability and maintenance]

	3) ideally, REDHAT, Gentoo, Debian policies should be
	   based on the "strict" policy [too much work otherwise]

	4) ideally, all policies in 3) _should_ also be managed
	   through stephen et al {_someone's_ gotta be responsible]

	5) ideally, there should _be_ no number 3) above but
	   realistically this is in conflict with 2)

	6) there should be no distro "tunables" in the sample
	   "strict" policy.

therefore, a means to satisfy these criteria is to have a CVS repository
per distribution which contains only the files that are different from
the "strict" one.

the reasons for recommending this double-tagged approach over the
"put-the-entire-lot-of-the-nsa-strict-policy-files-into-another-cvs-tag"
approach are two-fold:

	1) maintaining totally separate cvs tags is a maintenance headache:
	   it's merge, merge, merge and it's boring.

	2) having separate tags FORCES maintainers of BOTH tags to be alert.

	   any commits in say the NSA tagged location will IMMEDIATELY be
	   pulled in by anyone doing a cvs update, NOT just when they next
	   do a merge-merge-merge.

	3) having a separate tag for REDHAT files that are additional or
	   different from the NSA tag minimises people's desire to _create_
	   such differences in the first place!


enough said: i won't mention this issue any more, it's up to you to
decide if a future maintenance headache warrants the above solution.

l.

p.s. if you like i can create a tiny test cvs repository plus example
cvs commands which demonstrates the principle of multi-tagging.


-- 
--
Truth, honesty and respect are rare commodities that all spring from
the same well: Love.  If you love yourself and everyone and everything
around you, funnily and coincidentally enough, life gets a lot better.
--
<a href="http://lkcl.net">      lkcl.net      </a> <br />
<a href="mailto:lkcl@lkcl.net"> lkcl@lkcl.net </a> <br />


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: [RFC] Upstream policy handling

[Thomas Bleher]

* Colin Walters <walters@verbum.org> [2004-09-20 01:17]:
> On Sun, 2004-09-19 at 11:07 -0400, Joshua Brindle wrote:
> > If there are any other suggestions or comments on this I'd like to hear 
> > them. Obviously the implementation details are up in the air here, and I 
> > know that some of you can't/won't use bk. 
> >
> > If there are suggestions for a 
> >   better system and a way to host it (preferably neutrally) that would 
> > be great.
> 
> If you are set on this, I suggest GNU Arch.  It is actually better than
> Bitkeeper in a number of ways (besides the obvious one of licensing);
> for example, it supports cherry-picking (applying individual
> changesets), and doesn't require anything other than an unmodified web
> server for read access. 

I'd like to add a data point here: I have been using Arch for all my
policy work and it just works great. Arch makes it very easy to have
parallel branches and to merge between them. I don't think I would have
been able to keep my policy in sync with the fedora policy without arch.

Personally I think it is better to have one policy which governs all
distros. But regardless how this is decided, I think it would be great
if all policies were easily accessible in one place. Recently I wanted
to add the gentoo policy into my arch repository so I could compare the
approaches and see which changes had been made. However I could not find
the gentoo policy in an easily accessible format (a tarball with all
policy, cvs repository, ...). If anyone can recommend a method to get
it, I would be really thankful.

Thomas

-- 
http://www.cip.ifi.lmu.de/~bleher/selinux/ - my SELinux pages
GPG-Fingerprint: BC4F BB16 30D6 F253 E3EA  D09E C562 2BAE B2F4 ABE7

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.