SE Linux II?

SE Linux II?

[Eric Peters]

Recently you (Stephen Smalley) wrote:

To date, development on the LSM-based SELinux prototype (or SELinux II,
if you prefer) has focused on providing the same functionality present
in the original SELinux prototype (i.e. fine-grained and flexible
nondiscretionary access controls) as a loadable kernel module that
uses the LSM hooks rather than our own custom kernel patch.
Currently, SELinux II seems to be stable enough for release, and
does provide most of the functionality of the original prototype
(we're still working on the network access controls).  It should
be released soon on the NSA web site.

We are currently working off of the LSM kernel patch
(lsm-2001_08_07 against 2.4.7) from lsm.immunix.org, so you
could investigate integrating that into your FOLK patch if
you want to support SELinux II.

-------

Is there really any ETA on this release?

I'm just looking at maybe a rough date of perhaps a week/two etc? So that I
can do some planning for testin/moving some system over to it (so it would
hopefully at that point be more "upgradeable" without excessive kernel
recompiles correct?)

Thanks,

Eric


--
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: SE Linux II?

[Stephen Smalley]

On Mon, 13 Aug 2001, Eric Peters wrote:

> Is there really any ETA on this release?

I'm afraid that it is out of my hands.  We're currently blocked for
bureaucratic reasons rather than technical ones.  I expect that it
will occur within a week, but then again, it was supposed to happen
before the end of the July.  We're now working off of the lsm-2001_08_12
patch against kernel 2.4.8 from lsm.immunix.org.

> hopefully at that point be more "upgradeable" without excessive kernel
> recompiles correct?)

Well, sort of.  The LSM kernel patch is itself still under
rapid development.

--
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: SE Linux II?

[Eric Peters]

Is there an anonymous CVS server available for download?

This question is a little out of blue I suppose, but i'm looking to
hopefully setup a system of directory permission access so I can have:

/home/user1
/home/user1/subuser1
/home/user1/subuser1/subuser1subuser1
/home/user1/subuser1/subuser1subuser2
/home/user1/subuser2

Type of heirachy where the user1 can access everything under his
/home/user1, subuser1 can access everything under his subuser1 home
directoyr, and subuser2 acccess to his directory and etc.

Would something like this be implemented out of the box with SELinux, or
could I potentially modify SELinux with relative ease to accomplish this
type of access.  basically I want the "controlling" account "user1" to be
able and access any "subuser1", "subuser2" files, where "subuser1" also has
access to his child accounts "subuser1subuser1", and "subuser1subuser2"
(user1 could also access these/his "children's"-"child" accounts)

Thanks I appreciate all your time,

Eric

----- Original Message -----
From: "Stephen Smalley" <sds@tislabs.com>
To: "Eric Peters" <eric@peters.org>
Cc: <SELinux@tycho.nsa.gov>
Sent: Tuesday, August 14, 2001 5:20 AM
Subject: Re: SE Linux II?


>
> On Mon, 13 Aug 2001, Eric Peters wrote:
>
> > Is there really any ETA on this release?
>
> I'm afraid that it is out of my hands.  We're currently blocked for
> bureaucratic reasons rather than technical ones.  I expect that it
> will occur within a week, but then again, it was supposed to happen
> before the end of the July.  We're now working off of the lsm-2001_08_12
> patch against kernel 2.4.8 from lsm.immunix.org.
>
> > hopefully at that point be more "upgradeable" without excessive kernel
> > recompiles correct?)
>
> Well, sort of.  The LSM kernel patch is itself still under
> rapid development.
>
> --
> 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: SE Linux II?

[Stephen Smalley]

On Tue, 14 Aug 2001, Eric Peters wrote:

> Is there an anonymous CVS server available for download?

Umm, no.  If we could put it out via anonymous CVS, then
why wouldn't we be able to put it out on the web site?  Same
obstacle.  But I wouldn't worry - it should be available soon.

> This question is a little out of blue I suppose, but i'm looking to
> hopefully setup a system of directory permission access so I can have:
> 
> /home/user1
> /home/user1/subuser1
> /home/user1/subuser1/subuser1subuser1
> /home/user1/subuser1/subuser1subuser2
> /home/user1/subuser2
> 
> Type of heirachy where the user1 can access everything under his
> /home/user1, subuser1 can access everything under his subuser1 home
> directoyr, and subuser2 acccess to his directory and etc.
> 
> Would something like this be implemented out of the box with SELinux, or
> could I potentially modify SELinux with relative ease to accomplish this
> type of access.  basically I want the "controlling" account "user1" to be
> able and access any "subuser1", "subuser2" files, where "subuser1" also has
> access to his child accounts "subuser1subuser1", and "subuser1subuser2"
> (user1 could also access these/his "children's"-"child" accounts)

You could certainly modify or replace the example SELinux security server
to implement such a policy model.  That is relatively straightforward, and
does not require any changes to the rest of the kernel to support new
policy models.  The policy models that we chose to provide in the example
security server are Type Enforcement and Role-Based Access Control (and,
optionally, Multi-Level Security).  These policy models group users and
processes into equivalence classes known as roles and domains, and define
permissions based on these equivalence classes.  That tends to be much
easier to manage than a policy based on individual users, although you can
certainly define a unique role/domain for a particular user if you want.

With regard to the hierarchical relationship among users that you
describe, the example policy models don't really provide implicit support
for it, although you can explicitly represent such relationships through
the assignment of permissions.  A more complete Role-Based Access Control
implementation would directly support such relationships.  

For more information, I would recommend reading our papers published in
the Proceedings of the Freenix track of the 2001 Usenix Annual Technical
Conference and in the Proceedings of the 2001 Ottawa Linux Symposium.
Hopefully, they will also be up on the web site soon.  Until then,
you can find the Usenix paper at the Usenix web site 
(www.usenix.org/publications/library/proceedings/usenix01) if
you are a member and the Ottawa paper at the LWN web site 
(lwn.net/2001/features/OLS/pdf).  

--
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: SE Linux II?

[Eric Peters]

> You could certainly modify or replace the example SELinux security server
> to implement such a policy model.  That is relatively straightforward, and
> does not require any changes to the rest of the kernel to support new
> policy models.  The policy models that we chose to provide in the example
> security server are Type Enforcement and Role-Based Access Control (and,
> optionally, Multi-Level Security).  These policy models group users and
> processes into equivalence classes known as roles and domains, and define
> permissions based on these equivalence classes.  That tends to be much
> easier to manage than a policy based on individual users, although you can
> certainly define a unique role/domain for a particular user if you want.

I've been reading the PDFs for the better part of the morning (they are
definately covering the type of 'ignorant' questions I've been having)  I am
however still in a state of question about the representation of a 'domain'.
My understanding of a class is just aggregated types (read write/etc) which
could fall under the class 'file', yet what is the definition of a domain?

"Domains are treated just as any other type.  Domains are simply types
assigned to processes.  Because of this, types used as domains can also be
used as a type of related object, e.g. the type of its procfs entries.  The
term domain is often still used for convenience even thoug the security
server does not internally distinguish them from types."

As close as I am to starting to understand how the SS is setup I'm still
hung up over the use of 'domain' and what I should be thinking
about/referencing when reading the rest of the PDF and it comes up.  Is a
domain just an aggregation of classes?  The other destinction I suppose I
need to start making is the 'process' spaces, in many ways I've been
thinking of this as a very file oriented approach, yet with the transitions
between roles I guess I could see where there can be a process that would
have a unique set of types available.

Thanks, I really do appreciate your time, I'm currently not a member of
Usenix, however the student rate definately seems reasonable,

Eric


>
> With regard to the hierarchical relationship among users that you
> describe, the example policy models don't really provide implicit support
> for it, although you can explicitly represent such relationships through
> the assignment of permissions.  A more complete Role-Based Access Control
> implementation would directly support such relationships.
>
> For more information, I would recommend reading our papers published in
> the Proceedings of the Freenix track of the 2001 Usenix Annual Technical
> Conference and in the Proceedings of the 2001 Ottawa Linux Symposium.
> Hopefully, they will also be up on the web site soon.  Until then,
> you can find the Usenix paper at the Usenix web site
> (www.usenix.org/publications/library/proceedings/usenix01) if
> you are a member and the Ottawa paper at the LWN web site
> (lwn.net/2001/features/OLS/pdf).
>
> --
> 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: SE Linux II?

[Stephen Smalley]

On Wed, 15 Aug 2001, Eric Peters wrote:

> however still in a state of question about the representation of a 'domain'.
> My understanding of a class is just aggregated types (read write/etc) which
> could fall under the class 'file', yet what is the definition of a domain?

The term "class" refers to the kind of object, e.g. a directory, a regular
file, a device file, a TCP socket, a UDP socket, a message queue, etc.
For each class, a set of permissions are defined to control the
services/operations provided for that object.

The terms "domain" and "type" refer to a particular security attribute 
in the security context that is used by the Type Enforcement (TE) policy.
There have been many papers about TE and its variant DTE.  A "domain"
is simply a security tag for a process, and a "type" is simply a
security tag for an object.  The TE policy configuration specifies
authorized permissions for various (domain,type,class) triples for
operations on objects or (domain,domain,class) triples for operations
between subjects.  Abstractly, a domain is a set of processes with
the same set of permissions to objects (an equivalence class of
processes).  The ability to enter a domain can be limited to specific
programs by using the entrypoint permission, and the ability to
transition between domains is controlled.  Typically, a TE policy
directly authorizes users for specific domains.  The SELinux
example security server uses roles as an intermediate abstractions,
authorizing roles for specific domains and users for specific roles.

--
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: SE Linux II?

[Eric Peters]

That helps alot thanks!

Eric

----- Original Message -----
From: "Stephen Smalley" <sds@tislabs.com>
To: "Eric Peters" <eric@peters.org>
Cc: <SELinux@tycho.nsa.gov>
Sent: Wednesday, August 15, 2001 10:38 AM
Subject: Re: SE Linux II?


>
> On Wed, 15 Aug 2001, Eric Peters wrote:
>
> > however still in a state of question about the representation of a
'domain'.
> > My understanding of a class is just aggregated types (read write/etc)
which
> > could fall under the class 'file', yet what is the definition of a
domain?
>
> The term "class" refers to the kind of object, e.g. a directory, a regular
> file, a device file, a TCP socket, a UDP socket, a message queue, etc.
> For each class, a set of permissions are defined to control the
> services/operations provided for that object.
>
> The terms "domain" and "type" refer to a particular security attribute
> in the security context that is used by the Type Enforcement (TE) policy.
> There have been many papers about TE and its variant DTE.  A "domain"
> is simply a security tag for a process, and a "type" is simply a
> security tag for an object.  The TE policy configuration specifies
> authorized permissions for various (domain,type,class) triples for
> operations on objects or (domain,domain,class) triples for operations
> between subjects.  Abstractly, a domain is a set of processes with
> the same set of permissions to objects (an equivalence class of
> processes).  The ability to enter a domain can be limited to specific
> programs by using the entrypoint permission, and the ability to
> transition between domains is controlled.  Typically, a TE policy
> directly authorizes users for specific domains.  The SELinux
> example security server uses roles as an intermediate abstractions,
> authorizing roles for specific domains and users for specific roles.
>
> --
> 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: SE Linux II?

[Eric Peters]

That helps alot thanks!

Eric

----- Original Message -----
From: "Stephen Smalley" <sds@tislabs.com>
To: "Eric Peters" <eric@peters.org>
Cc: <SELinux@tycho.nsa.gov>
Sent: Wednesday, August 15, 2001 10:38 AM
Subject: Re: SE Linux II?


>
> On Wed, 15 Aug 2001, Eric Peters wrote:
>
> > however still in a state of question about the representation of a
'domain'.
> > My understanding of a class is just aggregated types (read write/etc)
which
> > could fall under the class 'file', yet what is the definition of a
domain?
>
> The term "class" refers to the kind of object, e.g. a directory, a regular
> file, a device file, a TCP socket, a UDP socket, a message queue, etc.
> For each class, a set of permissions are defined to control the
> services/operations provided for that object.
>
> The terms "domain" and "type" refer to a particular security attribute
> in the security context that is used by the Type Enforcement (TE) policy.
> There have been many papers about TE and its variant DTE.  A "domain"
> is simply a security tag for a process, and a "type" is simply a
> security tag for an object.  The TE policy configuration specifies
> authorized permissions for various (domain,type,class) triples for
> operations on objects or (domain,domain,class) triples for operations
> between subjects.  Abstractly, a domain is a set of processes with
> the same set of permissions to objects (an equivalence class of
> processes).  The ability to enter a domain can be limited to specific
> programs by using the entrypoint permission, and the ability to
> transition between domains is controlled.  Typically, a TE policy
> directly authorizes users for specific domains.  The SELinux
> example security server uses roles as an intermediate abstractions,
> authorizing roles for specific domains and users for specific roles.
>
> --
> 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.

RBAC/Types Hierarchy

[Eric Peters]

I'll try to push this on a new thread and keep it more "open" for anyone on
the list to respond :)

> You could certainly modify or replace the example SELinux security server
> to implement such a policy model.  That is relatively straightforward, and
> does not require any changes to the rest of the kernel to support new
> policy models.  The policy models that we chose to provide in the example
> security server are Type Enforcement and Role-Based Access Control (and,
> optionally, Multi-Level Security).  These policy models group users and
> processes into equivalence classes known as roles and domains, and define
> permissions based on these equivalence classes.  That tends to be much
> easier to manage than a policy based on individual users, although you can
> certainly define a unique role/domain for a particular user if you want.
>
> With regard to the hierarchical relationship among users that you
> describe, the example policy models don't really provide implicit support
> for it, although you can explicitly represent such relationships through
> the assignment of permissions.  A more complete Role-Based Access Control
> implementation would directly support such relationships.

I believe due to the nature of the extended hierarchy, that I will need to
have an explicit representation of the permissions.  I'm essentially looking
to implement a web hosting solution, which would allow a "controlling"
account to read/write, send signals to processes, (and possibly su?!? - via
explicit transitions) to the "child" accounts.  My current idea is to have a
new domain for every user, a new role for every user, and corresponding

/home/thisuser(|/.*)                     system_u:object_r:thisuser_home_t

entries in the file_contexts such that in the rbac config, when a
"controlling" account is defined, in addition to his "controllinguser_t"
type,
role controllinguser_r types {
        controllinguser_t
        thisuser_t
}

The thisuser_t can be associated, and transitions setup for
controllinguser_r to thisuser_r.

When installing SELinux, the install process requires an effective reboot
after changing the file_contexts so that the new contexts can be enforced on
the system.

This means of having so many domains, types, and roles, would require alot
of "maintenance" when new accounts are added/deleted/edited - however I'm
going to have to be managing that anyhow.  My real "question" is can the
setfiles, (assuming I suppose, it gets a domain established so in runtime it
can properly transition to the required roles and set file contexts), and
updating the policies be entirely done in a "run time" environment, or would
I need to go about redressing this need as well.  The means I've gone about
installing SELinux don't seem very sympathetic to this runtime change :)


Thanks again for all your time,

Eric




--
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: RBAC/Types Hierarchy

[Eric Peters]

> Sorry, I don't understand this statement.  After updating file_contexts,
> you do a 'make relabel'.  You only need to restart processes that
> were already started in a different domain based on the old labels.
> The reboot during the install is just for the initial setup. 
> And after updating the policy config, you can do a 'make load'.
> Of course, if your system is in enforcing mode, then these
> actions can only be done from the sysadm_r role.

perfect, thanks

Eric



--
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: RBAC/Types Hierarchy

[Stephen Smalley]

> When installing SELinux, the install process requires an effective reboot
> after changing the file_contexts so that the new contexts can be enforced on
> the system.

Sorry, I don't understand this statement.  After updating file_contexts,
you do a 'make relabel'.  You only need to restart processes that
were already started in a different domain based on the old labels.
The reboot during the install is just for the initial setup. 
And after updating the policy config, you can do a 'make load'.
Of course, if your system is in enforcing mode, then these
actions can only be done from the sysadm_r role.

--
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: RBAC/Types Hierarchy

[John Scroggins]

Eric Peters wrote:
> 
> I'll try to push this on a new thread and keep it more "open" for anyone on
> the list to respond :)

snip>

Thanks this is a good subject to tackle. 

btw: My name is John Scroggins, and I recently joined the list, and
asked if anyone was developing the documentation for admins and users..
Mr. Smalley responded with a "feel free", so I have been assessing the
whole situation and I have enlisted the help of several players:

1) system administrator with a major Linux company 
2) A CTO from A local ISP 
3) A Senior UNIX database architect 
4) A lawyer who has security environs experience 
5) myself -- Linux book author and technical writer

I want to get a broad view of all the possible scenarios, this will help
the community in the long run. Your questions are highly relevant to the
assembling of these docs, the more questions are posed and answered, the
more complete the documentation.
 
Would you like to get involved with the documentation effort for this
project?  

--JS
snip>

 

> You have received this message because you are subscribed to the selinux list.
> If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
> the words "unsubscribe selinux" without quotes as the message.

--
You have received this message because you are subscribed to the selinux list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: RBAC/Types Hierarchy

[Dale Amon]

On Wed, Aug 15, 2001 at 06:17:35PM -0700, John Scroggins wrote:
> again you exhibit the ability to add value to the subject of WHAT to
> document-- don't sell yourself short :) If you'd like, I can just tag
> your name as a contributor -- I am excited to attempt this (along with
> others), and I believe this whole project has substantial merit. If you
> change your mind let me know 
> 

I certainly have interest in techniques of applying this
to securing public servers that host web and other
services.

It's a jungle out here. You'd be surprised at the places
I get attacks from... Or given this list, probably not.

-- 
------------------------------------------------------
Use Linux: A computer        Dale Amon, CEO/MD
is a terrible thing          Village Networking Ltd
to waste.                    Belfast, Northern Ireland
------------------------------------------------------

--
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: RBAC/Types Hierarchy

[Eric Peters]

I'm afraid I would be a poor addition to counsel others in the use of
SELinux as I myself am just learning to use it.  (Still hoping I can manage
the Hierarchy restrictions - else I'll see about implementing them with a
standard file based ACL)

I am more than interested in perusing anything you guys are writing however.
There is definately to some regard, a need for multiple example policy files
to be developed for different operating environments, which could be easily
modeled and adapted by users of SELinux.

Look forward to reading your exploits,

Eric

----- Original Message -----
From: "John Scroggins" <dataefx@earthlink.net>
To: "Eric Peters" <eric@peters.org>
Cc: <SELinux@tycho.nsa.gov>
Sent: Wednesday, August 15, 2001 3:05 PM
Subject: Re: RBAC/Types Hierarchy


> Eric Peters wrote:
> >
> > I'll try to push this on a new thread and keep it more "open" for anyone
on
> > the list to respond :)
>
> snip>
>
> Thanks this is a good subject to tackle.
>
> btw: My name is John Scroggins, and I recently joined the list, and
> asked if anyone was developing the documentation for admins and users..
> Mr. Smalley responded with a "feel free", so I have been assessing the
> whole situation and I have enlisted the help of several players:
>
> 1) system administrator with a major Linux company
> 2) A CTO from A local ISP
> 3) A Senior UNIX database architect
> 4) A lawyer who has security environs experience
> 5) myself -- Linux book author and technical writer
>
> I want to get a broad view of all the possible scenarios, this will help
> the community in the long run. Your questions are highly relevant to the
> assembling of these docs, the more questions are posed and answered, the
> more complete the documentation.
>
> Would you like to get involved with the documentation effort for this
> project?
>
> --JS
> snip>
>
>
>
> > You have received this message because you are subscribed to the selinux
list.
> > If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov
with
> > the words "unsubscribe selinux" without quotes as the message.
>
> --
> You have received this message because you are subscribed to the selinux
list.
> If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov
with
> the words "unsubscribe selinux" without quotes as the message.
>


--
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: RBAC/Types Hierarchy

[John Scroggins]

Eric Peters wrote:
> 
> I'm afraid I would be a poor addition to counsel others in the use of
> SELinux as I myself am just learning to use it.  (Still hoping I can manage
> the Hierarchy restrictions - else I'll see about implementing them with a
> standard file based ACL)

snip>>
I think this may apply to all the people that were mentioned, but we
all  have to start somewhere. The more we explore the possibilities, the
better the documentation. Projects are only as successful as their docs
represent, your questions may turn out to be a life saver, for someone
else.   
snip>>
> 
> I am more than interested in perusing anything you guys are writing however.
> There is definately to some regard, a need for multiple example policy files
> to be developed for different operating environments, which could be easily
> modeled and adapted by users of SELinux.

snip>> 
again you exhibit the ability to add value to the subject of WHAT to
document-- don't sell yourself short :) If you'd like, I can just tag
your name as a contributor -- I am excited to attempt this (along with
others), and I believe this whole project has substantial merit. If you
change your mind let me know 

cheers  

--JS
snip>>
> 
> Look forward to reading your exploits,
> 
> Eric

> >
> > --
> > You have received this message because you are subscribed to the selinux
> list.
> > If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov
> with
> > the words "unsubscribe selinux" without quotes as the message.
> >

--
You have received this message because you are subscribed to the selinux list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: RBAC/Types Hierarchy

[John Scroggins]

Dale Amon wrote:
> 
> On Thu, Aug 16, 2001 at 11:29:32AM -0700, John Scroggins wrote:
> > Are you willing to give some input on this project?
> > Let me know, as I want to assemble a resource list (people), so we can
> > get started.
> >
> > Thanks for your response,
> >
> 
> I know a fair bit about the threat model, but only passing
> knowledge of selinux itself. Although I've been following
> the discussions, I've been so busy fire fighting that I've
> not really had the time to actually *try it*, as it appears
> to be not the sort of thing one can figure out and deploy
> over a weekend...
> 
> I'm not sure there is much useful input that I *can* give
> at this point. I just don't know enough in this area.
> 
> --

well lets look at this from another vantage point: 

The developers on this project have got there hands full trying to code
the components of SELinux. If there is no field testing, creative
comments, or general input, the whole documentation process will stand
still (as it has for the last few months). If this occurs, then we will
all have to sink or swim, never understanding the benefits of the
project.

I asked people from different backgrounds to help so that the docs would
not seem one-dimensional, proving a singular concept which may have no
relevance to the 
inquiry posed by the user or admin. 

This effort is in not a destination, rather, a journey .. Linux would
have never come this far if others had not joined in.        

> ------------------------------------------------------
> Use Linux: A computer        Dale Amon, CEO/MD
> is a terrible thing          Village Networking Ltd
> to waste.                    Belfast, Northern Ireland
> ------------------------------------------------------

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