All of lore.kernel.org
 help / color / mirror / Atom feed
From: Casey Schaufler <casey@schaufler-ca.com>
To: Vikram Ambrose <Vikram.Ambrose@windriver.com>
Cc: SE Linux <selinux@tycho.nsa.gov>
Subject: Re: Request for multiple mailing lists
Date: Thu, 07 Aug 2008 10:47:34 -0700	[thread overview]
Message-ID: <489B3536.1060103@schaufler-ca.com> (raw)
In-Reply-To: <489B25B6.4080309@windriver.com>

Vikram Ambrose wrote:
> The SE Linux <selinux@tycho.nsa.gov> mailing list is being cluttered 
> with non selinux related material.
>
> Especially concerning refpolicy. And there is no set fast term used 
> for filtering such content, and needless to say a waste of bandwidth.
>

SELinux without policy is like a book without pages. Think of
the reference policy as the pages of the Old Testament.

> The SELinux list is not a place for non-SELinux maintainers, like 
> Tresys to discuss their policies within themselves. Would it be 
> alright for me and the other developers in my company to use the 
> SELinux list to discuss our policies?

Well I think so. It's kind of pointless to have a loadable policy if
everyone always uses the same one now, isn't it?

> Or the next company that decides to adopt SELinux?

You bet. Any issues that arise from any policy should be discussed here.
The basic underlying mechanisms of SELinux have changed more in the past
couple years more in support of policy desires and/or issues than for
any other reason (best I can tell anyhow).

> RedHat goes as far as to using the SELinux list as a communication 
> channel with Tresys. Unless there has been some agreement made between 
> the SELinux gatekeepers (NSA?) , Tresys and Redhat, I find this a 
> misuse of the mailing list.
>
> In the last 4 months, there have only been a handful of unique threads 
> concerning SELinux. A few by Stepehen, Eric, and myself. Everything 
> else is policy related.  With a total of 800 odd messages in this time 
> frame, its quite clear the policy discussion is cluttering the list. 
> As more and more people begin to adopt SELinux and face the battles of 
> SELinux integration, the userspace topic will become increasingly 
> popular.
>

Policy postings are prevalent because policy is where the flexibility of
SELinux lies.

> As I see it, the current list should be split into 3.
>
> 1. selinux-kernel
>    This would be a very low volume list. .Perhaps even with special 
> clearance to address security holes and concerns.

Please, no restricted lists. This is Open Source, after all.

> 2. selinux-userspace
>    This list would deal with userspace tools, wrappers and other non 
> kernel related material. Whether it be NSA's userspace tools or 
> support for 3rd party applications being compiled to be selinux-aware 
> using libselinux. This list is very important, if not the most 
> important of the three.

I could agree if the tool chain, applications, and runtime were not
so tightly integrated with and dependent on the policy.

> 3. selinux-policy
>    This list will deal with policies. A good place for Administrators 
> and policy developers to discuss the creation, debugging and use of 
> various policies. This as it stands would have the highest volume. 
> Nevertheless as suggested by Grift Dominick on #selinux, a forum would 
> be an even better place to discuss policies. Repository of ideas, 
> designs and development dedicated to policies. A forum for the 
> Administrator and Policy Developer.

The policy feeds into the tools which feed back into the policies.
The bulk of the tools are there to deal with policy, so I don't see
them being reasonably separable.

> Without this breakdown, the selinux list would be analogous to people 
> talking about GNU and C programming on lkml.
Which is something that happens from time to time. For good or ill
SELinux is a system, not a just kernel component. Anyone who is serious
about using or even monitoring what goes on with SELinux would need
to watch all three of the proposed lists to make sense of what's
going on.


That is of course the view from over here.

Thank you.


--
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:[~2008-08-07 17:47 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-08-07 16:41 Request for multiple mailing lists Vikram Ambrose
2008-08-07 17:47 ` Casey Schaufler [this message]
2008-08-07 18:55   ` Stanley A. Klein
2008-08-08  2:08   ` Russell Coker
2008-08-08  3:18     ` Casey Schaufler
2008-08-08  8:29     ` Andy Warner
2008-08-08 10:01       ` Vesa-Matti J Kari
2008-08-08 10:10         ` Andy Warner
2008-08-08 10:33           ` Vesa-Matti J Kari
2008-08-08 10:48             ` Russell Coker
2008-08-08 17:10               ` Joshua Brindle
2008-08-09  2:20                 ` max bianco
2008-08-09  2:45                   ` Russell Coker
2008-08-14 16:16                 ` Stephen Smalley
2008-08-15  5:18                   ` Russell Coker
2008-08-09  2:27               ` Casey Schaufler
2008-08-11 14:20 ` Vikram Ambrose
2008-08-11 15:34 ` Eric Paris
2008-08-11 17:17   ` Justin Mattock

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=489B3536.1060103@schaufler-ca.com \
    --to=casey@schaufler-ca.com \
    --cc=Vikram.Ambrose@windriver.com \
    --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.