RE: dynamic context transitions - a seteuid parallel

RE: dynamic context transitions - a seteuid parallel

[Chad Hanson]

Luke Kenneth Casson Leighton wrote:

> okay, so this dynamic context transitions idea is pretty much
> identical to the seteuid equivalence proposals, and doing
> an equivalent of seteuid() it has been made abundantly clear
> [many times], and why, that it should not be done.
> 
> ... question: what it is about MLS that makes it so necessary to
> implement dynamic context transitions?
>

The DoD and associated communities have long requested and utilized the
privilege bracketing technique for information sharing solutions. Thus the
majority of existing applications are built to this framework. TCS and other
ISVs have a large existing code base of fielded accredited solutions based
on this framework.
 
> what are the alternatives?
> 

The alternatives are to overprivilege the application which is not
acceptable or to rewrite all of the applications before they can be used on
this new platform. The latter is goal which can and should be achieved or
time. Applications can streamlined and reorganized to fit into the modular
framework and of cooperating applications. This is a considerable effort and
major roadblock to utilizing SELinux and therefore Linux for these types of
applications.

The other main roadblocks are already being addressed with Linux getting
CAPP EAL3 and soon to be EAL4 certifications. Add LSPP and RBAC and you have
Linux system suitable to address secure information sharing needs.

-Chad

> l.
> 
> p.s. not that i actually understand MLS enough to understand 
> any answers
> [yet] but i'm just encouraging people to bounce ideas.
> 
> 

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

RE: dynamic context transitions - a seteuid parallel

[James Morris]

On Mon, 1 Nov 2004, Chad Hanson wrote:

> The alternatives are to overprivilege the application which is not
> acceptable or to rewrite all of the applications before they can be used on
> this new platform. The latter is goal which can and should be achieved or
> time. Applications can streamlined and reorganized to fit into the modular
> framework and of cooperating applications.

All the more reason to make dynamic transitions an optional feature, so 
even MLS systems can eventually switch it off.


- James
-- 
James Morris
<jmorris@redhat.com>



--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

RE: dynamic context transitions - a seteuid parallel

[Stephen Smalley]

On Mon, 2004-11-01 at 19:43, James Morris wrote:
> All the more reason to make dynamic transitions an optional feature, so 
> even MLS systems can eventually switch it off.

Separate kernel config option?  Certainly feasible, but a bit ugly since
it is simply a change within the existing setprocattr hook and exported
using the existing /proc/pid/attr/current interface as opposed to a
completely new interface.  setprocattr currently returns -EACCES upon
attempts to write to /proc/pid/attr/current; we would likely want it to
return -EOPNOTSUPP or similar if the option was disabled to clearly
indicate that the failure was due to missing kernel support rather than
permission denial.

In any event, is it really an option to ultimately disable a kernel API
once it is accepted?  API/ABI compatibility seems to be a strong
requirement for the kernel...

-- 
Stephen Smalley <sds@epoch.ncsc.mil>
National Security Agency


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: dynamic context transitions - a seteuid parallel

[Karl MacMillan]

Chad Hanson wrote:

>Luke Kenneth Casson Leighton wrote:
>  
>
>>what are the alternatives?
>>
>>    
>>
>
>The alternatives are to overprivilege the application which is not
>acceptable or to rewrite all of the applications before they can be used on
>this new platform.
>

It is not clear to me how the application is not overprivileged already 
if it is allowed to freely change between a privileged and unprivileged 
domain. The application must be fully trusted with the maximum access 
that it is granted. A misbehaving application will simply not drop 
access (obviously). Additionally, it seems that from an analysis stand 
point, these domains must be treated as equivalent and so it is not 
clear how the argument can be made that this increases assurance.

Karl

>The latter is goal which can and should be achieved or
>time. Applications can streamlined and reorganized to fit into the modular
>framework and of cooperating applications. This is a considerable effort and
>major roadblock to utilizing SELinux and therefore Linux for these types of
>  
>

>The other main roadblocks are already being addressed with Linux getting
>CAPP EAL3 and soon to be EAL4 certifications. Add LSPP and RBAC and you have
>Linux system suitable to address secure information sharing needs.
>
>-Chad
>
>  
>
>>l.
>>
>>p.s. not that i actually understand MLS enough to understand 
>>any answers
>>[yet] but i'm just encouraging people to bounce ideas.
>>
>>
>>    
>>
>
>--
>This message was distributed to subscribers of the selinux mailing list.
>If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
>the words "unsubscribe selinux" without quotes as the message.
>  
>


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

RE: dynamic context transitions - a seteuid parallel

[Frank Mayer]

> The DoD and associated communities have long requested and utilized
> the privilege bracketing technique for information sharing solutions.
> Thus the majority of existing applications are built to this
> framework. TCS and other ISVs have a large existing code base of
> fielded accredited solutions based on this framework.

To be fair, privilege bracketing came about primarily as a compromise of how to
meet the B2 requirements.  The ideal was something like ring brackets from the
Multics hardware, or even the simplified execution privilege levels from x86
architecture.  I'm sure that on of the first places privilege bracketing
argument was used was the B2 Trusted XENIX project, where we stretched greatly
the B2 requirements of least privilege and separation of security relevant code,
and successfully used the concept of privilege bracketing as en evaluation
strategy.

So I'll admit my culpability in weakening the B2 requirements, but that does not
mean privilege bracketing is a good idea just because we used it in the pass as
a means to expedite evaluations.  Rings and x86 privilege levels are truly
separate, distinct security domains.  Privilege bracketing is not (all software
in the process will typically have complete control over what privileges it
desires to use).  Unfortunately, like Trusted XENIX (and any Unix), the only
really distinct execution domains we have are processes, which has much greater
overhead cost for switching than rings.  

So if we were honest, the real reason we want to change security content is for
performance reasons, not security assurance reason.

Frank



--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: dynamic context transitions - a seteuid parallel

[Russell Coker]

On Tue, 2 Nov 2004 23:49, "Frank Mayer" <mayerf@tresys.com> wrote:
> So if we were honest, the real reason we want to change security content is
> for performance reasons, not security assurance reason.

Which probably made a lot of sense for Xenix, an 80286 was not a particularly 
fast CPU.

I've just done a quick test of exec time.  For a process to exec itself it 
takes an average of .9ms per exec on a P3-650.  In the past we have discussed 
at length issues related to modifying Samba for best operation under SE 
Linux.  It seems to me that any disk sub-system you might find attached to a 
P3-650 class CPU is unlikely to support 1000 operations of the form of file 
create/open/unlink per second.  So therefore if we were to have a Samba 
server process fork off a child for each file open we still probably wouldn't 
have the exec be the bottleneck for Samba performance.

Now we have to keep in mind that doing a fork/exec for every file open isn't 
the best way of doing such things.  If we create a helper process when the 
SMB authentication is performed and pass requests to it via a Unix domain 
socket then performance should be better.

What is the trend in new CPUs?  Are they getting worse or better for exec 
performance?  The only machine better than a P3-800 that I have for testing 
is a pitiful P-M.


What programs have the greatest performance requirements in terms of launching 
processes under a different context?  I suspect that a Samba server with the 
design changes we discussed could be near the top of the list, with the main 
competitor being a busy web server that's launching cgi-bin scripts.

-- 
http://www.coker.com.au/selinux/   My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/  Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/    Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/  My home page

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

RE: dynamic context transitions - a seteuid parallel

[Frank Mayer]

> The alternatives are to overprivilege the application which is not
> acceptable or to rewrite all of the applications before they can be
> used on this new platform. The latter is goal which can and should be
> achieved or time. Applications can streamlined and reorganized to fit
> into the modular framework and of cooperating applications. This is a
> considerable effort and major roadblock to utilizing SELinux and
> therefore Linux for these types of applications.

I think the case is not stated accurately.  What you want is to fundamentally
change a key property of the most important security property of type
enforcement (process type tranquility) in order to allow software the
*discretion* to turn on and off some of its privileges, arbitrarily.  I
certainly have no problem with software's ability to decide not to use its
privileges, but I an quite concerned that achieving this small victory cause
significant damage to the core mandatory security assurance.

> The other main roadblocks are already being addressed with Linux
> getting CAPP EAL3 and soon to be EAL4 certifications. Add LSPP and
> RBAC and you have Linux system suitable to address secure information
> sharing needs. 

No, privilege bracketing is not (or should not be) a concerned at EAL4 and
below.  I try my best to forget the CC :-) but I'm quite sure of this.  Maybe if
you're talking about EAL5 (the B2 like requirement), but again that's just an
evaluation strategy, not necessarily "good."  I know for a fact that the EAL4
evaluation strategy for a certain non-Unix OS never concerned itself with such
an issue.  

If the Linux guys are wrapped around privileges within a single process for an
EAL4 evaluation, seek better advice!  This is simply the wrong issue to be
focusing the evaluators on.

Frank




--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

dynamic context transitions - a seteuid parallel

[Luke Kenneth Casson Leighton]

okay, so this dynamic context transitions idea is pretty much
identical to the seteuid equivalence proposals, and doing
an equivalent of seteuid() it has been made abundantly clear
[many times], and why, that it should not be done.

... question: what it is about MLS that makes it so necessary to
implement dynamic context transitions?

what are the alternatives?

l.

p.s. not that i actually understand MLS enough to understand any answers
[yet] but i'm just encouraging people to bounce ideas.


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.