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.From: Stephen Smalley <sds_at_tislabs.com>
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.From: Eric Peters <eric_at_peters.org>
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
>
> 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.From: Stephen Smalley <sds_at_tislabs.com>
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.From: Eric Peters <eric_at_peters.org>
> 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.From: Stephen Smalley <sds_at_tislabs.com>
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.From: Eric Peters <eric_at_peters.org>
That helps alot thanks!
Eric
>
> 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.From: Eric Peters <eric_at_peters.org>
That helps alot thanks!
Eric
>
> 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.From: Eric Peters <eric_at_peters.org>
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.From: Stephen Smalley <sds_at_tislabs.com>
> 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.From: Eric Peters <eric_at_peters.org>
> 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.From: John Scroggins <dataefx_at_earthlink.net>
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:
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.From: Eric Peters <eric_at_peters.org>
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
> 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.From: John Scroggins <dataefx_at_earthlink.net>
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.From: Dale Amon <amon_at_vnl.com>
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.From: John Scroggins <dataefx_at_earthlink.net>
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.
This archive was generated by hypermail 2.2.0 on Wed 11 Jun 2008 - 08:10:54 EDT