[refpolicy] MCS Policy Constraints

[refpolicy] MCS Policy Constraints

[Douglas Brown]

Hi all,

The MCS policy has only file, database and one network-related class constraint. I'm sure this is deliberate by design, however I'd like to know if there's any impediment to adding category domain separation for all the classes in the MLS policy to the MCS policy and if I may submit a patch to do so?

Thanks for your advice.

Cheers,
Doug

[refpolicy] MCS Policy Constraints

[Sven Vermeulen]

On Apr 9, 2013 10:11 PM, "Douglas Brown" <d46.brown@student.qut.edu.au>
wrote:
>
> Hi all,
>
> The MCS policy has only file, database and one network-related class
constraint. I'm sure this is deliberate by design, however I'd like to know
if there's any impediment to adding category domain separation for all the
classes in the MLS policy to the MCS policy and if I may submit a patch to
do so?

Isn't this because categories need to be set by users and this is only
possible on the (mainly) file classes?

Wkr,
  Sven Vermeulen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://oss.tresys.com/pipermail/refpolicy/attachments/20130409/ebd4e51e/attachment.html 

[refpolicy] MCS Policy Constraints

[Douglas Brown]

On 10/04/2013, at 6:27 AM, Sven Vermeulen wrote:

On Apr 9, 2013 10:11 PM, "Douglas Brown" <d46.brown at student.qut.edu.au<mailto:d46.brown@student.qut.edu.au>> wrote:
>
> Hi all,
>
> The MCS policy has only file, database and one network-related class constraint. I'm sure this is deliberate by design, however I'd like to know if there's any impediment to adding category domain separation for all the classes in the MLS policy to the MCS policy and if I may submit a patch to do so?

Isn't this because categories need to be set by users and this is only possible on the (mainly) file classes?

I don't think so. A context, and therefore categories, can be administratively assigned to processes, ports, or any other object.

Ideally on an opt-in basis, services could be run with a limited set of categories assigned to them and using the attribute 'mcs_constrained_type', could be (h1 dom h2) restricted, as is already the case with some socket classes, introduced with Dominick's commit c2f056b2f63ce37a84ac8f468d356108b1737d97 on 2012-11-27 to 'policy/mcs':

mlsconstrain { tcp_socket udp_socket rawip_socket } node_bind
(( h1 dom h2 ) or ( t1 != mcs_constrained_type ));


Cheers,
Doug
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://oss.tresys.com/pipermail/refpolicy/attachments/20130410/b62869e3/attachment.html 

[refpolicy] MCS Policy Constraints

[Christopher J. PeBenito]

On 04/09/13 16:10, Douglas Brown wrote:
> Hi all,
> 
> The MCS policy has only file, database and one network-related class constraint. I'm sure this is deliberate by design, however I'd like to know if there's any impediment to adding category domain separation for all the classes in the MLS policy to the MCS policy and if I may submit a patch to do so?

There isn't a problem adding constraints to the other object classes.  However, the MCS policy is intended by design to be simple and only cover files and DB, so the patch would not be accepted.  If you're looking for comprehensive object class coverage with MCS, it might be sufficient to use the MLS policy but configure it with only 1 sensitivity (set MLS_SENS in build.conf).


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

[refpolicy] MCS Policy Constraints

[Daniel J Walsh]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 04/10/2013 08:48 AM, Christopher J. PeBenito wrote:
> On 04/09/13 16:10, Douglas Brown wrote:
>> Hi all,
>> 
>> The MCS policy has only file, database and one network-related class
>> constraint. I'm sure this is deliberate by design, however I'd like to
>> know if there's any impediment to adding category domain separation for
>> all the classes in the MLS policy to the MCS policy and if I may submit a
>> patch to do so?
> 
> There isn't a problem adding constraints to the other object classes.
> However, the MCS policy is intended by design to be simple and only cover
> files and DB, so the patch would not be accepted.  If you're looking for
> comprehensive object class coverage with MCS, it might be sufficient to use
> the MLS policy but configure it with only 1 sensitivity (set MLS_SENS in
> build.conf).
> 
> 
This is the mcs file we currently have in Fedora.  We have lots of other
confinement.  We are using these for constraints on things like svirt_t for
containing virtual machines, openshift_t for containing OpenShift Users (gears)
As well as controlling sandbox desktop apps(sandbox_x_t) , containers for
secure services svirt_lxc_net_t.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.13 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlFlbtsACgkQrlYvE4MpobMB4QCeM+4NPiu+yRoq4iywx0IcWuE4
wCoAmwdLDPGrj2Lt7tM0M8aQt7Ayq0vo
=bY2J
-----END PGP SIGNATURE-----
-------------- next part --------------
ifdef(`enable_mcs',`
default_range dir_file_class_set target low;

#
# Define sensitivities 
#
# MCS is single-sensitivity.

gen_sens(1)

#
# Define the categories
#
# Generate declarations

gen_cats(mcs_num_cats)

#
# Each MCS level specifies a sensitivity and zero or more categories which may
# be associated with that sensitivity.
#

gen_levels(1,mcs_num_cats)

#
# Define the MCS policy
#
# mlsconstrain class_set perm_set expression ;
#
# mlsvalidatetrans class_set expression ;
#
# expression : ( expression )
#	     | not expression
#	     | expression and expression
#	     | expression or expression
#	     | u1 op u2
#	     | r1 role_mls_op r2
#	     | t1 op t2
#	     | l1 role_mls_op l2
#	     | l1 role_mls_op h2
#	     | h1 role_mls_op l2
#	     | h1 role_mls_op h2
#	     | l1 role_mls_op h1
#	     | l2 role_mls_op h2
#	     | u1 op names
#	     | u2 op names
#	     | r1 op names
#	     | r2 op names
#	     | t1 op names
#	     | t2 op names
#	     | u3 op names (NOTE: this is only available for mlsvalidatetrans)
#	     | r3 op names (NOTE: this is only available for mlsvalidatetrans)
#	     | t3 op names (NOTE: this is only available for mlsvalidatetrans)
#
# op : == | !=
# role_mls_op : == | != | eq | dom | domby | incomp
#
# names : name | { name_list }
# name_list : name | name_list name
#

#
# MCS policy for the file classes
#
# Constrain file access so that the high range of the process dominates
# the high range of the file.  We use the high range of the process so
# that processes can always simply run at s0.
#
# Note:
#  - getattr on dirs/files is not constrained.
#  - /proc/pid operations are not constrained.

mlsconstrain file { read ioctl lock execute execute_no_trans }
	(( h1 dom h2 ) or ( t1 != mcs_constrained_type ));

mlsconstrain file { write setattr append unlink link rename }
	(( h1 dom h2 ) or ( t1 != mcs_constrained_type ));

mlsconstrain dir { search read ioctl lock }
	(( h1 dom h2 ) or ( t1 != mcs_constrained_type ));

mlsconstrain dir { write setattr append unlink link rename add_name remove_name }
	(( h1 dom h2 ) or ( t1 != mcs_constrained_type ));

mlsconstrain fifo_file { open }
	(( h1 dom h2 ) or ( t1 != mcs_constrained_type ));

mlsconstrain { lnk_file chr_file blk_file sock_file } { getattr read ioctl }
	(( h1 dom h2 ) or ( t1 != mcs_constrained_type ));

mlsconstrain { lnk_file chr_file blk_file sock_file } { write setattr }
	(( h1 dom h2 ) or ( t1 != mcs_constrained_type ));

# New filesystem object labels must be dominated by the relabeling subject
# clearance, also the objects are single-level.
mlsconstrain file { create relabelto }
	((( h1 dom h2 ) and ( l2 eq h2 )) or
	 ( t1 != mcs_constrained_type ));

# new file labels must be dominated by the relabeling subject clearance
mlsconstrain { dir file lnk_file chr_file blk_file sock_file fifo_file } { relabelfrom }
	(( h1 dom h2 ) or ( t1 != mcs_constrained_type ));

mlsconstrain { file lnk_file fifo_file } { create relabelto }
	(( l2 eq h2 )  or ( t1 != mcs_constrained_type ));

mlsconstrain { dir file lnk_file chr_file blk_file sock_file fifo_file } { create relabelto }
	(( h1 dom h2 ) or ( t1 != mcs_constrained_type ));

mlsconstrain process { transition dyntransition }
	(( h1 dom h2 ) or ( t1 != mcs_constrained_type ));

mlsconstrain process { ptrace }
	(( h1 dom h2 ) or ( t1 != mcs_constrained_type ));

mlsconstrain process { sigkill sigstop }
	(( h1 dom h2 ) or ( t1 != mcs_constrained_type ));

mlsconstrain process { signal }
	(( h1 dom h2 ) or ( t1 != mcs_constrained_type ));

mlsconstrain { tcp_socket udp_socket rawip_socket } node_bind
	(( h1 dom h2 ) or ( t1 != mcs_constrained_type ));

#
# MCS policy for SELinux-enabled databases
#

# Any database object must be dominated by the relabeling subject
# clearance, also the objects are single-level.
mlsconstrain { db_database db_schema db_table db_sequence db_view db_procedure db_language db_column db_blob } { create relabelto }
	(( h1 dom h2 ) and ( l2 eq h2 ));

mlsconstrain { db_tuple } { insert relabelto }
	(( h1 dom h2 ) and ( l2 eq h2 ));

# Access control for any database objects based on MCS rules.
mlsconstrain db_database { drop getattr setattr relabelfrom access install_module load_module get_param set_param }
	( h1 dom h2 );

mlsconstrain db_schema { drop getattr setattr relabelfrom search }
	( h1 dom h2 );

mlsconstrain db_table { drop getattr setattr relabelfrom select update insert delete lock }
	( h1 dom h2 );

mlsconstrain db_column { drop getattr setattr relabelfrom select update insert }
	( h1 dom h2 );

mlsconstrain db_tuple { relabelfrom select update delete use }
	( h1 dom h2 );

mlsconstrain db_sequence { drop getattr setattr relabelfrom get_value next_value set_value }
	( h1 dom h2 );

mlsconstrain db_view { drop getattr setattr relabelfrom expand }
	( h1 dom h2 );

mlsconstrain db_procedure { drop getattr setattr relabelfrom execute install entrypoint }
	( h1 dom h2 );

mlsconstrain db_language { drop getattr setattr relabelfrom execute }
	( h1 dom h2 );

mlsconstrain db_blob { drop getattr setattr relabelfrom read write import export }
	( h1 dom h2 );

mlsconstrain { tcp_socket udp_socket rawip_socket } node_bind
	(( h1 dom h2 ) or ( t1 != mcs_constrained_type ));

# the node recvfrom/sendto ops, the recvfrom permission is a "write" operation
# because the subject in this particular case is the remote domain which is
# writing data out the network node which is acting as the object
mlsconstrain { node } { recvfrom sendto }
	(( l1 dom l2 ) or (t1 != mcs_constrained_type));

mlsconstrain { packet peer } { recv }
	(( l1 dom l2 ) or
	 ((t1 != mcs_constrained_type) and (t2 != mcs_constrained_type)));

# the netif ingress/egress ops, the ingress permission is a "write" operation
# because the subject in this particular case is the remote domain which is
# writing data out the network interface which is acting as the object
mlsconstrain { netif } { egress ingress }
	     	(( l1 dom l2 ) or (t1 != mcs_constrained_type));

') dnl end enable_mcs