Re: Runtime flexibility of SELInux

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Many Thanks,

I will look into the Secure Pipelines and policy delivery / update options.

Regards,

Tim

On 25/04/12 13:40, Stephen Smalley wrote:
On Wed, 2012-04-25 at 10:37 +0100, Tim Sheppard wrote:
The other thing I need to be able to do is constrain a process to only
permit it to change a context from c1 ->  c2 (or label1 ->  label2 in the
general case). Is this possible to manage in a policy at all and if so
is there any runtime flexibility over the rules that can be created to
allow me to specify the only legal changes are c1 ->  c2 ->  c3 ->  end for
process1-1 and c1 ->  c2 ->  c3 ->  c4->  c5 ->  end for process1-2.
Essentially, I need to be able to ensure that a process cannot change
the security labelling to bypass a stage in the chain.
That's more easily expressed via Type Enforcement (which supports
intransitive relationships) than MLS.  Type Enforcement is what is
normally used for assured pipelines.  Some people have instead modeled
assured pipelines using MLS categories by using incomparable category
sets on the input and output sides of each stage and clever
configuration, but that's more complicated and less precise in its
control of the information flow.

With regard to runtime flexibility, there isn't presently a way to
programmatically instantiate new domains and types; your application can
only use ones that are already defined in the policy.  So options might
include:
- Ship a policy module with your application that defines the maximal
set of domains/types ever required for one of these pipelines, and then
your application can just use the relevant subset for any given
instance, or

- Implement some kind of userspace daemon that runs with privilege (and
thus can load policy) and accepts requests to instantiate new pipeline
stage domains and types, generates new policy modules to define them,
and loads them (I think maybe some folks from Tresys have done this in
the past?).

Or you could always extend SELinux to directly support such
functionality, but that would be a larger project (and require a custom
kernel).



This email and any attachments to it may be confidential and are
intended solely for the use of the individual to whom it is addressed.
If you are not the intended recipient of this email, you must neither
take any action based upon its contents, nor copy or show it to anyone.
Please contact the sender if you believe you have received this email in
error. QinetiQ may monitor email traffic data and also the content of
email for the purposes of security. QinetiQ Limited (Registered in
England & Wales: Company Number: 3796233) Registered office: Cody Technology Park, Ively Road, Farnborough, Hampshire, GU14 0LX http://www.qinetiq.com.
--
selinux mailing list
selinux@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/selinux



[Index of Archives]     [Fedora Users]     [Fedora Desktop]     [Big List of Linux Books]     [Yosemite News]     [Yosemite Campsites]     [KDE Users]     [Gnome Users]

  Powered by Linux