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