All of lore.kernel.org
 help / color / mirror / Atom feed
* RE: dynamic context transitions
@ 2004-11-03 15:36 Chad Hanson
  2004-11-03 15:46 ` Karl MacMillan
  2004-11-03 17:26 ` Luke Kenneth Casson Leighton
  0 siblings, 2 replies; 138+ messages in thread
From: Chad Hanson @ 2004-11-03 15:36 UTC (permalink / raw)
  To: Stephen Smalley, Chad Hanson
  Cc: Karl MacMillan, Frank Mayer, Darrel Goeddel, SELinux List


Stephen Smalley wrote:
> 
> >From the kernel POV, any code in the application has the potential to
> execute with the maximum set of permissions granted to any domain in the
> "domain transition group", or in reality, their union.  You may
> carefully write your application to shed and gain permissions as needed,
> but an exploit of a flaw in that application may indeed succeed in
> getting code to execute in that process with that maximum set of
> permissions.  Hence, the application still has to be "trusted" to
> exercise that maximal set of permissions, and has a corresponding
> assurance burden.  In contrast, if you decompose the application, the
> kernel can ensure that only the specific code that should execute with
> privilege does so, and the trust burden on the rest of the application
> is greatly reduced.  See the difference?
> 

I agree with this from an overall vulnerability POV. My point is that a
dynamic  non-reversible transition can increase the security of an
application by limiting it's permissions, including helpers that can be
execed. Also, even though the vulnerability threat is always the maximum set
of the current permissions, I don't agree that you necessary always want
those permissions to be active, if you have a choice IMHO. This is just a
difference of opinion between privilege bracketed code and exec level
permissions. At the end of the day, I don't see how a privilege bracket
mechanism can weaken the assurance of an application if we follow the
approach that all domains in the "domain transition group" for an
application are a subset of a high level domain which describes the maximal
set of application permissions.

-Chad

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

^ permalink raw reply	[flat|nested] 138+ messages in thread
* dynamic context transitions
@ 2005-02-15 21:34 Luke Kenneth Casson Leighton
  2005-02-15 22:21 ` Darrel Goeddel
  2005-02-16 13:05 ` Stephen Smalley
  0 siblings, 2 replies; 138+ messages in thread
From: Luke Kenneth Casson Leighton @ 2005-02-15 21:34 UTC (permalink / raw)
  To: SE-Linux

stephen,

i assume it _is_ necessary to perform dynamic auto transitions?

such that i can track to alternative contexts, yes?

e.g. i am running in sshd_privsep_t [because on a fork(),
i deliberately called setcon() to set it that way]

and i now want to be a user-related context, so i do this:

	get_default_context(pw->pw_name,NULL,&scontext)
	setcon(scontext);

and i set up a dynamic_auto_trans(sshd_privsep_t,
                                  sshd_exec_t,
				  sshd_privsep_user_t)

... hang on, that doesn't look right.  surely there should be
four arguments:

	* domain you were in before the setcon
	* domain the setcon asked to be in
	* executable_t
	* domain you want to be in afterwards

so it'd be:

	dynamic_auto_trans(sshd_privsep_t, /* where we were */
		   user_t,               /* from get_default_context() */
		  sshd_exec_t,          /* from the sshd binary */
		  sshd_privsep_user_t) /* what we _really_ want to be */


burblburbl... *gloop* drowning in not-much-understanding...

l.

-- 
--
<a href="http://lkcl.net">http://lkcl.net</a>
--

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

^ permalink raw reply	[flat|nested] 138+ messages in thread
* Re: dynamic context transitions
@ 2004-11-15  1:57 Luke Kenneth Casson Leighton
  2004-11-15 13:29 ` Stephen Smalley
  0 siblings, 1 reply; 138+ messages in thread
From: Luke Kenneth Casson Leighton @ 2004-11-15  1:57 UTC (permalink / raw)
  To: SE-Linux

i have what i believe to be an important question about how dynamic
context transitions should partition resources:

is it the case that:

- when a single process transitions (dynamically) to a new context,
  any resources it presently has opened (file handles etc.) will
  still be available and accessible in the new context.

or is it the case that:

- when a single process transitions (dynamically) to a new context,
  any resources it presently has opened (file handles etc.) will
  NOT be accessible in the new context, but that, should the process
  (dynamically) transition BACK to the new context, those resources
  become accessible again.

the former is a trivial implementation, i presume [by comparison to...]

the latter requires that every resource accessible by a process
has a context handle associated with it (eek!)

the distinction is critical because the latter is more like the exec()
model and the former is more seteuid-like.

i wouldn't want to be explaining and advocating something that was
misunderstood!

l.


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

^ permalink raw reply	[flat|nested] 138+ messages in thread
* Re: dynamic context transitions
@ 2004-11-14 20:23 Luke Kenneth Casson Leighton
  2004-11-15 13:25 ` Stephen Smalley
  0 siblings, 1 reply; 138+ messages in thread
From: Luke Kenneth Casson Leighton @ 2004-11-14 20:23 UTC (permalink / raw)
  To: SE-Linux

i hope people don't mind me pointing out what may appear to be obvious:

q: how do you stop an attacker circumventing a program with this
seteuid-like dynamic context transition capability, such that the
attacker can make the program transition anywhere anytime to an
arbitrarily chosen domain?

answer: by restricting the domains to which the transition may occur.

q: how would you do that?

answer: by providing something similar to domain_auto_trans() which is
instead adding a level of indirection.  so, instead of the newly
proposed function (let's call it selinux_change_domain) specifying the
new domain as its argument, you instead specify an intermediate handle.

so you'd have in the policy:

dynamic_handle "samba_as_root" samba_root_t
dynamic_handle "samba_as_user" samba_user_t

dynamic_auto_trans(samba_t, "samba_as_root")
dynamic_auto_trans(samba_root_t, "samba_as_user")

then, inside smbd, you call, at the appropriate point:

	selinux_change_domain("samba_as_user")

then, the job of the selinux_change_domain() function is to not only
check that you have permission to make dynamic transitions, but
also that you are in the samba_root_t domain - and to do a lookup
onto the dynamic_handle to find out what domain to transition to.


otherwise, you run the risk of a circumvented program being able to
transition to unconfined_t - or anything that they damn well choose.

i trust that this has been considered in the design of the new dynamic
transition function?

l.


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

^ permalink raw reply	[flat|nested] 138+ messages in thread
* RE: dynamic context transitions
@ 2004-11-03 18:00 Chad Hanson
  0 siblings, 0 replies; 138+ messages in thread
From: Chad Hanson @ 2004-11-03 18:00 UTC (permalink / raw)
  To: Karl MacMillan, Chad Hanson
  Cc: Stephen Smalley, Frank Mayer, Darrel Goeddel, SELinux List


Karl MacMillan wrote:
> 
> I think there are very important differences between the dynamic
> transitions and the exec model and I read part of your message above as
> arguing they are basically equivalent. Correct me if I am wrong. 

I would agree these models are not same. 

Privilege bracketing can be used for two distinct purposes. 

	The first purpose is to always run with the mininum amount of
permission to complete an operation. This model has no gain in security
assurance than program always running with all of the permissions. It can
only help audit the internal functionality of the program.
	The second purpose can permanently remove permissions from a
process. This provides a mechanism this is more strict than the previous
domain, and cannot revert back to the old domain. This is similiar to the
exec model without the environment cleansing and controlled interfaces. I
believe it could help strengthen the exec model, by disallowing usage of
helpers which are no longer needed inside an application. 

The exec model also leads itself to easier analysis as a source audit is not
needed to help determine the abilities of an application.

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

^ permalink raw reply	[flat|nested] 138+ messages in thread
* RE: dynamic context transitions
@ 2004-11-02 18:49 Chad Hanson
  2004-11-02 21:34 ` Stephen Smalley
  2004-11-02 22:06 ` Karl MacMillan
  0 siblings, 2 replies; 138+ messages in thread
From: Chad Hanson @ 2004-11-02 18:49 UTC (permalink / raw)
  To: Karl MacMillan, Stephen Smalley
  Cc: Frank Mayer, Darrel Goeddel, SELinux List, Chad Hanson


Karl MacMillan wrote: 
> I admit that I was really trying to make it clear that this isn't a
> transition mechanism, but something that would stay if introduced. Also,
> where would you put the trust boundaries if not at process boundries? Is
> it possible to truly reduce the trust between two sections of code in
> the same process image? [these are not rhetorical questions - I'm really
> asking for some clarification]

You put the trust at the process boundary. This does not preclude you from
trying increase the trust in the code. You clearly could reduce the trust
within an application. The privilege bracketing approach goes hand in hand
with secure programming techniques. An example would be that your program
needs to open the kernel memory device. If your application does this action
and has the needed information you should close the device. If you have
incorrect source and forget to close this device, there are two methods of
protection. One approach is the exec-based methodology and exec other
programs to perform additional operations, thus reducing the footprint of
the trusted code. The second approach would be using privilege bracketing to
remove the ability to handle this resource. If you permanently remove your
access to this device, even if the file descriptor is still open you will
not be able to access this information.  Both of these approaches achieve
the exact same goal, the implementations are just a bit different. 

> 
> > On the other hand, what happens if we simply
> > reject this functionality?  Will the developers of all of these "legacy"
> > applications rush to restructure their applications to better support
> > least privilege and isolation for SELinux?  Or will they just leave them
> > as they are, either not running on SELinux at all or running in a single
> > domain with the maximal set of permissions required for operation all
> > the time?  Is that truly preferable?
> > 
> 
> It is not a straightforward answer I don't think. One reason I am able
> to work on SELinux is because of the compromises made to make this a
> workable system for general purpose. My concern is that dynamic context
> transitions will give people a false sense of security. I don't think
> that it is necessarily the case that it is worse to run in a domain with
> the maximal set of permissions. 

I would disagree, running with the maximal set of permissions is exactly
what we are trying to prevent by providing fine-grained privileges.  This
shouldn't provide  a false sense of security, from a vulnerability point of
view, because the process is capable of using all current privileges and
misuse of what it can execute. The minimal use of permission can be used to
verify that the application is behaving as intended without using unneeded
permissions for an operation.

-Chad

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

^ permalink raw reply	[flat|nested] 138+ messages in thread
* RE: dynamic context transitions
@ 2004-11-02 15:25 Chad Hanson
  0 siblings, 0 replies; 138+ messages in thread
From: Chad Hanson @ 2004-11-02 15:25 UTC (permalink / raw)
  To: Frank Mayer, 'Stephen Smalley'
  Cc: 'Luke Kenneth Casson Leighton', Chad Hanson,
	Darrel Goeddel, selinux


Frank Mayer wrote:
> OK, then TE is deemed a more fundamental protection scheme, like rings,
and MLS
> a higher-level access control policy dependent upon TE's protection
features.
> I'm OK with that model, as long as we treat the TE more basic and
important than
> MLS, and not contort TE to fix MLS problems.  
> 
> I better understand the desire now, it truly isn't related to MLS, but TE
> privilege management in general.  The problem truly is the lack of an
efficient
> means to switch between domains. I would suggest our continued exploring
more
> controlled means of managing privilege (such the type hierarchy I
mentioned)
> than the ability to state arbitrary relationships (if we must go down this
> path).  Frank
> 

I don't have a problem with a hierarchy because it is similiar to defining
the dyntransition relationship. I would however want the ability to go up
and down in the hierarchy as well move laterally within the hierarchy.  I
would also like to make a sub-tree of the hieararchy be able to detach
itself and have the process bound into the sub-tree. We are using the domain
changes only for privilege management and have no reason to switch out of an
application domain hierarchy. In fact, a hierarchy mechanism is what we need
to easily implement the policy for a given application. 

-Chad


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

^ permalink raw reply	[flat|nested] 138+ messages in thread
* RE: dynamic context transitions
@ 2004-11-01 21:45 Chad Hanson
  0 siblings, 0 replies; 138+ messages in thread
From: Chad Hanson @ 2004-11-01 21:45 UTC (permalink / raw)
  To: Stephen Smalley, Chad Hanson; +Cc: Darrel Goeddel, selinux, Frank Mayer

Stephen Smalley wrote:
> > I would assume this would along the lines of the trusted 
> reader/writer
> > concept. THe app is bounded to an MLS range. Instead of a 
> process being
> > ranged and running at unclass-confidential, it is bounded 
> by confidential
> > and effectively is running at either unclassfied or 
> confidential and able to
> > transition between the two levels.
> 
> I think I would need to see your MLS implementation to fully 
> assess the
> implications, but I'm not clear as to why this requires 
> changing levels
> dynamically vs. just giving the process the capability to write down
> while remaining at a single level.  Also, I'd be a bit concerned about
> what happens while the process is running at the lower level, e.g.
> attempted access by untrusted processes running at that lower level.
> 

This all depends on how modular an application or daemon maybe. In some
cases a write down is satsifactory. At others times, when using file
polyinstantiation, it maybe simpler to change labels instead of writing
down. In a larger daemon, it maybe that you want do processing at the label
of data before upgrading/downgrading the data.  There are a number of
applications which do things in different manners depending on the
circumstance. Your example above of untrusted process at lower level trying
to access the trusted process at the same level is another strong point for
utilizing TE to help provide stronger protections for solutions than exist
today.

-Chad

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

^ permalink raw reply	[flat|nested] 138+ messages in thread
* RE: dynamic context transitions
@ 2004-11-01 21:33 Chad Hanson
  2004-11-02 13:31 ` Frank Mayer
  0 siblings, 1 reply; 138+ messages in thread
From: Chad Hanson @ 2004-11-01 21:33 UTC (permalink / raw)
  To: Frank Mayer, Chad Hanson, Darrel Goeddel, selinux
  Cc: 'Stephen Smalley'


Frank Mayer wrote:
> > The addition of a dynamic transition
> > provides an extra ability, only when necessary, to tighten the
> > security of a process.
> 
> Let me try another approach.  We're in the process of 
> designing language
> extensions that will be part of a policy management service 
> (building upon the
> binary module work that Karl should release later tonight).  
> One aspect of these
> extension will introduce a name hierarchy  for types.  
> Implicit in this
> hierarchy is the idea that a subordinate type cannot exceed the access
> privileges of any of its higher types.  For example, take 
> types 'foo' and
> 'foo.bar' ("." represents a hierarchy).  In this case, what 
> we're planning (so
> far) is that the type foo.bar can have the same or less, but 
> not more, access
> permission than the type foo in the policy.  There are many 
> reasons why such a
> semantic is useful.  
> 
> So if we had such a semantic implemented and enforced now, I 
> would feel a lot
> better if the type can only decrease down the hierarchy, and 
> never laterally or
> up the hierarchy.  Would this meet the need?  This would 
> certainly be more
> defensible in my mind [I know this is somewhat hypothetical 
> since the language
> extension does not yet exist, and will be some time in coming].
> 

This is one way a domain transitions could occur. I wouldn't want to prevent
the ability to go up the heirarchy. In this example, a privilege bracketed
program could start out in foo.unpriv transition back and forth a few times
to foo and then transition to foo.unpriv'.  foo.unpriv' is unable to
transition to foo or foo.unpriv. foo.unpriv' could transition to foo.foo'.
In a traditional privilege bracketed application you'll want to run in the
subordinate domain most of the time.

-Chad


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

^ permalink raw reply	[flat|nested] 138+ messages in thread
* RE: dynamic context transitions
@ 2004-11-01 18:28 Chad Hanson
  2004-11-01 20:47 ` Luke Kenneth Casson Leighton
  2004-11-01 20:55 ` Stephen Smalley
  0 siblings, 2 replies; 138+ messages in thread
From: Chad Hanson @ 2004-11-01 18:28 UTC (permalink / raw)
  To: Stephen Smalley, Darrel Goeddel; +Cc: selinux, Chad Hanson, Frank Mayer


> On Fri, 2004-10-29 at 15:10, Darrel Goeddel wrote:
> > A process may also
> > jump between multiple MLS labels and perform actions at each.
> <snip>
> > The chain
> > of allowable dynamic  transitions is also controlled on a 
> context-pair
> > basis.  This allows a "dynamic  transition group" to be 
> treated as an
> > equivalence class for policy analysis.
> 
> These two statements seem to be in conflict to me.  Whereas 
> you might be
> able to legitimately collapse multiple domains into a single 
> equivalence
> class for information flow analysis purposes, I don't see how this is
> legitimate for levels.  If they were separate levels in the 
> first place,
> then they should be separate equivalence classes for 
> information flow. 
> Can you clarify?

Let me try to give some background.

The ability for a process to perform actions at multiple MLS labels exists
whether dynamic transitions exist or not. Privilege bracketing does limit
the use and permits removal of the ability from the process.

MLS level transitions will need to be controlled via new permissions on the 
process class (mls_upgrade and mls_downgrade).  Similar permissions will be 
implemented for objects.  Most processes will not have the ability to alter 
their MLS level (just as most will not be able to alter their domain).  For 
processes that have the ability to alter their mls level, they will need to
be 
regarded as having access to all levels of information within the process' 
clearance.

I would assume this would along the lines of the trusted reader/writer
concept. THe app is bounded to an MLS range. Instead of a process being
ranged and running at unclass-confidential, it is bounded by confidential
and effectively is running at either unclassfied or confidential and able to
transition between the two levels.

-Chad

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

^ permalink raw reply	[flat|nested] 138+ messages in thread
* RE: dynamic context transitions
@ 2004-11-01 17:14 Chad Hanson
  2004-11-01 20:04 ` Frank Mayer
  0 siblings, 1 reply; 138+ messages in thread
From: Chad Hanson @ 2004-11-01 17:14 UTC (permalink / raw)
  To: Frank Mayer, Darrel Goeddel, selinux
  Cc: 'Stephen Smalley', Chad Hanson


I've addressed some of your concerns below.....

> -----Original Message-----
> From: Frank Mayer [mailto:mayerf@tresys.com]
> Sent: Sunday, October 31, 2004 4:48 PM
> To: 'Darrel Goeddel'; selinux@tycho.nsa.gov
> Cc: 'Stephen Smalley'; 'Chad Hanson'
> Subject: RE: dynamic context transitions
> 
> 
> [Excuse the detailed response. too many nerves were struck by 
> this proposal.]
> 
> > 	We would like to propose adding support for a trusted process to
> > alter its security context dynamically in order to support privilege
> > bracketing within an application.  We are aware that this idea has
> > been discussed in the past on the list and entirely understand the
> > concerns about non-tranquility, but we feel that this 
> feature, and its
> > implementation, have considerable merit and can be provided with
> > appropriate controls to mitigate the risks.
> 
> I fear this day would come.  I partially attribute the loss 
> of high-assurance in
> the MLS arena to loss of tranquility, and the slippery slope 
> that its loss
> starts (as greatly exploited by CMWs of the era).  On the 
> other hand Linux is a
> typical lower assurance OS so perhaps the demand for this 
> "feature" was
> inevitable.
> 

Would not running MLS and TE bring back some of the assurance that were
lost? The alternative of MLS only solutions would continue this weakness.

> >        The motivator behind this proposal is to provide a mechanism
> > for a trusted application (one written to leverage the security
> > policy) to be able to remove unnecessary privileges when they are no
> > longer needed, as well as temporarily raise the privilege level to
> > perform certain operations and then return to a less privileged
> > level.  
> 
> First a question, "leverage the security policy"; what do you 
> mean?  Second, the
> tone of the statement is that "trustedness" is a binary 
> condition.  Perhaps true
> in some MLS implementations where one has privilege to write 
> down or break
> tranquility, but not necessarily the case in type enforcement.  
> 

By "leverage the security policy", we are talking about an application that
is aware of the security policy and uses security interfaces to alter it's
state. An application doesn't have to break tranquility to perform a
privileged operation. Most MLS implmentations allow for a privilege to
override MLS policy. Also, many MLS operations require a privilege for an
operation to succeed like object upgrade or downgrade.

This issue is relevant to TE and MLS for any existing application which has
not been rewritten to a framework which execs many small executables.  A
dynamic domain transition is an implementation of privilege bracketing to
increase or decrease an application's security state.

> > By privilege level, we are referring to access to other
> > types/domains and access to security classes such as system, passwd,
> > and capability.  The former provides enhanced security for
> > applications/daemons which need access to many things to initialize,
> > but can then run with much less access to the system.  
> 
> Yes a legacy problem, so we live with it and improve over 
> time rather than
> fundamentally change to slightly improve legacy software. 
> 
> > The latter
> > method of privilege bracketing helps code audits of large
> > applications by identifying critical regions of code that require
> > more privileges to run. 
> 
> Or rather, possibly a way to achieve great sense of a false 
> assurance.  We
> evolved the so called privilege bracketing concept back in 
> the Orange Book days
> because we were stuck with legacy software, and so decided 
> that if we bracketed
> privilege, somehow the running process was of less 
> "trustedness" when the
> privilege was turned off.  I would argue the idea is not 
> necessarily valid,
> given we're talking about a single execution "domain" with 
> complete control of
> its privileges (and complete lack of control of its 
> privileges if all software
> executing within the process is not *all* entirely trusted 
> equally).  So maybe
> its better to require software engineers to be concerned 
> about all software in a
> "trusted" process, and not just that inside a privilege 
> bracket controllable by
> any software in the process.
> 

Legacy software still exists and is relevant to TE and MLS for any existing
application which has not been rewritten to a framework which execs many
small executables.  A dynamic domain transition is an implementation of
privilege bracketing to increase or decrease an application's security
state. IMHO a properly utilized privilege bracketing system can provide
strength to an application by removing future access to resources. As
software engineers, I agree we should care about all code in a trusted
process.

> > 	A goal of SELinux and trusted application programming is to
> > create smaller programs which can be secured and audited. However,
> > there are and will continue to be applications which don't fall into
> > this framework. For these applications, a privilege bracketing
> > approach provides a more granular security framework than what
> > currently exists from SELinux today at process level.
> 
> You are certainly correct about the need for legacy software. 
>  However, perhaps
> we achieve less assurance through loss of tranquility, and 
> the long term effect
> that will have (i.e., by continuing poor application security 
> engineering) than
> we would get by leaving tranquility, understanding the 
> privileges associated
> with an entire process, and working towards better 
> trustworthy applications in
> the future.  I fear the alternative you suggest is that the 
> weak (or false)
> assurance we achieve by bracketing will become the norm.
>  

The goal is always to increase the security of systems. We should try to
improve existing applications and write new applications to utilize the best
technologies that exist. We cannot, however, expect the entire realm of MLS
software to be rewritten to meet new paradigms. We can greatly increase the
security of the existing application by placing more granular controls on
operations performed by the app.

> > 	The MLS model is another reason for this functionality. We have
> > chosen to create MLS policy overrides using a new SELinux MLS
> > capability class. 
> 
> I have not thought greatly about this choice, but I wonder if 
> it was wise to
> make the MLS mechanism dependent on the capability mechanism. 
>  Orthogonal
> mechanisms would seem smarter.  
> 

The MLS Capabilities are an SELinux class and not dependent on the Linux
Capability system.

> > Trusted MLS applications may require a specific
> > capability to satisfy or "temporarily" override a policy to change
> > the MLS label of an object after it has passed "official 
> procedures".
> 
> So the use of a capability to control this privilege was a 
> design "chose";
> perhaps that's where the problem lies? 
> 

Whether it is a capability or an explicit allow rule, the ability needs to
be granted to change object MLS attributes, same as TE.

> > A process may also jump between multiple MLS labels and perform
> > actions at each. This functionality requires the need for dynamic
> > domain transitions. 
> 
> Only because someone chose to implement a BLP trusted process 
> by breaking
> tranquility rather than allowing write down (and leaving 
> object labels alone).
> In any case, no need to disturb the domain type right?
> 

There is no need to disturb the domain type for a MLS label change.

> I freely admit my ignorance of SELinux MLS implementation 
> details, can you
> further explain why TE has to be changed to support it?
> 
> >       The implementation is fairly straightforward.  You will be
> > allowed to write  to /proc/PID/attr/current.  This will require the
> > new permission of "allow XXX_t  self:process setcurrent".  A second
> > check will then be done to ensure that the  current context is
> > allowed to dynamically transition to the new context by  requiring
> > the new permission of "allow XXX_t YYY_t:process dyntransition". 
> > Role allow rules are checked in the kernel just like exec-based
> > transitions.  There are also constraints which will not allow a user
> > change or a role change.  We have also examined the the issues of
> > state inheritance and have concluded that extra checks along those
> > lines would have no real security benefit. One note on this topic is
> > that file descriptor access is re-validated on use. This 
> will prevent
> > lower privileged domains from using file descriptors, of a 
> type which
> > the more privileged domain only has access to, that may be 
> open after
> > a dynamic transition. 
> 
> Ah and here we have the beginning of the slippery slope.  
> This might be easy in
> terms of lines of code, but the conceptual complexity of what 
> you describe above
> scares me.  I still wonder why we have to change TE to 
> support a MLS convention.
> I'd much rather you did not make these mechanisms dependent 
> on each other.  
> 

If these are independent, TE would not be able to control/restrict
operations from the MLS policy. The addition of a dynamic transition
provides an extra ability, only when necessary, to tighten the security of a
process.

> >       Since the ability to perform dynamic transitions is controlled
> > by separate permission from exec-based transitions (process
> > setcurrent), policy writers have the ability to not use the new
> > feature.  The chain of allowable dynamic  transitions is also
> > controlled on a context-pair basis.  This allows a "dynamic 
> > transition group" to be treated as an equivalence class for policy
> > analysis. 
> 
> Again, I wouldn't argue (anymore) about MLS tranquility, but 
> why effect type
> tranquility?

In SELinux, the type is the basis for all non-MLS decisions. One cannot tie
abilities to specific MLS levels, so the process type is the bearer of
security rights. 

> 
> >       In closing, this feature will greatly aid the 
> adoption of Linux
> > (and SELinux of course) by current developers and users of trusted
> > operating systems because it provides them with a transition tool to
> > migrate their current generation applications which use privilege
> > bracketing.  
> 
> Hmmm, by "trusted OSs" you mean MLS right?  There are 
> certainly many "MLS
> security engineering conventions" evolved for lower assurance 
> MLS OSs over the
> years I'd rather not see adopted for the TE portion of 
> SELinux.  Let's give TE a
> chance :-)
> 

I think TE can be very beneficial to upgrade the state of existing MLS
solutions.  We just need to provide a migration path for existing
appplications and create new and better MLS applications in the future.

-Chad

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

^ permalink raw reply	[flat|nested] 138+ messages in thread
* RE: dynamic context transitions
@ 2004-11-01 14:11 Chad Hanson
  0 siblings, 0 replies; 138+ messages in thread
From: Chad Hanson @ 2004-11-01 14:11 UTC (permalink / raw)
  To: Stephen Smalley, Frank Mayer; +Cc: Darrel Goeddel, selinux, Chad Hanson


> 
> On Sun, 2004-10-31 at 17:47, Frank Mayer wrote:
> > > 	The MLS model is another reason for this functionality. We have
> > > chosen to create MLS policy overrides using a new SELinux MLS
> > > capability class. 
> > 
> > I have not thought greatly about this choice, but I wonder 
> if it was wise to
> > make the MLS mechanism dependent on the capability 
> mechanism.  Orthogonal
> > mechanisms would seem smarter.  
> 
> Point of clarification:  These MLS capabilities only exist as TE
> abstractions, not as part of the Linux capabilities logic, 
> IIUC.  Using
> TE to control MLS privileges is desirable.
> 

This is correct. We believe the the existing capabilities logic shouldn't be
extended and thus added a new TE class for MLS override logic.  These "MLS
capabilities" only affect MLS policy decisions.  In our desired
implementation, SELinux would abritrate all capability decisions and
obsolete the capability module.

> > Ah and here we have the beginning of the slippery slope.  
> This might be easy in
> > terms of lines of code, but the conceptual complexity of 
> what you describe above
> > scares me.  I still wonder why we have to change TE to 
> support a MLS convention.
> > I'd much rather you did not make these mechanisms dependent 
> on each other.  
> 
> TE was originally developed to fill in the gaps of MLS, including
> privilege management for trusted subjects.  Using TE to control MLS
> privileges is a good thing.  Whether or not privilege bracketing is a
> good thing is more open to debate, although it is clearly 
> entrenched in
> applications today, and not just MLS applications; the prior requests
> for such a feature have been to support traditional Unix applications
> that presently use seteuid/setfsuid.
> 

IMHO the combination of MLS and TE is next step in increasing the security
of solutions.  Existing MLS applications and systems have weaknesses. Using
TE to model a complex MLS scenario is not a good idea.  The combination of
the two technologies create the strongest foundation. 

-Chad

____________________________
Chad Hanson
Senior Secure Systems Engineer

Trusted Computer Solutions
121 W Goose Alley
Urbana, IL  61801

www.TrustedCS.com

V:  217.384.0028  ext.12
F:  217.384.0288

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

^ permalink raw reply	[flat|nested] 138+ messages in thread
* dynamic context transitions
@ 2004-10-29 19:10 Darrel Goeddel
  2004-10-29 21:18 ` Luke Kenneth Casson Leighton
                   ` (5 more replies)
  0 siblings, 6 replies; 138+ messages in thread
From: Darrel Goeddel @ 2004-10-29 19:10 UTC (permalink / raw)
  To: selinux@tycho.nsa.gov; +Cc: Stephen Smalley, Chad Hanson

[-- Attachment #1: Type: text/plain, Size: 4435 bytes --]

Hello all,

	We would like to propose adding support for a trusted process to
alter its security context dynamically in order to support privilege
bracketing within an application.  We are aware that this idea has been
discussed in the past on the list and entirely understand the concerns
about non-tranquility, but we feel that this feature, and its
implementation, have considerable merit and can be provided with
appropriate controls to mitigate the risks.

       The motivator behind this proposal is to provide a mechanism for a
trusted application (one written to leverage the security policy) to be
able to remove unnecessary privileges when they are no longer needed, as
well as temporarily raise the privilege level to perform certain
operations and then return to a less privileged level.  By privilege
level, we are referring to access to other types/domains and access to
security classes such as system, passwd, and capability.  The former
provides enhanced security for applications/daemons which need access to
many things to initialize, but can then run with much less access to the
system.  The latter method of privilege bracketing helps code audits of
large applications by identifying critical regions of code that require
more privileges to run.

	A goal of SELinux and trusted application programming is to
create smaller programs which can be secured and audited. However, there
are and will continue to be applications which don't fall into this
framework. For these applications, a privilege bracketing approach
provides a more granular security framework than what currently exists
from SELinux today at process level.

	The MLS model is another reason for this functionality. We have
chosen to create MLS policy overrides using a new SELinux MLS capability
class. Trusted MLS applications may require a specific capability to
satisfy or "temporarily" override a policy to change the MLS label of an
object after it has passed "official procedures". A process may also
jump between multiple MLS labels and perform actions at each. This
functionality requires the need for dynamic domain transitions.

      The implementation is fairly straightforward.  You will be allowed
to write  to /proc/PID/attr/current.  This will require the new
permission of "allow XXX_t  self:process setcurrent".  A second check
will then be done to ensure that the  current context is allowed to
dynamically transition to the new context by  requiring the new
permission of "allow XXX_t YYY_t:process dyntransition".  Role allow
rules are checked in the kernel just like exec-based transitions.  There
are also constraints which will not allow a user change or a role
change.  We have also examined the the issues of state inheritance and
have concluded that extra checks along those lines would have no real
security benefit. One note on this topic is that file descriptor access is
re-validated on use. This will prevent lower privileged domains from using
file descriptors, of a type which the more privileged domain only has
access to, that may be open after a dynamic transition.

      Since the ability to perform dynamic transitions is controlled by
separate permission from exec-based transitions (process setcurrent),
policy writers have the ability to not use the new feature.  The chain
of allowable dynamic  transitions is also controlled on a context-pair
basis.  This allows a "dynamic  transition group" to be treated as an
equivalence class for policy analysis.

      In closing, this feature will greatly aid the adoption of Linux
(and SELinux of course) by current developers and users of trusted
operating systems because it provides them with a transition tool to
migrate their current generation applications which use privilege
bracketing.  Without this migration path, applications which are
currently on trusted operating systems today, will probably never make it
to the Linux community.  This would also lead to a greater application
developer base for SELinux now, and the next generation of those
applications can then be designed to be more modular and use more
exec-based transitions.

NOTE: the patch does not include the auto-generated flask .h files.

Thanks.

-- 

Darrel Goeddel
Senior Secure Systems Engineer

Trusted Computer Solutions             E: dgoeddel@trustedcs.com
121 West Goose Alley                   V: 217.384.0028 x19
Urbana, IL  61801                      F: 217.384.0288

[-- Attachment #2: setcurrentcon.patch --]
[-- Type: text/plain, Size: 7696 bytes --]

Index: linux-2.6/security/selinux/hooks.c
===================================================================
RCS file: /cvsroot/selinux/nsa/linux-2.6/security/selinux/hooks.c,v
retrieving revision 1.21
diff -u -u -r1.21 hooks.c
--- linux-2.6/security/selinux/hooks.c	21 Oct 2004 12:59:02 -0000	1.21
+++ linux-2.6/security/selinux/hooks.c	28 Oct 2004 17:47:14 -0000
@@ -4114,10 +4114,9 @@
 	u32 sid = 0;
 	int error;
 
-	if (current != p || !strcmp(name, "current")) {
+	if (current != p) {
 		/* SELinux only allows a process to change its own
-		   security attributes, and it only allows the process
-		   current SID to change via exec. */
+		   security attributes. */
 		return -EACCES;
 	}
 
@@ -4130,6 +4129,8 @@
 		error = task_has_perm(current, p, PROCESS__SETEXEC);
 	else if (!strcmp(name, "fscreate"))
 		error = task_has_perm(current, p, PROCESS__SETFSCREATE);
+	else if (!strcmp(name, "current"))
+		error = task_has_perm(current, p, PROCESS__SETCURRENT);
 	else
 		error = -EINVAL;
 	if (error)
@@ -4154,6 +4155,18 @@
 		tsec->exec_sid = sid;
 	else if (!strcmp(name, "fscreate"))
 		tsec->create_sid = sid;
+	else if (!strcmp(name, "current")) {
+		if (sid == 0)
+			return -EINVAL;
+
+		/* Check permissions for the transition. */
+		error = avc_has_perm(tsec->sid, sid, SECCLASS_PROCESS,
+		                     PROCESS__DYNTRANSITION, NULL, NULL);
+		if (error)
+			return error;
+
+		tsec->sid = sid;
+	}
 	else
 		return -EINVAL;
 
Index: linux-2.6/security/selinux/ss/services.c
===================================================================
RCS file: /cvsroot/selinux/nsa/linux-2.6/security/selinux/ss/services.c,v
retrieving revision 1.11
diff -u -u -r1.11 services.c
--- linux-2.6/security/selinux/ss/services.c	19 Aug 2004 15:23:55 -0000	1.11
+++ linux-2.6/security/selinux/ss/services.c	28 Oct 2004 17:47:15 -0000
@@ -275,7 +275,7 @@
 	 * pair.
 	 */
 	if (tclass == SECCLASS_PROCESS &&
-	    (avd->allowed & PROCESS__TRANSITION) &&
+	    (avd->allowed & (PROCESS__TRANSITION | PROCESS__DYNTRANSITION)) &&
 	    scontext->role != tcontext->role) {
 		for (ra = policydb.role_allow; ra; ra = ra->next) {
 			if (scontext->role == ra->role &&
@@ -283,7 +283,8 @@
 				break;
 		}
 		if (!ra)
-			avd->allowed = (avd->allowed) & ~(PROCESS__TRANSITION);
+			avd->allowed = (avd->allowed) & ~(PROCESS__TRANSITION |
+			                                PROCESS__DYNTRANSITION);
 	}
 
 	return 0;
Index: selinux-usr/policy/assert.te
===================================================================
RCS file: /cvsroot/selinux/nsa/selinux-usr/policy/assert.te,v
retrieving revision 1.12
diff -u -u -r1.12 assert.te
--- selinux-usr/policy/assert.te	24 Aug 2004 19:35:23 -0000	1.12
+++ selinux-usr/policy/assert.te	28 Oct 2004 17:47:15 -0000
@@ -24,7 +24,7 @@
 # Verify that every type that can be entered by
 # a domain is also tagged as a domain.
 #
-neverallow domain ~domain:process transition;
+neverallow domain ~domain:process { transition dyntransition };
 
 #
 # Verify that only the insmod_t and kernel_t domains 
Index: selinux-usr/policy/constraints
===================================================================
RCS file: /cvsroot/selinux/nsa/selinux-usr/policy/constraints,v
retrieving revision 1.7
diff -u -u -r1.7 constraints
--- selinux-usr/policy/constraints	8 Jul 2004 13:59:01 -0000	1.7
+++ selinux-usr/policy/constraints	28 Oct 2004 17:47:15 -0000
@@ -53,6 +53,9 @@
 	 or (t1 == priv_system_role and r2 == system_r )
         );
 
+constrain process dyntransition
+	( u1 == u2 and r1 == r2);
+
 #
 # Restrict the ability to label objects with other
 # user identities to a few privileged types.
Index: selinux-usr/policy/flask/access_vectors
===================================================================
RCS file: /cvsroot/selinux/nsa/selinux-usr/policy/flask/access_vectors,v
retrieving revision 1.12
diff -u -u -r1.12 access_vectors
--- selinux-usr/policy/flask/access_vectors	9 Sep 2004 12:14:39 -0000	1.12
+++ selinux-usr/policy/flask/access_vectors	28 Oct 2004 17:47:15 -0000
@@ -240,6 +240,8 @@
 	siginh
 	setrlimit
 	rlimitinh
+	dyntransition
+	setcurrent
 }
 
 
Index: selinux-usr/policy/macros/global_macros.te
===================================================================
RCS file: /cvsroot/selinux/nsa/selinux-usr/policy/macros/global_macros.te,v
retrieving revision 1.43
diff -u -u -r1.43 global_macros.te
--- selinux-usr/policy/macros/global_macros.te	13 Oct 2004 20:14:04 -0000	1.43
+++ selinux-usr/policy/macros/global_macros.te	28 Oct 2004 17:47:15 -0000
@@ -580,9 +580,9 @@
 allow $1 domain:fifo_file rw_file_perms;
 
 # Act upon any other process.
-allow $1 domain:process ~transition;
+allow $1 domain:process ~{ transition dyntransition };
 # Transition to myself, to make get_ordered_context_list happy.
-allow $1 self:process transition;
+allow $1 self:process { transition dyntransition };
 
 # Create/access any System V IPC objects.
 allow $1 domain:{ sem msgq shm } *;
Index: selinux-usr/policy/targeted/assert.te
===================================================================
RCS file: /cvsroot/selinux/nsa/selinux-usr/policy/targeted/assert.te,v
retrieving revision 1.1
diff -u -u -r1.1 assert.te
--- selinux-usr/policy/targeted/assert.te	12 May 2004 12:56:51 -0000	1.1
+++ selinux-usr/policy/targeted/assert.te	28 Oct 2004 17:47:15 -0000
@@ -31,7 +31,7 @@
 # Verify that every type that can be entered by
 # a domain is also tagged as a domain.
 #
-neverallow domain ~domain:process transition;
+neverallow domain ~domain:process { transition dyntransition};
 
 # for gross mistakes in policy
 neverallow domain domain:dir ~r_dir_perms;
Index: selinux-usr/policy/targeted/constraints
===================================================================
RCS file: /cvsroot/selinux/nsa/selinux-usr/policy/targeted/constraints,v
retrieving revision 1.1
diff -u -u -r1.1 constraints
--- selinux-usr/policy/targeted/constraints	12 May 2004 12:56:51 -0000	1.1
+++ selinux-usr/policy/targeted/constraints	28 Oct 2004 17:47:15 -0000
@@ -39,6 +39,9 @@
 constrain process transition 
 	( r1 == r2 or t1 == privrole );
 
+constrain process dyntransition
+	( u1 == u2 and r1 == r2);
+
 #
 # Restrict the ability to label objects with other
 # user identities to a few privileged types.
Index: selinux-usr/libselinux/include/selinux/selinux.h
===================================================================
RCS file: /cvsroot/selinux/nsa/selinux-usr/libselinux/include/selinux/selinux.h,v
retrieving revision 1.20
diff -u -u -r1.20 selinux.h
--- selinux-usr/libselinux/include/selinux/selinux.h	14 Oct 2004 20:04:05 -0000	1.20
+++ selinux-usr/libselinux/include/selinux/selinux.h	28 Oct 2004 17:47:15 -0000
@@ -23,6 +23,9 @@
    Caller must free via freecon. */
 extern int getcon(security_context_t *con);
 
+/* Set current security context */
+extern int setcon(security_context_t con);
+
 /* Get context of process identified by pid, and 
    set *con to refer to it.  Caller must free via freecon. */
 extern int getpidcon(pid_t pid, security_context_t *con);
--- /dev/null	2003-09-15 08:40:47.000000000 -0500
+++ selinux-usr/libselinux/src/setcon.c	2004-10-28 10:48:14.000000000 -0500
@@ -0,0 +1,28 @@
+/*
+ * Author: Trusted Computer Solutions, Inc. <chanson@TrustedCS.com>
+ */
+
+#include <unistd.h>
+#include <fcntl.h>
+#include <string.h>
+#include <selinux/selinux.h>
+
+int setcon(security_context_t context)
+{
+	int fd;
+	ssize_t ret;
+
+	fd = open("/proc/self/attr/current", O_RDWR);
+	if (fd < 0)
+		return -1;
+	if (context) 
+		ret = write(fd, context, strlen(context)+1);
+	else
+		ret = -1; /* we can not clear this one */
+	close(fd);
+	if (ret < 0)
+		return -1;
+	else
+		return 0;
+}
+

^ permalink raw reply	[flat|nested] 138+ messages in thread
end of thread, other threads:[~2005-02-16 15:10 UTC | newest]

Thread overview: 138+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2004-11-03 15:36 dynamic context transitions Chad Hanson
2004-11-03 15:46 ` Karl MacMillan
2004-11-03 17:26 ` Luke Kenneth Casson Leighton
2004-11-04 16:50   ` Stephen Smalley
2004-11-04 17:25     ` Luke Kenneth Casson Leighton
2004-11-04 19:46     ` James Morris
2004-11-05  5:31     ` Colin Walters
2004-11-05 12:49       ` Stephen Smalley
2004-11-05 13:01         ` Frank Mayer
2004-11-05 13:13           ` Stephen Smalley
2004-11-05 15:55             ` Frank Mayer
2004-11-05 16:33               ` Luke Kenneth Casson Leighton
2004-11-05 16:41               ` Stephen Smalley
2004-11-05 17:07                 ` Frank Mayer
2004-11-05 17:48                   ` Stephen Smalley
2004-11-05 16:01         ` Colin Walters
2004-11-05 12:52       ` Frank Mayer
2004-11-05 13:11         ` Stephen Smalley
2004-11-05 15:04         ` Darrel Goeddel
2004-11-05 15:20           ` Stephen Smalley
2004-11-05 15:33             ` Karl MacMillan
2004-11-05 15:35               ` Stephen Smalley
2004-11-05 15:34             ` Darrel Goeddel
2004-11-05 16:01           ` Frank Mayer
2004-11-05 16:29           ` Luke Kenneth Casson Leighton
2004-11-05 16:44             ` Stephen Smalley
  -- strict thread matches above, loose matches on Subject: below --
2005-02-15 21:34 Luke Kenneth Casson Leighton
2005-02-15 22:21 ` Darrel Goeddel
2005-02-15 22:56   ` Luke Kenneth Casson Leighton
2005-02-16 13:05 ` Stephen Smalley
2005-02-16 14:08   ` Luke Kenneth Casson Leighton
2005-02-16 14:00     ` Stephen Smalley
2005-02-16 15:19       ` Luke Kenneth Casson Leighton
2004-11-15  1:57 Luke Kenneth Casson Leighton
2004-11-15 13:29 ` Stephen Smalley
2004-11-14 20:23 Luke Kenneth Casson Leighton
2004-11-15 13:25 ` Stephen Smalley
2004-11-15 14:34   ` Luke Kenneth Casson Leighton
2004-11-15 14:52     ` Stephen Smalley
2004-11-03 18:00 Chad Hanson
2004-11-02 18:49 Chad Hanson
2004-11-02 21:34 ` Stephen Smalley
2004-11-02 22:06 ` Karl MacMillan
2004-11-02 15:25 Chad Hanson
2004-11-01 21:45 Chad Hanson
2004-11-01 21:33 Chad Hanson
2004-11-02 13:31 ` Frank Mayer
2004-11-23  5:53   ` Russell Coker
2004-11-01 18:28 Chad Hanson
2004-11-01 20:47 ` Luke Kenneth Casson Leighton
2004-11-01 20:55 ` Stephen Smalley
2004-11-01 22:58   ` Luke Kenneth Casson Leighton
2004-11-02 13:47     ` Stephen Smalley
2004-11-02 14:06       ` Frank Mayer
2004-11-02 14:22         ` Stephen Smalley
2004-11-02 14:36           ` Frank Mayer
2004-11-03 18:47             ` Luke Kenneth Casson Leighton
2004-11-02 14:13       ` Frank Mayer
2004-11-03 15:38       ` Luke Kenneth Casson Leighton
2004-11-02 19:30     ` Valdis.Kletnieks
2004-11-03 15:55       ` Luke Kenneth Casson Leighton
2004-11-03 16:03         ` Stephen Smalley
2004-11-01 17:14 Chad Hanson
2004-11-01 20:04 ` Frank Mayer
2004-11-01 20:28   ` Stephen Smalley
2004-11-01 14:11 Chad Hanson
2004-10-29 19:10 Darrel Goeddel
2004-10-29 21:18 ` Luke Kenneth Casson Leighton
2004-10-30  9:06   ` Luke Kenneth Casson Leighton
2004-11-01 13:20     ` Stephen Smalley
2004-11-01 14:10       ` Luke Kenneth Casson Leighton
2004-11-01 16:23         ` Darrel Goeddel
2004-11-01 16:39           ` Stephen Smalley
2004-11-01 18:45           ` Luke Kenneth Casson Leighton
2004-11-01 20:10           ` James Morris
2004-11-01 20:35             ` Luke Kenneth Casson Leighton
2004-11-01 20:25               ` Stephen Smalley
2004-11-01 21:00                 ` Luke Kenneth Casson Leighton
2004-11-01 20:50                   ` Stephen Smalley
2004-11-01 22:21                     ` Luke Kenneth Casson Leighton
2004-11-08 14:42                 ` Russell Coker
     [not found]                   ` <1100395104.13794.12.camel@piglett.bartlett.house>
2004-11-14 11:15                     ` Luke Kenneth Casson Leighton
     [not found]                       ` <1100431351.13794.510.camel@piglett.bartlett.house>
     [not found]                         ` <20041114162453.GN5031@lkcl.net>
     [not found]                           ` <1100449615.30740.14.camel@localhost.localdomain>
2004-11-14 21:54                             ` Luke Kenneth Casson Leighton
     [not found]                               ` <20041201231224.GD5862@Favog.ubiqx.mn.org>
2004-12-02  1:46                                 ` Russell Coker
2004-11-08 14:39               ` Russell Coker
     [not found]               ` <20041203211212.GA5243@lkcl.net>
     [not found]                 ` <16817.7759.874421.597181@samba.org>
2004-12-04 11:39                   ` Russell Coker
2004-11-01 21:27           ` Karl MacMillan
2004-11-01 22:33             ` Luke Kenneth Casson Leighton
2004-11-02  0:25               ` Karl MacMillan
2004-11-02 13:43             ` Stephen Smalley
2004-11-02 14:16               ` Karl MacMillan
2004-11-02 14:19                 ` Stephen Smalley
2004-11-03 20:21                   ` Colin Walters
2004-11-25 19:48                 ` Russell Coker
2004-11-25 21:35                   ` Luke Kenneth Casson Leighton
2004-11-26  3:28                     ` Russell Coker
2004-11-26 19:23                       ` Valdis.Kletnieks
2004-11-26 18:58                     ` Valdis.Kletnieks
2004-11-02  2:18           ` Colin Walters
2004-11-02  9:08             ` Luke Kenneth Casson Leighton
2004-11-02 13:59             ` Stephen Smalley
2004-11-02 14:59               ` Colin Walters
2004-11-01 16:45         ` Colin Walters
2004-11-01 18:23           ` Luke Kenneth Casson Leighton
2004-10-30  2:41 ` James Morris
2004-10-31 22:47 ` Frank Mayer
2004-11-01 13:37   ` Stephen Smalley
2004-11-02  1:03     ` Karl MacMillan
2004-11-02 15:33       ` Stephen Smalley
2004-11-02 17:39         ` Karl MacMillan
2004-11-02 18:02           ` Stephen Smalley
2004-11-02 21:33             ` Karl MacMillan
2004-11-03 13:53               ` Stephen Smalley
2004-11-03 15:08                 ` Karl MacMillan
2004-11-25 20:12               ` Russell Coker
2004-11-03 17:53         ` Luke Kenneth Casson Leighton
2004-11-03 18:27         ` Luke Kenneth Casson Leighton
2004-11-01 15:51 ` Stephen Smalley
2004-11-01 16:56 ` Stephen Smalley
2004-11-01 21:44   ` Karl MacMillan
2004-11-12 18:42   ` Amy L Herzog
2004-11-15 14:07     ` Stephen Smalley
2004-11-19 13:48       ` Joshua D. Guttman
2004-11-19 14:33         ` Stephen Smalley
2004-11-19 16:29           ` Darrel Goeddel
2004-11-19 17:17             ` Stephen Smalley
2004-11-24 15:30               ` Darrel Goeddel
2004-11-24 15:31                 ` Stephen Smalley
2004-11-29 14:54                   ` Darrel Goeddel
2004-11-29 21:24                     ` Stephen Smalley
2004-11-29 23:41                       ` Darrel Goeddel
2004-11-30 12:58                         ` Stephen Smalley
2004-11-30 15:14                           ` Darrel Goeddel
2004-11-30 16:02                             ` Stephen Smalley
2004-11-30 18:27                               ` Stephen Smalley
2004-11-30 21:00                                 ` Stephen Smalley
2004-11-12 18:24 ` Stephen Smalley
2004-11-12 20:58   ` Valdis.Kletnieks

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.