All of lore.kernel.org
 help / color / mirror / Atom feed
From: Joshua Brindle <method@gentoo.org>
To: russell@coker.com.au
Cc: selinux <selinux@tycho.nsa.gov>,
	"pebe >> Chris PeBenito" <pebenito@gentoo.org>
Subject: Re: [RFC] Upstream policy handling
Date: Sun, 19 Sep 2004 19:48:19 -0400	[thread overview]
Message-ID: <414E1AC3.2070209@gentoo.org> (raw)
In-Reply-To: <200409200729.50087.russell@coker.com.au>

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.

  reply	other threads:[~2004-09-19 23:48 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-09-19 15:07 [RFC] Upstream policy handling Joshua Brindle
2004-09-19 19:21 ` Luke Kenneth Casson Leighton
2004-09-19 21:10   ` Luke Kenneth Casson Leighton
2004-09-19 20:46 ` Russell Coker
2004-09-19 21:11   ` Joshua Brindle
2004-09-19 21:29     ` Russell Coker
2004-09-19 23:48       ` Joshua Brindle [this message]
2004-09-20  3:33         ` Colin Walters
2004-09-20 12:26           ` Daniel J Walsh
2004-09-20 12:56           ` Christopher J. PeBenito
2004-09-20 15:53             ` Colin Walters
2004-09-20 20:44               ` File types that are not sysadmfiles Daniel J Walsh
2004-09-21  5:08                 ` Russell Coker
2004-09-21 14:42                   ` Colin Walters
2004-09-21 15:25                     ` Russell Coker
2004-09-21 15:45                       ` Colin Walters
2004-09-21 14:42                   ` Colin Walters
2004-09-22 20:22                   ` James Carter
2004-09-23 16:43               ` [RFC] Upstream policy handling Daniel J Walsh
2004-09-23 19:10                 ` Russell Coker
2004-09-20 12:25       ` Luke Kenneth Casson Leighton
2004-09-20 14:54         ` Russell Coker
2004-09-19 22:08 ` Colin Walters
2004-09-19 23:24   ` Joshua Brindle
2004-09-20  0:07     ` Colin Walters
2004-09-20 12:22     ` Luke Kenneth Casson Leighton
2004-09-20 15:17   ` Thomas Bleher

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=414E1AC3.2070209@gentoo.org \
    --to=method@gentoo.org \
    --cc=pebenito@gentoo.org \
    --cc=russell@coker.com.au \
    --cc=selinux@tycho.nsa.gov \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.