SELinux & Linux-privs projects

SELinux & Linux-privs projects

[Jeffry Smith]

Sent to both lists
Since I hadn't seen any traffic on the two lists about the other project, I 
thought I'd cross-send a message, to ensure the two communities are aware of 
what the other is doing.  I figure, although the projects are tackling 
different parts of the security of linux, there should be some overlap, since 
privileges should make it easier to do the type enforcement (I think), and the 
type enforcement can help with requirements for privileges (right?).

Comments?  

jeff


--
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: SELinux & Linux-privs projects

[Stephen Smalley]

On Thu, 11 Jan 2001, Jeffry Smith wrote:

> Sent to both lists
> Since I hadn't seen any traffic on the two lists about the other project, I 
> thought I'd cross-send a message, to ensure the two communities are aware of 
> what the other is doing.  I figure, although the projects are tackling 
> different parts of the security of linux, there should be some overlap, since 
> privileges should make it easier to do the type enforcement (I think), and the 
> type enforcement can help with requirements for privileges (right?).
> 
> Comments?  

The two mechanisms are mostly orthogonal, although SELinux can help
to support the capability model and perhaps to even replace it.  The
POSIX.1e capabilities can be used to decompose superuser privileges for
overriding the traditional Unix access controls.  SELinux provides a
flexible mandatory access control architecture that can support a wide
range of security policies.  There is no need for a mechanism to override
the SELinux mandatory access controls because the security policy can be
configured as needed to support fine-grained privileges for processes
with respect to the mandatory controls.  There is no need for any kind of
"trusted" subject that operates outside of the boundaries of the mandatory
access control architecture in SELinux.

To better support the capability mechanism, the ability to
use a capability is controlled by the SELinux mandatory access controls.
A parallel mandatory access control is defined for each capability
and must be granted by the security policy in order for the
capability to be used. Since SELinux provides subject labeling and 
can support labels derived both from the attributes of the user and the
program, it can restrict the use of capabilities to the appropriate
program through the security policy configuration.

In one of the predecessors of SELinux (the DTOS system), the NSA
implemented a different mechanism than the POSIX.1e capabilities
for decomposing superuser privileges.  The superuser privileges were
partitioned by having the security server return a set of override
decisions along with its access decisions, where these override decisions
could cause access to be granted even if the Unix access control would
ordinarily deny access.  Unlike the Linux capabilities, these override
decisions could be based on both the label of the subject and the label of
the relevant object. This mechanism permitted fine-grained decomposition
(e.g. permission to override DAC read restrictions could be limited to
files with certain security labels) and simpler management (through the
use of the centralized security policy).  Similar support could be added
to the Security-Enhanced Linux as well but is not present in the
current implementation.

--
Stephen D. Smalley, NAI Labs
sds@tislabs.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: SELinux & Linux-privs projects

[Huagang Xie]

In fact, the LIDS project(www.lids.org) extend the capability usage to
integrit in a MAC way. You can disable a capability world width and give 
the capability to the needed program( label the capability to a
subject).  

On Thu, 11 Jan 2001, Stephen Smalley wrote:

> 
> On Thu, 11 Jan 2001, Jeffry Smith wrote:
> 
> > Sent to both lists
> > Since I hadn't seen any traffic on the two lists about the other project, I 
> > thought I'd cross-send a message, to ensure the two communities are aware of 
> > what the other is doing.  I figure, although the projects are tackling 
> > different parts of the security of linux, there should be some overlap, since 
> > privileges should make it easier to do the type enforcement (I think), and the 
> > type enforcement can help with requirements for privileges (right?).
> > 
> > Comments?  
> 
> The two mechanisms are mostly orthogonal, although SELinux can help
> to support the capability model and perhaps to even replace it.  The
> POSIX.1e capabilities can be used to decompose superuser privileges for
> overriding the traditional Unix access controls.  SELinux provides a
> flexible mandatory access control architecture that can support a wide
> range of security policies.  There is no need for a mechanism to override
> the SELinux mandatory access controls because the security policy can be
> configured as needed to support fine-grained privileges for processes
> with respect to the mandatory controls.  There is no need for any kind of
> "trusted" subject that operates outside of the boundaries of the mandatory
> access control architecture in SELinux.
> 
> To better support the capability mechanism, the ability to
> use a capability is controlled by the SELinux mandatory access controls.
> A parallel mandatory access control is defined for each capability
> and must be granted by the security policy in order for the
> capability to be used. Since SELinux provides subject labeling and 
> can support labels derived both from the attributes of the user and the
> program, it can restrict the use of capabilities to the appropriate
> program through the security policy configuration.
> 
> In one of the predecessors of SELinux (the DTOS system), the NSA
> implemented a different mechanism than the POSIX.1e capabilities
> for decomposing superuser privileges.  The superuser privileges were
> partitioned by having the security server return a set of override
> decisions along with its access decisions, where these override decisions
> could cause access to be granted even if the Unix access control would
> ordinarily deny access.  Unlike the Linux capabilities, these override
> decisions could be based on both the label of the subject and the label of
> the relevant object. This mechanism permitted fine-grained decomposition
> (e.g. permission to override DAC read restrictions could be limited to
> files with certain security labels) and simpler management (through the
> use of the centralized security policy).  Similar support could be added
> to the Security-Enhanced Linux as well but is not present in the
> current implementation.
> 
> --
> Stephen D. Smalley, NAI Labs
> sds@tislabs.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.
> 

-- 
Happy Hacking

Linux Intrusion Detection System  
http://www.lids.org/



--
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: [Linux-privs-discuss] Re: SELinux & Linux-privs projects

[Christoph Hellwig]

On Fri, Jan 12, 2001 at 12:42:56AM +0800, Huagang Xie wrote:
> 
> 
> In fact, the LIDS project(www.lids.org) extend the capability usage to
> integrit in a MAC way. You can disable a capability world width and give 
> the capability to the needed program( label the capability to a
> subject).  

It's rather ugly compared to real filesystem capabilities and even
the elfcap hack.

	Christoph

-- 
Whip me.  Beat me.  Make me maintain AIX.


--
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: [Linux-privs-discuss] SELinux & Linux-privs projects

[Christoph Hellwig]

On Thu, Jan 11, 2001 at 09:44:54AM -0500, Jeffry Smith wrote:
> Sent to both lists
> Since I hadn't seen any traffic on the two lists about the other project, I 
> thought I'd cross-send a message, to ensure the two communities are aware of 
> what the other is doing.  I figure, although the projects are tackling 
> different parts of the security of linux, there should be some overlap, since 
> privileges should make it easier to do the type enforcement (I think), and the 

Linux-privs and other Posix1003.1e subsystems currenlty in development
for Linux provide a UNIXish way of trusted systems, while SELinux
implements ruleset-based security and is rather differnt and put
policy into the kernel, something that is dtringly disliked in UNIX.

So they are two rather different ways to archive the same goal.

	Christoph

-- 
Whip me.  Beat me.  Make me maintain AIX.


--
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: [Linux-privs-discuss] SELinux & Linux-privs projects

[Stephen Smalley]

On Thu, 11 Jan 2001, Christoph Hellwig wrote:

> Linux-privs and other Posix1003.1e subsystems currenlty in development
> for Linux provide a UNIXish way of trusted systems, while SELinux
> implements ruleset-based security and is rather differnt and put
> policy into the kernel, something that is dtringly disliked in UNIX.
> 
> So they are two rather different ways to achieve the same goal.

Allow me to clarify about SELinux.  I'll respond to your points
in reverse order.  SELinux and Linux-privs are NOT different ways
to achieve the same goal.  SELinux provides a flexible mandatory
access control architecture.  The architecture can enforce a wide
variety of security policies.  It can enforce the separation of
information based on confidentiality and integrity requirements.
This is quite different from Linux Privs, which provides a mechanism
for decomposing superuser privileges.  It is also quite different
from POSIX.1e mandatory access controls, which are tied to a 
specific kind of mandatory security policy.

It is also inaccurate to suggest that the issue is placing policy
in the kernel.  SELinux provides clean separation of policy from
enforcement, with the security policy cleanly encapsulated
in a single component of the operating system called the
security server with a general interface.  Many different
security server implementations are possible, including
implementations that consult user space servers.  The
example security server implementation consists of a
basic policy engine that consults a security policy configuration
read from a file.  This is also a false comparison, because
the POSIX.1e mandatory access control policy implementation would
likewise involve a kernel component, and it is more likely to
involve policy-specific code being used by other components of
the kernel.

--
Stephen D. Smalley, NAI Labs
sds@tislabs.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: [Linux-privs-discuss] SELinux & Linux-privs projects

[Christoph Hellwig]

On Thu, Jan 11, 2001 at 11:04:32AM -0500, Stephen Smalley wrote:
> Allow me to clarify about SELinux.  I'll respond to your points
> in reverse order.  SELinux and Linux-privs are NOT different ways
> to achieve the same goal.  SELinux provides a flexible mandatory
> access control architecture.  The architecture can enforce a wide
> variety of security policies.  It can enforce the separation of
> information based on confidentiality and integrity requirements.
> This is quite different from Linux Privs, which provides a mechanism
> for decomposing superuser privileges.

The capabilities do that, right.  But if I'm not completly wrong
Linux-Privs stands for all the Posix 1003.1e stuff, but currently
only caps are implemented, though work is done on other parts
(acl, aud, mac).

> It is also quite different
> from POSIX.1e mandatory access controls, which are tied to a 
> specific kind of mandatory security policy.

Capabilities and mac are of course different, otherwise you probably
won't find them in the same posix standard...

> It is also inaccurate to suggest that the issue is placing policy
> in the kernel.  SELinux provides clean separation of policy from
> enforcement, with the security policy cleanly encapsulated
> in a single component of the operating system called the
> security server with a general interface.  Many different
> security server implementations are possible, including
> implementations that consult user space servers.

Then you basically end up with rsbac.  But your current code does not
look like you provide support for that.

> The
> example security server implementation consists of a
> basic policy engine that consults a security policy configuration
> read from a file.  This is also a false comparison, because
> the POSIX.1e mandatory access control policy implementation would
> likewise involve a kernel component, and it is more likely to
> involve policy-specific code being used by other components of
> the kernel.

No.  The pocily for posix 1003.1e mac is set from usespace and stored
in extented attributes, at least in the TrustedBSD version, my initial
Linux hack and SGIs version.

	Christoph

-- 
Whip me.  Beat me.  Make me maintain AIX.


--
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: [Linux-privs-discuss] SELinux & Linux-privs projects

[Stephen Smalley]

> No.  The policy for posix 1003.1e mac is set from userspace and stored
> in extended attributes, at least in the TrustedBSD version, my initial
> Linux hack and SGIs version.

By "policy", are you simply referring to file labels?  What about
the security policy logic that determines whether access is granted?
Where is that implemented?  It sounds like there may be a misunderstanding
here.  In SELinux, file labels can likewise be set by applications
and are associated with files through a combination of a field in
the inode and a set of label mapping files.  We would have used extended
attributes, except that they weren't available in ext2fs.  The
format and contents of security labels can be arbitrarily changed
without modifying or even recompiling the file system code (or
networking code or process management code, etc).  The security policy
decisions are specified through a set of security policy
configuration files that can be edited and compiled into a 
binary representation that is loaded and used by the security server.
Most desired security policy changes can be implemented simply
by changing that configuration and reloading it.  If you want a 
radically new style of policy, you can reimplement the security server
itself, but that still doesn't require any changes or even recompilation
of the other components of the operating system.

The POSIX.1e MAC tightly couples policy and enforcement because
it is designed for a particular kind of security policy.
It assumes a certain kind of security label.  It assumes hierarchical
relationships among labels.  It assumes that it is
sufficient to treat all operations as being read, write, or execute.  
In order to support Type Enforcement or Role-Based Access
Control or other kinds of mandatory security, you are very likely
to need to change or at least recompile the file system code,
the networking code, etc.  

--
Stephen D. Smalley, NAI Labs
sds@tislabs.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: [Linux-privs-discuss] SELinux & Linux-privs projects

[Casey Schaufler]

Stephen Smalley wrote:

> The POSIX.1e MAC tightly couples policy and enforcement because
> it is designed for a particular kind of security policy.
> It assumes a certain kind of security label.

I don't know who told you that, but it certainly wasn't
anyone who worked on the standard. The 1e MAC specification
is explicitly devoid of any such assumptions. That's one
reason there's no specification on Moldy directories, for
example.

> It assumes hierarchical relationships among labels.

It assumes that there are two relationships, equality
and dominance, between labels. I can easily show labeling
schemes which are cyclic, but which can be represented
in terms of these relationships.

> It assumes that it is
> sufficient to treat all operations as being read, write, or execute.

That's because those are the only operations POSIX systems
support! It's implicit in being a POSIX (DRAFT) standard.

> In order to support Type Enforcement or Role-Based Access
> Control or other kinds of mandatory security, you are very likely
> to need to change or at least recompile the file system code,
> the networking code, etc.

Yes, and?

-- 

Casey Schaufler				Manager, Trust Technology, SGI
casey@sgi.com				voice: 650.933.1634
casey_p@pager.sgi.com			Pager: 888.220.0607

--
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: [Linux-privs-discuss] SELinux & Linux-privs projects

[Stephen Smalley]

On Thu, 11 Jan 2001, Casey Schaufler wrote:

> I don't know who told you that, but it certainly wasn't
> anyone who worked on the standard. The 1e MAC specification
> is explicitly devoid of any such assumptions. That's one
> reason there's no specification on Moldy directories, for
> example.

I assume that "devoid of any assumptions" refers to the kind
of label as opposed to being designed for a particular kind
of security policy.  Are you suggesting that POSIX.1e was
not designed specifically for lattice-based models like
BLP and Biba?  The fundamental statement of mandatory access
control policy in the standard is hardly suitable for all
mandatory security policies:  Subjects cannot cause information
labeled at some MAC label L1 to become accessible to subjects
at L2 unless L2 dominates L1.  You can't represent Type
Enforcement by such a statement.  And the kind of label is
implicit by the dominates relatinship.

> That's because those are the only operations POSIX systems
> support! It's implicit in being a POSIX (DRAFT) standard.

You can define distinct operations (permissions) in the
mandatory security policy for distinct kernel services
without altering the interfaces or behavior for discretionary
access controls.  

> > In order to support Type Enforcement or Role-Based Access
> > Control or other kinds of mandatory security, you are very likely
> > to need to change or at least recompile the file system code,
> > the networking code, etc.
> 
> Yes, and?

As discussed ad nauseum on the robust open source mailing list,
Type Enforcement is desirable for its support for ensuring that
applications are unbypassable and tamperproof, that processes
with any sort of privileges cannot execute untrustworthy
code, and for providing least privilege.  BLP and Biba
are not enough for everyone.  And I'm not suggesting that
Type Enforcement is the magic solution either - the
point is that we need a flexible mandatory access control
architecture so that the system can be customized and
can evolve easily to meet different security requirements.

--
Stephen D. Smalley, NAI Labs
sds@tislabs.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.

(offtopic) Re: [Linux-privs-discuss] SELinux & Linux-privs projects

[Andrew Morgan]

Stephen Smalley wrote:
> As discussed ad nauseum on the robust open source mailing list,

How 'open' is this 'robust open source' mailing list? Where is it
located, does it have any archives? [Google wasn't able to locate it for
me.]

Thanks

Andrew

--
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: [Linux-privs-discuss] SELinux & Linux-privs projects

[Christoph Hellwig]

On Thu, Jan 11, 2001 at 01:31:44PM -0500, Stephen Smalley wrote:
> > That's because those are the only operations POSIX systems
> > support! It's implicit in being a POSIX (DRAFT) standard.
> 
> You can define distinct operations (permissions) in the
> mandatory security policy for distinct kernel services
> without altering the interfaces or behavior for discretionary
> access controls. 

Sure you can.  But Posix 1003.1e is designed to fit nicely into
a UNIX/Posix enviroment.  And that's exactly why I like it.

> As discussed ad nauseum on the robust open source mailing list,
> Type Enforcement is desirable for its support for ensuring that
> applications are unbypassable and tamperproof, that processes
> with any sort of privileges cannot execute untrustworthy
> code, and for providing least privilege.

For this you have capabilities.  Look at the allowed set in filesystem
capabilities.  That's another fine part of Posix 1003.1e: it seperates
cleanly what does not belong together.

	Christoph

-- 
Whip me.  Beat me.  Make me maintain AIX.


--
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: SELinux & Linux-privs projects

[Stephen Smalley]

> For this you have capabilities.  Look at the allowed set in filesystem
> capabilities.  That's another fine part of Posix 1003.1e: it seperates
> cleanly what does not belong together.

A paper by Spencer Minear in this year's BSD Conference and Expo
provided a brief comparison of the POSIX.1e capability mechanism and
a BSD implementation of Type Enforcement.  You can find a copy under
http://www.bsdcon.com/proceedings/spencer_minear.  This ties in
with my earlier discussion of the advantages of using an
architecture like SELinux to provide similar functionality
to the capability mechanism, as was done in one of the predecessors
of SELinux (the DTOS system).  The paper also has some useful background
information on the development of Type Enforcement and its relationship to
MLS.  

--
Stephen D. Smalley, NAI Labs
sds@tislabs.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: [Linux-privs-discuss] SELinux & Linux-privs projects

[Casey Schaufler]

Stephen Smalley wrote:
> 
> On Thu, 11 Jan 2001, Casey Schaufler wrote:
> 
> > I don't know who told you that, but it certainly wasn't
> > anyone who worked on the standard. The 1e MAC specification
> > is explicitly devoid of any such assumptions. That's one
> > reason there's no specification on Moldy directories, for
> > example.
> 
> I assume that "devoid of any assumptions" refers to the kind
> of label as opposed to being designed for a particular kind
> of security policy.

No, it means that the developers of the DRAFT couldn't
agree on what the right policy was, so they made sure
that no one would have an advantage by having the DRAFT
specificly match their policy. For example, Sun was doing
restricted Bell&LaPadula sensitivity. SGI did modified
Bell&LaPadula sensitivity and Biba integrity. Data General,
well, we were never sure what they were up to, but it
sure sounded like a reasonably pure Bell&LaPadula. In
the early days AT&T was pushing for time stamp sorts of
policy, too.

> Are you suggesting that POSIX.1e was
> not designed specifically for lattice-based models like
> BLP and Biba?

I'm suggesting that the design goals included supporting
those policies, but also included generality. No one
who came to more than one meeting advocated anything
other than policy independence.

> The fundamental statement of mandatory access
> control policy in the standard is hardly suitable for all
> mandatory security policies:  Subjects cannot cause information
> labeled at some MAC label L1 to become accessible to subjects
> at L2 unless L2 dominates L1.  You can't represent Type
> Enforcement by such a statement.  And the kind of label is
> implicit by the dominates relatinship.

I'll take your word for it that you couldn't represent
TE using the 1e scheme.

> > That's because those are the only operations POSIX systems
> > support! It's implicit in being a POSIX (DRAFT) standard.
> 
> You can define distinct operations (permissions) in the
> mandatory security policy for distinct kernel services
> without altering the interfaces or behavior for discretionary
> access controls.

You're correct. If you really think it's valueable to
seperate left-hand-twiddle permission from write permission
the POSIX.1e scheme is not for you.


> ... - the
> point is that we need a flexible mandatory access control
> architecture so that the system can be customized and
> can evolve easily to meet different security requirements.

I have to disagree. It has not been the policy inflexibility
of MLS systems which have held them back, if in fact they
can be said to have been held back at all. It is the fact
that they're *different*. Flexible policy will not help in
the marketplace, it will hurt. We finally got people to the
point where they generally understood permission bits, when
along come NT ACLs, and the whole thing goes on the floor.
We'd be in much better shape if the MAC policies on MULTICS,
Solaris, HP/UX, AIX, and Irix where all the same. Flexibility?
Bad for the community.

-- 

Casey Schaufler				Manager, Trust Technology, SGI
casey@sgi.com				voice: 650.933.1634
casey_p@pager.sgi.com			Pager: 888.220.0607

--
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: [Linux-privs-discuss] SELinux & Linux-privs projects

[Stephen Smalley]

On Thu, 11 Jan 2001, Christoph Hellwig wrote:

> > It is also quite different
> > from POSIX.1e mandatory access controls, which are tied to a 
> > specific kind of mandatory security policy.
> 
> Capabilities and mac are of course different, otherwise you probably
> won't find them in the same posix standard...

I guess my antecedent was ambiguous.  I was trying to say that
the SELinux mandatory access controls are quite different from
POSIX.1e mandatory access controls, because SELinux provides
a flexible mandatory access control architecture that can
support many different kinds of security policies while
POSIX.1e is limited to a particular kind of security
policy (multi-level security, and perhaps Biba integrity
or other lattice-based models).  SELinux can support
lattice-based models like multi-level security, but it
can also support Type Enforcement, Role-Based Access
Control, and other models.  So POSIX.1e MAC only does
a subset of what SELinux does.

--
Stephen D. Smalley, NAI Labs
sds@tislabs.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: [Linux-privs-discuss] SELinux & Linux-privs projects

[Robert Watson]

On Thu, 11 Jan 2001, Stephen Smalley wrote:

> On Thu, 11 Jan 2001, Christoph Hellwig wrote:
> 
> > > It is also quite different
> > > from POSIX.1e mandatory access controls, which are tied to a 
> > > specific kind of mandatory security policy.
> > 
> > Capabilities and mac are of course different, otherwise you probably
> > won't find them in the same posix standard...
> 
> I guess my antecedent was ambiguous.  I was trying to say that the
> SELinux mandatory access controls are quite different from POSIX.1e
> mandatory access controls, because SELinux provides a flexible mandatory
> access control architecture that can support many different kinds of
> security policies while POSIX.1e is limited to a particular kind of
> security policy (multi-level security, and perhaps Biba integrity or
> other lattice-based models).  SELinux can support lattice-based models
> like multi-level security, but it can also support Type Enforcement,
> Role-Based Access Control, and other models.  So POSIX.1e MAC only does
> a subset of what SELinux does. 

I've run into a few limitations in the POSIX.1e MAC interface that I've
needed to work around and suggest directions for future improvement if
there's any desire towards moving to a more general MAC framework:

1) Dominance operator required -- mac_dominate() must return true, false,
   or an error (EINVAL), but is unable to return that dominance is
   undefined.  For un-ordered or partially ordered MAC schemes, this will
   cause problems for applications that rely on the ordering.  In this
   case, mac_dominate()  will often (or always) return 0, making it less
   useful; as it's not clear that mac_dominate() will be meaningful in an
   environment and if it is, what it means may not be consistent. 

2) Limited support for compound labels -- when more than one scheme is in
   use at a time, a compound mac label is required.  However, the
   dominance operator may be defined differently for different components
   of the label (for example, Biba dominate differs from MLS dominate). 
   When moving to different or more complex schemes, it's easy to imagine
   situations where mac_dominate() has to combine inconsistent results,
   and presumably always return 0 as a result. 

3) mac_dominate() is not meaningful without understanding the policy in
   question: that is, a userland application cannot use it for policy
   evaluation to determine whether a given operation on a given object is
   permitted, because mac_dominate() isn't an "is this allowed" request,
   it has to do with label relationships. 

Everyone has their own feelings on general access control frameworks and
policy mechanisms, but my feeling is that there are a number of
improvements that could be made to POSIX.1e to improve its usefulness with
regards to more arbitrary MAC policies.  This would include functions that
request an access control determination for a pair of labels and an
operation identifier, functions to determine inheritence when a subject
spawns a new object from an existing object (file from directory, packet
from interface, MIB hiearchies, etc), and so on.  Also, an interface to
push requests concerning MAC labels based on knowledge of the syntax and
semantics of a component of the label, but without assumptions in the
interface about what those might be.  In addition, a way to determine what
components of the label are available, and properties of the policy
enforcement environment. 

This won't allow applications invoking privilege to manage mandatory
labels to be completely free of knowledge of a policy, but it will allow
the application that is aware of one component of the policy to override
the policy via general interfaces, at the same time as not overriding
policies that it doesn't understand, or isn't intended to manipulate. 
Similarly, it will allow applications maintaining objects to rely on the
system policy evaluation when enforcing protections on these internal
objects.  The SELinux implementation allows some aspects of this (in
particular, allowing applications to use the standard system policy and
access control mechanisms), as does the NAI DTE implementation.  POSIX.1e
begins the process of moving towards a general labeling mechanism, and
though some changes could better support the kind of environment that I
envision.

Robert N M Watson             FreeBSD Core Team, TrustedBSD Project
robert@fledge.watson.org      NAI Labs, Safeport Network Services





--
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: [Linux-privs-discuss] SELinux & Linux-privs projects

[Jesse Pollard]

Christoph Hellwig <hch@ns.caldera.de>:
> On Thu, Jan 11, 2001 at 01:31:44PM -0500, Stephen Smalley wrote:
> > > That's because those are the only operations POSIX systems
> > > support! It's implicit in being a POSIX (DRAFT) standard.
> > 
> > You can define distinct operations (permissions) in the
> > mandatory security policy for distinct kernel services
> > without altering the interfaces or behavior for discretionary
> > access controls. 
> 
> Sure you can.  But Posix 1003.1e is designed to fit nicely into
> a UNIX/Posix enviroment.  And that's exactly why I like it.
> 
> > As discussed ad nauseum on the robust open source mailing list,
> > Type Enforcement is desirable for its support for ensuring that
> > applications are unbypassable and tamperproof, that processes
> > with any sort of privileges cannot execute untrustworthy
> > code, and for providing least privilege.
> 
> For this you have capabilities.  Look at the allowed set in filesystem
> capabilities.  That's another fine part of Posix 1003.1e: it seperates
> cleanly what does not belong together.

That is true for some security policies, not for others. POSIX is/was
based on the TSEC description, which is a very black/white model. It
does not support a more complex model such as a chinese wall structure.

That policy allows a user to access anything. But once the user accesses
an isolated object, the user can no longer access other objects. This
is related to the problem of "privileged communication" and "conflict
of interest" resolution. It also has some limitations when it comes to
certain privacy controls that are beginning to show up in industry and
government.

It appears that the SELinux implementation might be able to allow such
a structure to be created, and enforced.

-------------------------------------------------------------------------
Jesse I Pollard, II
Email: pollard@navo.hpc.mil

Any opinions expressed are solely my own.

--
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: [Linux-privs-discuss] SELinux & Linux-privs projects

[LA Walsh]

> That is true for some security policies, not for others. POSIX is/was
> based on the TSEC description, which is a very black/white model. It
> does not support a more complex model such as a chinese wall structure.
---
	No?  User1 wants to access the Firm-A defense file.  Runs a transition
program that adds Firm-A to the user's mac-label division list.  Now any
files or users that are working on Firm-B defense files (which have gone
through the same transition to mac-label w/division "firm-b" added) are 
inaccessible to the User1.  User1 is now permanently banned from firm-b
files by having transitioned into a user with 'firm-a' access.

	Seems like that implements perfectly a chinese wall /conflict of
interest model.  

	To my mind MAC+capabilities + a transitions config file = "domain
or type enforcement".  I see the transitions file as being fairly easy to
maintain.  	

	MAC and capabilities are basic building blocks from which you can
build other security models.

	I'm told you can build MAC and capabilities from DTE with 
sufficient rules, and perhaps that is so, but it seems that set of rules
would be considerably more complex than a "transitions" file with which
to implement DTE or Chinese Wall.

-l




--
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: [Linux-privs-discuss] SELinux & Linux-privs projects

[Jesse Pollard]

---------  Received message begins Here  ---------

> 
> 
> > That is true for some security policies, not for others. POSIX is/was
> > based on the TSEC description, which is a very black/white model. It
> > does not support a more complex model such as a chinese wall structure.
> ---
> 	No?  User1 wants to access the Firm-A defense file.  Runs a transition
> program that adds Firm-A to the user's mac-label division list.  Now any
> files or users that are working on Firm-B defense files (which have gone
> through the same transition to mac-label w/division "firm-b" added) are 
> inaccessible to the User1.  User1 is now permanently banned from firm-b
> files by having transitioned into a user with 'firm-a' access.
>
> 	Seems like that implements perfectly a chinese wall /conflict of
> interest model.  

Not unless every possible process suddenly becomes the "transition program".
The key here is that the user could just be running "more". If the user
has no restrictions, then it works. Once the user HAS done more on the
file, then restrictions may be imposed on the next file (depending on the
conflict). 

There is no need to run a special program before gaining access. No
intervention by the security manager other than defining the conflict matrix
in the first place.

A practical chinese wall has more complications too. A conflict is usually
specified in a contract ("propriatary information not to be divulged for
5 years" type of thing). This means that the conflict exists, but only
for the time interval since it was last imposed (most likely based on the
modification date of the file?). After the time interval, the conflict
is resolved, and the restriction removed. Even if the file is destroyed,
the conflict still remains.

Existing lattice models have no structure to handle time, they all expect
the state to last forever. This would help with the automatic downgrading
of sensitive data, if the data could be labled with time as well as
compartment/level ("not for release until after xxx hours...). These
transitions currently require intervention by the security administrator,
and the author (if available - he may have died... now the data may never
get downgraded).

> 	To my mind MAC+capabilities + a transitions config file = "domain
> or type enforcement".  I see the transitions file as being fairly easy to
> maintain.  	
> 
> 	MAC and capabilities are basic building blocks from which you can
> build other security models.
> 
> 	I'm told you can build MAC and capabilities from DTE with 
> sufficient rules, and perhaps that is so, but it seems that set of rules
> would be considerably more complex than a "transitions" file with which
> to implement DTE or Chinese Wall.

The "transitions" file has no means of detecting when enforcement must
take place. It has to be applied manually, and can't be done automatically
since the security monitor for lattice structured systems cannot interpret
it.

I grant that a DTE rule set may be more complex to define a lattice, but
the intent appears to be to provide initial definitions, and explore more
flexible definitions.

I would also imagine that they may be slower for really complex structures
too... perhaps we are seeing an analogue to the CISC/RISC cpu archetectures
from 10 years ago? Both were right, and both were wrong (and depended on the
application....)

Right now, I don't fully understand the difference in implementation, other
than the security monitor itself. It appears that the DTE can define how
the bits are interpreted. Lattice models tend to have a fixed definition of
the bits, limiting redefinition. I don't yet know if there is still a limit
on the number of bits, but perhaps that is more flexible too. 32 (or even
64) bits has always seemed too limiting. It certainly should be less
restrictive on the algorithm implemented for evaluation.

-------------------------------------------------------------------------
Jesse I Pollard, II
Email: pollard@navo.hpc.mil

Any opinions expressed are solely my own.

--
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: [Linux-privs-discuss] SELinux & Linux-privs projects

[LA Walsh]

>
> Not unless every possible process suddenly becomes the
> "transition program".
> The key here is that the user could just be running "more". If the user
> has no restrictions, then it works. Once the user HAS done more on the
> file, then restrictions may be imposed on the next file (depending on the
> conflict).
---
	True -- what you are talking about is 'floating' labels', where
as in 'POSIX' Information labels.  In a conforming implementation a subject
with label "inf1" that reads an object that has "inf2" gets relabeled
with the output of "float(inf1,inf2) and any written object gets the label
of the process.

	Using the output of the information labels to automatically
modify or add to 'mac_labels', would be an implementation-detail not
covered by the POSIX spec.

	Can have unintended consequences if someone who has read 'defense-A'
"su's" to root and writes /etc/passwd.  But you get the idea -- a lawyer
on "A" couldn't be a sysadmin.  The configuration would be an implementation
detail, but seems "doable".

>
> There is no need to run a special program before gaining access. No
> intervention by the security manager other than defining the
> conflict matrix
> in the first place.
---
	Right.  The 'information label' part of the posix spec was defined
to keep track of information flow.

>
> A practical chinese wall has more complications too. A conflict is usually
> specified in a contract ("propriatary information not to be divulged for
> 5 years" type of thing). This means that the conflict exists, but only
> for the time interval since it was last imposed (most likely based on the
> modification date of the file?). After the time interval, the conflict
> is resolved, and the restriction removed. Even if the file is destroyed,
> the conflict still remains.
>
> Existing lattice models have no structure to handle time, they all expect
> the state to last forever.
---
	A pure chinese wall model doesn't have the notion of time either.

> This would help with the automatic downgrading
> of sensitive data, if the data could be labled with time as well as
> compartment/level ("not for release until after xxx hours...). These
> transitions currently require intervention by the security administrator,
> and the author (if available - he may have died... now the data may never
> get downgraded).
----
	Well that may be the point.  Different requirements.  Most governments
would probably avoid systems that automatically declassified material
w/o human intervention at the time of the declassification.  The original
author cannot know how long the information should remain restricted --
especially if the time interval is after the author's death.  The author
may not be authorized to declassify their data in the future as well as
the present.


>
> The "transitions" file has no means of detecting when enforcement must
> take place. It has to be applied manually, and can't be done automatically
> since the security monitor for lattice structured systems cannot interpret
> it.
----
	Either the file is has a 'fixed' MAC label, or you can allow part
of the MAC label to float àla information labels.  The difference is whether
or not the user is "warned" and has to explicity change state or if they
are just automatically reclassified.  Personally, I think of the former
as more 'useful'.  I'd like to know that I'm entering down a one-way path
before I've done so.


> I would also imagine that they may be slower for really complex structures
> too... perhaps we are seeing an analogue to the CISC/RISC cpu
> archetectures
> from 10 years ago? Both were right, and both were wrong (and
> depended on the
> application....)
----
	Probably a very valid point.
-l


--
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: [Linux-privs-discuss] SELinux & Linux-privs projects

[LA Walsh]

> > >	Can have unintended consequences if someone who has read 'defense-A'
> >"su's" to root and writes /etc/passwd.  But you get the idea -- a lawyer
> >on "A" couldn't be a sysadmin.  The configuration would be an
> implementation
> >detail, but seems "doable".
>
> Is doable, but not with the rigid lattice structure. There the requirement
> is that the subject must already dominate the object before
> access. It would
> be possible to invoke a "transition security" as part of the security
> server. The only limitation then is the rigid definition of what
> the security
> bits mean.
---
	I don't have DS17 memorized, but I don't remember reading that
labels are rigid.  No where do I find that a 'user' has to be involved
in a transition.  The POSIX spec seems to state that "the MAC label of a
file
shall be dominated by the MAC label of a subject for the subject to read the
data
or attributes of a file."

	I don't see that as saying the MAC label of the process is RIGID.  I.e. -
suppose I define my domainates function as "is newer or of equal age".  A
process
always runs with a MAC label of 'current time'.  The MAC label on the file
is 'last modified time'.

	So under File Policy 1, p197, the current time (MAC label of the process)
must be 'newer or equal' to the last-mod time on a file.
	Under FP2 & 4: the 'last-mod' time must dominate, so a write or create
would set it to "equal" age (note that items of equal age dominate each
other).

	This is definintely not RIGID or lattice but does seem meet the POSIX
requirements or am I reading something wrong?

	Assuming my interpretation is valid, it seems that dynamically
altering the MAC-label of a Subject Process such that it dominates an
object to be read would still would still be a conforming DS17
implementation.


>
> Not really - it only prevents downward flow. For compartmentalization the
> user must first be an active member of the compartment, rather
> than assuming
> the compartment of the data if there are no conflicts. The
> "information label"
> only proves that the user is allowed. Not that the user may be
> "conditionally"
> allowed as long as there are no conflicts.
---
	Again, while it talks about the need for a user to possess
CAP_MAC_UPGRADE to upgrade their own MAC label at *their* request, I
don't see anything that prohibits the OS from doing this automatically
based on some set of rules.


> Rather than have two trusted programs that can change each field
> separately,
> it would be better to allow one program to request permission (gain the
> appropriate lable) to change either field. That requires the flexibility
> to have more security bits controlled by the server than are currently
> available.
---
	That's not within the scope of the POSIX spec.  It seems you are
requesting 'more bits' that "applications" could use as they see fit
that are managed by the OS.  I don't see this as some lack with the POSIX
security features as much as simply an implementation-dependent detail.
Linux could choose to provide more bits to user-apps.  Choosing to do
so or not is independent of the discussion concerning the merits of a
DS17 conforming implmentation vs. a DTE system.

-l


--
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: [Linux-privs-discuss] SELinux & Linux-privs projects

[Jesse Pollard]

"LA Walsh" <law@sgi.com>:
> > > >	Can have unintended consequences if someone who has read 'defense-A'
> > >"su's" to root and writes /etc/passwd.  But you get the idea -- a lawyer
> > >on "A" couldn't be a sysadmin.  The configuration would be an
> > implementation
> > >detail, but seems "doable".
> >
> > Is doable, but not with the rigid lattice structure. There the requirement
> > is that the subject must already dominate the object before
> > access. It would
> > be possible to invoke a "transition security" as part of the security
> > server. The only limitation then is the rigid definition of what
> > the security
> > bits mean.
> ---
> 	I don't have DS17 memorized, but I don't remember reading that
> labels are rigid.  No where do I find that a 'user' has to be involved
> in a transition.  The POSIX spec seems to state that "the MAC label of a
> file
> shall be dominated by the MAC label of a subject for the subject to read the
> data
> or attributes of a file."
>
> 	I don't see that as saying the MAC label of the process is RIGID.  I.e. -
> suppose I define my domainates function as "is newer or of equal age".  A
> process
> always runs with a MAC label of 'current time'.  The MAC label on the file
> is 'last modified time'.
> 
> 	So under File Policy 1, p197, the current time (MAC label of the process)
> must be 'newer or equal' to the last-mod time on a file.
> 	Under FP2 & 4: the 'last-mod' time must dominate, so a write or create
> would set it to "equal" age (note that items of equal age dominate each
> other).
> 
> 	This is definintely not RIGID or lattice but does seem meet the POSIX
> requirements or am I reading something wrong?

1. You are now using bits that are not under MAC control.

2. The date being shown cannot be used as part of an access policy (changed
   by the user/group). That would call for another field to contain the
   the real "last-mod" date, which could ONLY be changed by the OS+FS.

The "rigid" here means what can be stored in the label. Usually
this is limited to "level" access and/or a "compartment" mask. The ability to
change the label to include time does not exist, especially since the
owner can change the date and invalidate its use as a label.

> 	Assuming my interpretation is valid, it seems that dynamically
> altering the MAC-label of a Subject Process such that it dominates an
> object to be read would still would still be a conforming DS17
> implementation.

Subject altering is possible as long as the "MAC_UPGRADE" is permitted first.

> >
> > Not really - it only prevents downward flow. For compartmentalization the
> > user must first be an active member of the compartment, rather
> > than assuming
> > the compartment of the data if there are no conflicts. The
> > "information label"
> > only proves that the user is allowed. Not that the user may be
> > "conditionally"
> > allowed as long as there are no conflicts.
> ---
> 	Again, while it talks about the need for a user to possess
> CAP_MAC_UPGRADE to upgrade their own MAC label at *their* request, I
> don't see anything that prohibits the OS from doing this automatically
> based on some set of rules.

I don't believe an action is defined to allow a dynamic upgrade, the security
server would have to be the one doing the upgrade - and that would work though
now the security server is no longer matching the POSIX definition of providing

"The information label interfaces specified support the following functions: 

     test information label relationship - includes interfaces that will determine
		dominance between two labels, and equivalence between two labels. 
     float a label - includes an interface that will produce a label that is the
		combination of a label associated with a source, and the label
		associated with a destination. This new label will then be
		associated with the destination. 
     label validity - includes an interface for determining whether an information
		label is valid. The definition of a valid information label is
		implementation defined; however, examples include: the label is
		malformed, the label contains components that are not currently
		defined on the system, or the label is simply forbidden to be dealt
		with by the system. "

from "http://csrc.nist.gov/nistpubs/800-7/node17.html" POSIX Security Interfaces
and Mechanisms.

It doesn't appear to prevent additional functions though that would be extending
the POSIX interface. I do note that the "float a label" does not include the
subject.

> 
> > Rather than have two trusted programs that can change each field
> > separately,
> > it would be better to allow one program to request permission (gain the
> > appropriate lable) to change either field. That requires the flexibility
> > to have more security bits controlled by the server than are currently
> > available.
> ---
> 	That's not within the scope of the POSIX spec.  It seems you are
> requesting 'more bits' that "applications" could use as they see fit
> that are managed by the OS.  I don't see this as some lack with the POSIX
> security features as much as simply an implementation-dependent detail.
> Linux could choose to provide more bits to user-apps.  Choosing to do
> so or not is independent of the discussion concerning the merits of a
> DS17 conforming implmentation vs. a DTE system.

True, but it doesn't eliminate the need though, it just eliminates the
ability to implement it. (I have a LOT more to study before this statement
has any real assurance of correctness. I could be all wet here.)

I do have to go find that DS 16 document since I already know that
DS 17 has never been made public information (to my knowlege). I understand
that the differences were for clarification only, though.

-------------------------------------------------------------------------
Jesse I Pollard, II
Email: pollard@navo.hpc.mil

Any opinions expressed are solely my own.

--
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: [Linux-privs-discuss] SELinux & Linux-privs projects

[LA Walsh]

> > 	This is definintely not RIGID or lattice but does seem meet
> the POSIX
> > requirements or am I reading something wrong?
>
> 1. You are now using bits that are not under MAC control.
---
	?  I'm using bits not under MAC control?   What does that mean?
Is that defined somewhere in the POSIX spec?  It is Mandatory Access
Control.

	On a system, you can write to a file 'in the future', but you can't
read the future until it is the present or past (and your PID time dominates
the file time).  You can 'read' the past but can't write to the 'past'
without
updating the file label such that it is dominated by your process.  This is
mandatory -- not discretionary access.  Someone cannot "chmod a+r" "future"
files with the expectation that they can be read.  It's a consistent
Mandatory
Access Model.

	So...where does DS17 talk about "bits"?  I see a "mac_dominate" and
a "mac_equal" function.  They don't mention bits.


> 2. The date being shown cannot be used as part of an access
> policy (changed
>    by the user/group). That would call for another field to contain the
>    the real "last-mod" date, which could ONLY be changed by the OS+FS.
---
	Right.  The user couldn't change my "last-mod" label.  Which shouldn't
be viewed as the same bits as the 'file modification time".  I just
implemented
a policy (opaquely) that uses 'time' as a MAC check.

>
> The "rigid" here means what can be stored in the label. Usually
> this is limited to "level" access and/or a "compartment" mask.
---
	?Usually?  I think you may be making assumptions that impose
arbitrary limits on a conforming DS17 implementation.  We are comparing
DS17 features vs. DTE -- not some "usual" implementation.

	Another example.  "Dominate" may mean a 'chaos' function.  I assign
a "Chaos" value to files and processes.  System files are assumed to be
low in "Chaos" as are the system level processes that read them.  User
processes are assumed to be more chaotic and can only produces files
at higher chaos levels.  Since the state of these files is "more chaotic",
my system processes (or say, uid==0) cannot read more chaotic files.  This
prevents virii and worm infection of system processes as the system process
labels don't dominate user files and can't read them.  User processes,
don't dominate system files so they can't write to system files.

	Another example.  Dominate may be implmented to include both
a sensitivity/division (ala Bell-LaPadula), *AND* 'chaos' dominance (BIBA
integrity).

	The point is that the actual contents of a mac_label isn't defined
in POSIX nor is it said that they are fixed in time (that I am aware of).




> The ability to
> change the label to include time does not exist, especially since the
> owner can change the date and invalidate its use as a label.
---
	Changing the file date would be a separate operation from changing the
MAC_LABEL on the file.  The MAC_LABEL is only changed by the system or by
a process possessing appropriate privilege.

>
> > 	Assuming my interpretation is valid, it seems that dynamically
> > altering the MAC-label of a Subject Process such that it dominates an
> > object to be read would still would still be a conforming DS17
> > implementation.
>
> Subject altering is possible as long as the "MAC_UPGRADE" is
> permitted first.
---
	You need both CAP_MAC_RELABEL_SUBJ and CAP_MAC_UPGRADE[DOWNGRADE] for
a process to alter its own label.  However the kernel itself has "all"
capabilities on startup -- what the kernel sets and does on processes is
dependent on system security policy.

> I don't believe an action is defined to allow a dynamic upgrade,
> the security
> server would have to be the one doing the upgrade - and that
> would work though
> now the security server is no longer matching the POSIX
> definition of providing
>
> "The information label interfaces specified support the following
> functions:
>
>      test information label relationship - includes interfaces
> that will determine
> 		dominance between two labels, and equivalence
> between two labels.
>      float a label - includes an interface that will produce a
> label that is the
> 		combination of a label associated with a source,
> and the label
> 		associated with a destination. This new label will then be
> 		associated with the destination.
>      label validity - includes an interface for determining
> whether an information
> 		label is valid. The definition of a valid
> information label is
> 		implementation defined; however, examples include:
> the label is
> 		malformed, the label contains components that are
> not currently
> 		defined on the system, or the label is simply
> forbidden to be dealt
> 		with by the system. "
>
> from "http://csrc.nist.gov/nistpubs/800-7/node17.html" POSIX
> Security Interfaces
> and Mechanisms.
---
	What part of the above does my dynamic "mac_dominate" function
voilate?  My mac_dominate function said nothing about the implementation
of inf_float.

>
> It doesn't appear to prevent additional functions though that
> would be extending
> the POSIX interface. I do note that the "float a label" does not
> include the
> subject.
----
	I don't understand your statement.  "float a label"?  It takes
2 labels, a source and destination and writes a new label, based on those
inputs, to the destination.

>
> > > That requires the  flexibility
> > > to have more security bits controlled by the server than are currently
> > > available.
> > ---
> > 	That's not within the scope of the POSIX spec.  It seems you are
> > requesting 'more bits' that "applications" could use as they see fit
> > that are managed by the OS.  I don't see this as some lack with
> the POSIX
> > security features as much as simply an implementation-dependent detail.
> > Linux could choose to provide more bits to user-apps.  Choosing to do
> > so or not is independent of the discussion concerning the merits of a
> > DS17 conforming implmentation vs. a DTE system.
>
> True, but it doesn't eliminate the need though, it just eliminates the
> ability to implement it. (I have a LOT more to study before this statement
> has any real assurance of correctness. I could be all wet here.)
---
	The 'need' is dependent on the type of security policy you wish
to implement in a system.  Indeed, I'd tend to agree, in a complete
security-distribution, files that are in the "Trusted Base" or TCB, but that
are not in the kernel may want capabilities.  The problem is one of
"enforcement".  The kernel cannot enforce the minutia of which field in
a database is writeable by a user.  That layer of "abstraction" is normally
provided in an application that ensures conformity.

	The alternative would be a kernel that, for example, could parse
the passwd file and decide if an access was allowed or not.  Is it good
design for the kernel to manage bits that it doesn't enforce?  Maybe it
is convenient -- but once the usage monitoring leaves the kernel, those
bits are essentially 'user data' to the kernel (even though they may be
part of 'system software' in a TCB).



--
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: [Linux-privs-discuss] SELinux & Linux-privs projects

[Jesse Pollard]

I'll leave the other parts... I'm not fully familiar yet with DS16/17
and it is beginning to feel like we are discussing the differences
between macintosh apples and granny smith... (the representation of
the controls vs the representation of the policy limits -
It feels like I'm coming round to your thoughts too..)

> > > > That requires the  flexibility
> > > > to have more security bits controlled by the server than are currently
> > > > available.
> > > ---
> > > 	That's not within the scope of the POSIX spec.  It seems you are
> > > requesting 'more bits' that "applications" could use as they see fit
> > > that are managed by the OS.  I don't see this as some lack with
> > the POSIX
> > > security features as much as simply an implementation-dependent detail.
> > > Linux could choose to provide more bits to user-apps.  Choosing to do
> > > so or not is independent of the discussion concerning the merits of a
> > > DS17 conforming implmentation vs. a DTE system.
> >
> > True, but it doesn't eliminate the need though, it just eliminates the
> > ability to implement it. (I have a LOT more to study before this statement
> > has any real assurance of correctness. I could be all wet here.)
> ---
> 	The 'need' is dependent on the type of security policy you wish
> to implement in a system.  Indeed, I'd tend to agree, in a complete
> security-distribution, files that are in the "Trusted Base" or TCB, but that
> are not in the kernel may want capabilities.  The problem is one of
> "enforcement".  The kernel cannot enforce the minutia of which field in
> a database is writeable by a user.  That layer of "abstraction" is normally
> provided in an application that ensures conformity.
> 
> 	The alternative would be a kernel that, for example, could parse
> the passwd file and decide if an access was allowed or not.  Is it good
> design for the kernel to manage bits that it doesn't enforce?  Maybe it
> is convenient -- but once the usage monitoring leaves the kernel, those
> bits are essentially 'user data' to the kernel (even though they may be
> part of 'system software' in a TCB).

The kernel is the conduit of sensitive data. I think it will become
likely that the security data will be supported by a database server
at some time in the future - a password server. It would be usefull
to be able to have that daemon provide/accept data via the kernel interface
(and libc) for things like "getpwent". I think it likely that there should
be some symetry with a "modpwent" and "putpwent" (or "newpwent").

The restrictions on access to the data must be defined by something, and
I think that something is best served by the security monitor. Storage of
the data is better served by the database, as controled by the security server.
Especially since the security server already implements the functions that
can evaluate the policy being defined. The data flow for this is

1: user process <---> kernel interface <---> security monitor <---> logindb

or

2: user process <---> kernel interface <---> security monitor
                               \
                                +--> logindb

or even (though more work has to be done by the logindb and the
  	security monitor):

3: user process <---> kernel interface <---> logindb <---> security monitor

That way the security monitor determines what gets passed to the logindb.
I think just a "yes/no" decision should be sufficient, yes the data is passed
no, the data is not. The advantage is the elimination of passwd as a trusted
program, NIS as a trusted facility, and the password and shadow files as a
trusted disk file (though the equivalent may be present as part of the logindb
storage structure). It may possibly reduce the support complications of
various authentication daemons, since currently, each must be trusted to
handle security data safely. the authentication daemons only have to match
password/kerberos/... and not have to deal with accessing the passwd and
shadow files.

I would prefer 1 or 2 over 3 because it feels like a better and more auditable
operation. The logindb doesn't have to be trusted for anything but proper
storage/retrieval of the data. #3 also depends on logindb having access to
the user process credentials, and passing those same credentials for
evaluation by the security monitor, AND respecting the result of the decision.

And I prefer #1 over #2 for similar reasons, plus it starts defining a
series of interface definitions for other security database interfaces
(IPSec SAD for one, a generic authentication daemon for another, security
configuration control, policy database, audit event log, ...)

Much better than having two different security monitors that may make
conflicting decisions.

I haven't tried to implement it though...

-------------------------------------------------------------------------
Jesse I Pollard, II
Email: pollard@navo.hpc.mil

Any opinions expressed are solely my own.

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