From: dwalsh@redhat.com (Daniel J Walsh)
To: refpolicy@oss.tresys.com
Subject: [refpolicy] [PATCH] Implement mcsuntrustedproc.
Date: Mon, 26 Nov 2012 16:23:49 -0500 [thread overview]
Message-ID: <50B3DDE5.7090506@redhat.com> (raw)
In-Reply-To: <50B3931F.906@tresys.com>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
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.
seinfo -amcsuntrustedproc -x
mcsuntrustedproc
svirt_lxc_net_t
openshift_app_t
openshift_min_t
openshift_net_t
openshift_min_app_t
openshift_net_app_t
svirt_nokvm_t
sandbox_x_t
svirt_t
sandbox_min_t
sandbox_net_t
sandbox_web_t
openshift_t
sandbox_t
That way we don't have to deal with lots of domains that might interact with a
MCS constrained application. cupsd_t, httpd_t...
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with undefined - http://www.enigmail.net/
iEYEARECAAYFAlCz3eUACgkQrlYvE4MpobP6QwCg4cG4qIaRbtpRSfAILfeMJD/N
KyMAoOimApzFIMl970MycKusZMQCjP8r
=uhgE
-----END PGP SIGNATURE-----
next prev parent reply other threads:[~2012-11-26 21:23 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 [this message]
2012-11-27 15:12 ` Christopher J. PeBenito
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=50B3DDE5.7090506@redhat.com \
--to=dwalsh@redhat.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.