All of lore.kernel.org
 help / color / mirror / Atom feed
From: cpebenito@tresys.com (Christopher J. PeBenito)
To: refpolicy@oss.tresys.com
Subject: [refpolicy] [PATCH] Implement mcsuntrustedproc.
Date: Tue, 27 Nov 2012 10:12:35 -0500	[thread overview]
Message-ID: <50B4D863.9000705@tresys.com> (raw)
In-Reply-To: <50B3DDE5.7090506@redhat.com>

On 11/26/12 16:23, Daniel J Walsh wrote:
> On 11/26/2012 11:04 AM, Christopher J. PeBenito wrote:
>> On 11/02/12 14:46, Dominick Grift wrote:
>>>
>>> This process is not allowed to interact with subjects or operate on
>>> objects that it would otherwise be able to interact with or operate on 
>>> respectively.
>>>
>>> This is, i think, to make sure that specified processes cannot interact 
>>> with subject or operate on objects regardless of its mcs range.
>>>
>>> It is used by svirt and probably also by sandbox
>>>
>>> Signed-off-by: Dominick Grift <dominick.grift@gmail.com> diff --git
>>> a/policy/mcs b/policy/mcs index f477c7f..c366f56 100644 --- a/policy/mcs 
>>> +++ b/policy/mcs @@ -69,16 +69,32 @@ #  - /proc/pid operations are not
>>> constrained.
>>>
>>> mlsconstrain file { read ioctl lock execute execute_no_trans } -	(( h1
>>> dom h2 ) or ( t1 == mcsreadall ) or ( t2 == domain )); +	(( h1 dom h2 )
>>> or ( t1 == mcsreadall ) or +	(( t1 != mcsuntrustedproc ) and (t2 ==
>>> domain)));
>>>
>>> mlsconstrain file { write setattr append unlink link rename } -	(( h1 dom
>>> h2 ) or ( t1 == mcswriteall ) or ( t2 == domain )); +	(( h1 dom h2 ) or (
>>> t1 == mcswriteall ) or +	(( t1 != mcsuntrustedproc ) and (t2 ==
>>> domain)));
>>>
>>> mlsconstrain dir { search read ioctl lock } -	(( h1 dom h2 ) or ( t1 ==
>>> mcsreadall ) or ( t2 == domain )); +	(( h1 dom h2 ) or ( t1 == mcsreadall
>>> ) or +	(( t1 != mcsuntrustedproc ) and (t2 == domain)));
>>>
>>> mlsconstrain dir { write setattr append unlink link rename add_name
>>> remove_name } -	(( h1 dom h2 ) or ( t1 == mcswriteall ) or ( t2 == domain
>>> )); +	(( h1 dom h2 ) or ( t1 == mcswriteall ) or +	(( t1 !=
>>> mcsuntrustedproc ) and (t2 == domain))); + +mlsconstrain fifo_file { open
>>> } +	(( h1 dom h2 ) or ( t1 == mcsreadall ) or +	(( t1 != mcsuntrustedproc
>>> ) and ( t2 == domain ))); + +mlsconstrain { lnk_file chr_file blk_file
>>> sock_file } { getattr read ioctl } +	(( h1 dom h2 ) or ( t1 == mcsreadall
>>> ) or +	(( t1 != mcsuntrustedproc ) and (t2 == domain))); + +mlsconstrain
>>> { lnk_file chr_file blk_file sock_file } { write setattr } +	(( h1 dom h2
>>> ) or ( t1 == mcswriteall ) or +	(( t1 != mcsuntrustedproc ) and (t2 ==
>>> domain)));
>>>
>>> # New filesystem object labels must be dominated by the relabeling
>>> subject # clearance, also the objects are single-level. @@ -101,6 +117,12
>>> @@ mlsconstrain process { sigkill sigstop } (( h1 dom h2 ) or ( t1 ==
>>> mcskillall ));
>>>
>>> +mlsconstrain process { signal } +	(( h1 dom h2 ) or ( t1 !=
>>> mcsuntrustedproc )); + +mlsconstrain { tcp_socket udp_socket rawip_socket
>>> } node_bind +	(( h1 dom h2 ) or ( t1 != mcsuntrustedproc )); +
> 
>> This doesn't look right.  It says that only untrusted processes are
>> MCS-constrained for these permissions.
> 
> 
> Yes the idea we have moved to is to make MCS contraints opt in by the policy
> writer rather then optout.

Ok, then in that case, my preference would be to have it like ubac and have an attribute called mcsconstrained or mcs_constrained_type and the interface name changed accordingly.  Then it would be clearer that its an opt-in mechanism.

-- 
Chris PeBenito
Tresys Technology, LLC
www.tresys.com | oss.tresys.com

      reply	other threads:[~2012-11-27 15:12 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-11-02 18:46 [refpolicy] [PATCH] Implement mcsuntrustedproc Dominick Grift
2012-11-03 11:01 ` Daniel J Walsh
2012-11-26 16:04 ` Christopher J. PeBenito
2012-11-26 21:23   ` Daniel J Walsh
2012-11-27 15:12     ` Christopher J. PeBenito [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=50B4D863.9000705@tresys.com \
    --to=cpebenito@tresys.com \
    --cc=refpolicy@oss.tresys.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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.