2005-06-01 15:40:37 +00:00
|
|
|
ifdef(`enable_mls',`
|
|
|
|
#
|
|
|
|
# Define sensitivities
|
|
|
|
#
|
2006-10-04 17:25:34 +00:00
|
|
|
# Domination of sensitivities is in increasin
|
|
|
|
# numerical order, with s0 being the lowest
|
2005-06-01 15:40:37 +00:00
|
|
|
|
2006-10-04 17:25:34 +00:00
|
|
|
gen_sens(mls_num_sens)
|
2005-09-12 21:40:56 +00:00
|
|
|
|
2005-06-01 15:40:37 +00:00
|
|
|
#
|
|
|
|
# Define the categories
|
|
|
|
#
|
2006-10-04 17:25:34 +00:00
|
|
|
# Generate declarations
|
2005-06-01 15:40:37 +00:00
|
|
|
|
2006-10-04 17:25:34 +00:00
|
|
|
gen_cats(mls_num_cats)
|
2005-06-01 15:40:37 +00:00
|
|
|
|
|
|
|
#
|
|
|
|
# Each MLS level specifies a sensitivity and zero or more categories which may
|
|
|
|
# be associated with that sensitivity.
|
|
|
|
#
|
2006-10-04 17:25:34 +00:00
|
|
|
# Generate levels from all sensitivities
|
|
|
|
# with all categories
|
2005-06-01 15:40:37 +00:00
|
|
|
|
2006-10-04 17:25:34 +00:00
|
|
|
gen_levels(mls_num_sens,mls_num_cats)
|
2005-06-01 15:40:37 +00:00
|
|
|
|
|
|
|
#
|
|
|
|
# Define the MLS 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 }
|
2005-09-12 21:40:56 +00:00
|
|
|
# name_list : name | name_list name
|
2005-06-01 15:40:37 +00:00
|
|
|
#
|
|
|
|
|
|
|
|
#
|
|
|
|
# MLS policy for the file classes
|
|
|
|
#
|
|
|
|
|
|
|
|
# make sure these file classes are "single level"
|
|
|
|
mlsconstrain { file lnk_file fifo_file } { create relabelto }
|
|
|
|
( l2 eq h2 );
|
|
|
|
|
2006-01-06 22:51:40 +00:00
|
|
|
# new file labels must be dominated by the relabeling subjects clearance
|
2005-06-01 15:40:37 +00:00
|
|
|
mlsconstrain { dir file lnk_file chr_file blk_file sock_file fifo_file } relabelto
|
|
|
|
( h1 dom h2 );
|
|
|
|
|
|
|
|
# the file "read" ops (note the check is dominance of the low level)
|
|
|
|
mlsconstrain { dir file lnk_file chr_file blk_file sock_file fifo_file } { read getattr execute }
|
|
|
|
(( l1 dom l2 ) or
|
|
|
|
(( t1 == mlsfilereadtoclr ) and ( h1 dom l2 )) or
|
|
|
|
( t1 == mlsfileread ) or
|
|
|
|
( t2 == mlstrustedobject ));
|
|
|
|
|
|
|
|
mlsconstrain dir search
|
|
|
|
(( l1 dom l2 ) or
|
|
|
|
(( t1 == mlsfilereadtoclr ) and ( h1 dom l2 )) or
|
|
|
|
( t1 == mlsfileread ) or
|
|
|
|
( t2 == mlstrustedobject ));
|
|
|
|
|
|
|
|
# the "single level" file "write" ops
|
2006-08-29 02:41:00 +00:00
|
|
|
mlsconstrain { file lnk_file fifo_file dir chr_file blk_file sock_file } { write create setattr relabelfrom append unlink link rename mounton }
|
2005-06-01 15:40:37 +00:00
|
|
|
(( l1 eq l2 ) or
|
|
|
|
(( t1 == mlsfilewritetoclr ) and ( h1 dom l2 ) and ( l1 domby l2 )) or
|
2006-11-01 15:42:22 +00:00
|
|
|
(( t2 == mlsfilewriteinrange ) and ( l1 dom l2 ) and ( h1 domby h2 )) or
|
2005-06-01 15:40:37 +00:00
|
|
|
( t1 == mlsfilewrite ) or
|
|
|
|
( t2 == mlstrustedobject ));
|
|
|
|
|
2007-08-24 14:14:29 +00:00
|
|
|
# Directory "write" ops
|
2005-06-01 15:40:37 +00:00
|
|
|
mlsconstrain dir { add_name remove_name reparent rmdir }
|
2007-08-24 14:14:29 +00:00
|
|
|
(( l1 eq l2 ) or
|
|
|
|
(( t1 == mlsfilewriteinrange ) and ( l1 dom l2 ) and ( l1 domby h2 )) or
|
2005-06-01 15:40:37 +00:00
|
|
|
(( t1 == mlsfilewritetoclr ) and ( h1 dom l2 ) and ( l1 domby l2 )) or
|
|
|
|
( t1 == mlsfilewrite ) or
|
|
|
|
( t2 == mlstrustedobject ));
|
|
|
|
|
|
|
|
# these access vectors have no MLS restrictions
|
|
|
|
# { dir file lnk_file chr_file blk_file sock_file fifo_file } { ioctl lock swapon quotaon }
|
|
|
|
#
|
2005-09-12 21:40:56 +00:00
|
|
|
# { file chr_file } { execute_no_trans entrypoint execmod }
|
2005-06-01 15:40:37 +00:00
|
|
|
|
|
|
|
# the file upgrade/downgrade rule
|
2005-09-12 21:40:56 +00:00
|
|
|
mlsvalidatetrans { dir file lnk_file chr_file blk_file sock_file fifo_file }
|
2005-06-01 15:40:37 +00:00
|
|
|
((( l1 eq l2 ) or
|
|
|
|
(( t3 == mlsfileupgrade ) and ( l1 domby l2 )) or
|
|
|
|
(( t3 == mlsfiledowngrade ) and ( l1 dom l2 )) or
|
|
|
|
(( t3 == mlsfiledowngrade ) and ( l1 incomp l2 ))) and
|
|
|
|
(( h1 eq h2 ) or
|
|
|
|
(( t3 == mlsfileupgrade ) and ( h1 domby h2 )) or
|
|
|
|
(( t3 == mlsfiledowngrade ) and ( h1 dom h2 )) or
|
|
|
|
(( t3 == mlsfiledowngrade ) and ( h1 incomp h2 ))));
|
|
|
|
|
|
|
|
# create can also require the upgrade/downgrade checks if the creating process
|
|
|
|
# has used setfscreate (note that both the high and low level of the object
|
|
|
|
# default to the process sensitivity level)
|
|
|
|
mlsconstrain { dir file lnk_file chr_file blk_file sock_file fifo_file } create
|
|
|
|
((( l1 eq l2 ) or
|
|
|
|
(( t1 == mlsfileupgrade ) and ( l1 domby l2 )) or
|
|
|
|
(( t1 == mlsfiledowngrade ) and ( l1 dom l2 )) or
|
|
|
|
(( t1 == mlsfiledowngrade ) and ( l1 incomp l2 ))) and
|
|
|
|
(( l1 eq h2 ) or
|
|
|
|
(( t1 == mlsfileupgrade ) and ( l1 domby h2 )) or
|
|
|
|
(( t1 == mlsfiledowngrade ) and ( l1 dom h2 )) or
|
|
|
|
(( t1 == mlsfiledowngrade ) and ( l1 incomp h2 ))));
|
|
|
|
|
|
|
|
|
2005-09-12 21:40:56 +00:00
|
|
|
|
|
|
|
|
2005-06-01 15:40:37 +00:00
|
|
|
#
|
|
|
|
# MLS policy for the filesystem class
|
|
|
|
#
|
|
|
|
|
2006-01-06 22:51:40 +00:00
|
|
|
# new filesystem labels must be dominated by the relabeling subjects clearance
|
2005-06-01 15:40:37 +00:00
|
|
|
mlsconstrain filesystem relabelto
|
|
|
|
( h1 dom h2 );
|
|
|
|
|
|
|
|
# the filesystem "read" ops (implicit single level)
|
|
|
|
mlsconstrain filesystem { getattr quotaget }
|
|
|
|
(( l1 dom l2 ) or
|
|
|
|
(( t1 == mlsfilereadtoclr ) and ( h1 dom l2 )) or
|
|
|
|
( t1 == mlsfileread ));
|
|
|
|
|
|
|
|
# all the filesystem "write" ops (implicit single level)
|
|
|
|
mlsconstrain filesystem { mount remount unmount relabelfrom quotamod }
|
|
|
|
(( l1 eq l2 ) or
|
|
|
|
(( t1 == mlsfilewritetoclr ) and ( h1 dom l2 ) and ( l1 domby l2 )) or
|
|
|
|
( t1 == mlsfilewrite ));
|
|
|
|
|
|
|
|
# these access vectors have no MLS restrictions
|
|
|
|
# filesystem { transition associate }
|
|
|
|
|
|
|
|
|
2005-09-12 21:40:56 +00:00
|
|
|
|
|
|
|
|
2005-06-01 15:40:37 +00:00
|
|
|
#
|
|
|
|
# MLS policy for the socket classes
|
|
|
|
#
|
|
|
|
|
2006-01-06 22:51:40 +00:00
|
|
|
# new socket labels must be dominated by the relabeling subjects clearance
|
2005-06-01 15:40:37 +00:00
|
|
|
mlsconstrain { socket tcp_socket udp_socket rawip_socket netlink_socket packet_socket key_socket unix_stream_socket unix_dgram_socket netlink_route_socket netlink_firewall_socket netlink_tcpdiag_socket netlink_nflog_socket netlink_xfrm_socket netlink_selinux_socket netlink_audit_socket netlink_ip6fw_socket netlink_dnrt_socket } relabelto
|
|
|
|
( h1 dom h2 );
|
|
|
|
|
2007-08-24 14:14:29 +00:00
|
|
|
# the socket "read+write" ops
|
|
|
|
# (Socket FDs are generally bidirectional, equivalent to open(..., O_RDWR),
|
|
|
|
# require equal levels for unprivileged subjects, or read *and* write overrides)
|
|
|
|
mlsconstrain { socket tcp_socket udp_socket rawip_socket netlink_socket packet_socket key_socket unix_stream_socket unix_dgram_socket netlink_route_socket netlink_firewall_socket netlink_tcpdiag_socket netlink_nflog_socket netlink_xfrm_socket netlink_selinux_socket netlink_audit_socket netlink_ip6fw_socket netlink_dnrt_socket } { accept connect }
|
|
|
|
(( l1 eq l2 ) or
|
|
|
|
(((( t1 == mlsnetreadtoclr ) and ( h1 dom l2 )) or
|
|
|
|
( t1 == mlsnetread )) and
|
|
|
|
((( t1 == mlsnetwriteranged ) and ( l1 dom l2 ) and ( l1 domby h2 )) or
|
|
|
|
(( t1 == mlsnetwritetoclr ) and ( h1 dom l2 ) and ( l1 domby l2 )) or
|
|
|
|
( t1 == mlsnetwrite ))));
|
|
|
|
|
|
|
|
|
2005-09-12 21:40:56 +00:00
|
|
|
# the socket "read" ops (note the check is dominance of the low level)
|
2006-10-17 16:58:17 +00:00
|
|
|
mlsconstrain { socket tcp_socket udp_socket rawip_socket netlink_socket packet_socket key_socket unix_stream_socket unix_dgram_socket netlink_route_socket netlink_firewall_socket netlink_tcpdiag_socket netlink_nflog_socket netlink_xfrm_socket netlink_selinux_socket netlink_audit_socket netlink_ip6fw_socket netlink_dnrt_socket } { read getattr listen accept getopt recv_msg }
|
2005-06-01 15:40:37 +00:00
|
|
|
(( l1 dom l2 ) or
|
|
|
|
(( t1 == mlsnetreadtoclr ) and ( h1 dom l2 )) or
|
|
|
|
( t1 == mlsnetread ));
|
|
|
|
|
|
|
|
mlsconstrain { netlink_route_socket netlink_firewall_socket netlink_tcpdiag_socket netlink_xfrm_socket netlink_audit_socket netlink_ip6fw_socket } nlmsg_read
|
|
|
|
(( l1 dom l2 ) or
|
|
|
|
(( t1 == mlsnetreadtoclr ) and ( h1 dom l2 )) or
|
|
|
|
( t1 == mlsnetread ));
|
|
|
|
|
|
|
|
# the socket "write" ops
|
2005-09-12 21:40:56 +00:00
|
|
|
mlsconstrain { socket tcp_socket udp_socket rawip_socket netlink_socket packet_socket key_socket unix_stream_socket unix_dgram_socket netlink_route_socket netlink_firewall_socket netlink_tcpdiag_socket netlink_nflog_socket netlink_xfrm_socket netlink_selinux_socket netlink_audit_socket netlink_ip6fw_socket netlink_dnrt_socket } { write setattr relabelfrom connect setopt shutdown }
|
2007-08-24 14:14:29 +00:00
|
|
|
(( l1 eq l2 ) or
|
|
|
|
(( t1 == mlsnetwriteranged ) and ( l1 dom l2 ) and ( l1 domby h2 )) or
|
2005-06-01 15:40:37 +00:00
|
|
|
(( t1 == mlsnetwritetoclr ) and ( h1 dom l2 ) and ( l1 domby l2 )) or
|
|
|
|
( t1 == mlsnetwrite ));
|
|
|
|
|
2007-08-24 14:14:29 +00:00
|
|
|
# used by netlabel to restrict normal domains to same level connections
|
2007-03-09 14:45:19 +00:00
|
|
|
mlsconstrain { tcp_socket udp_socket rawip_socket } recvfrom
|
2006-10-17 16:58:17 +00:00
|
|
|
(( l1 eq l2 ) or
|
|
|
|
(( t1 == mlsnetreadtoclr ) and ( h1 dom l2 )) or
|
2007-08-24 14:14:29 +00:00
|
|
|
( t1 == mlsnetread ));
|
2006-10-17 16:58:17 +00:00
|
|
|
|
2010-03-08 12:59:56 +00:00
|
|
|
# UNIX domain socket ops
|
|
|
|
mlsconstrain unix_stream_socket connectto
|
|
|
|
(( l1 eq l2 ) or
|
|
|
|
(( t1 == mlsnetwriteranged ) and ( l1 dom l2 ) and ( l1 domby h2 )) or
|
|
|
|
(( t1 == mlsnetwritetoclr ) and ( h1 dom l2 ) and ( l1 domby l2 )) or
|
2010-04-29 15:29:39 +00:00
|
|
|
( t1 == mlsnetwrite ) or
|
|
|
|
( t2 == mlstrustedobject ));
|
2010-03-08 12:59:56 +00:00
|
|
|
|
|
|
|
mlsconstrain unix_dgram_socket sendto
|
|
|
|
(( l1 eq l2 ) or
|
|
|
|
(( t1 == mlsnetwriteranged ) and ( l1 dom l2 ) and ( l1 domby h2 )) or
|
|
|
|
(( t1 == mlsnetwritetoclr ) and ( h1 dom l2 ) and ( l1 domby l2 )) or
|
2010-04-29 15:29:39 +00:00
|
|
|
( t1 == mlsnetwrite ) or
|
|
|
|
( t2 == mlstrustedobject ));
|
2010-03-08 12:59:56 +00:00
|
|
|
|
2005-06-01 15:40:37 +00:00
|
|
|
# these access vectors have no MLS restrictions
|
2005-09-12 21:40:56 +00:00
|
|
|
# { socket tcp_socket udp_socket rawip_socket netlink_socket packet_socket key_socket unix_stream_socket unix_dgram_socket netlink_route_socket netlink_firewall_socket netlink_tcpdiag_socket netlink_nflog_socket netlink_xfrm_socket netlink_selinux_socket netlink_audit_socket netlink_ip6fw_socket netlink_dnrt_socket } { ioctl create lock append bind sendto send_msg name_bind }
|
2005-06-01 15:40:37 +00:00
|
|
|
#
|
|
|
|
# { tcp_socket udp_socket rawip_socket } node_bind
|
|
|
|
#
|
2005-09-12 21:40:56 +00:00
|
|
|
# { tcp_socket unix_stream_socket } { connectto newconn acceptfrom }
|
|
|
|
#
|
2006-03-13 15:36:38 +00:00
|
|
|
# tcp_socket name_connect
|
|
|
|
#
|
2005-06-01 15:40:37 +00:00
|
|
|
# { netlink_route_socket netlink_firewall_socket netlink_tcpdiag_socket netlink_xfrm_socket netlink_audit_socket netlink_ip6fw_socket } nlmsg_write
|
|
|
|
#
|
2006-03-13 15:36:38 +00:00
|
|
|
# netlink_audit_socket { nlmsg_relay nlmsg_readpriv }
|
|
|
|
#
|
|
|
|
# netlink_kobject_uevent_socket *
|
|
|
|
#
|
2005-06-01 15:40:37 +00:00
|
|
|
|
|
|
|
|
2005-09-12 21:40:56 +00:00
|
|
|
|
|
|
|
|
2005-06-01 15:40:37 +00:00
|
|
|
#
|
|
|
|
# MLS policy for the ipc classes
|
|
|
|
#
|
|
|
|
|
|
|
|
# the ipc "read" ops (implicit single level)
|
|
|
|
mlsconstrain { ipc sem msgq shm } { getattr read unix_read }
|
|
|
|
(( l1 dom l2 ) or
|
|
|
|
(( t1 == mlsipcreadtoclr ) and ( h1 dom l2 )) or
|
|
|
|
( t1 == mlsipcread ));
|
|
|
|
|
|
|
|
mlsconstrain msg receive
|
|
|
|
(( l1 dom l2 ) or
|
|
|
|
(( t1 == mlsipcreadtoclr ) and ( h1 dom l2 )) or
|
|
|
|
( t1 == mlsipcread ));
|
|
|
|
|
|
|
|
# the ipc "write" ops (implicit single level)
|
|
|
|
mlsconstrain { ipc sem msgq shm } { create destroy setattr write unix_write }
|
|
|
|
(( l1 eq l2 ) or
|
|
|
|
(( t1 == mlsipcwritetoclr ) and ( h1 dom l2 ) and ( l1 domby l2 )) or
|
|
|
|
( t1 == mlsipcwrite ));
|
|
|
|
|
|
|
|
mlsconstrain msgq enqueue
|
|
|
|
(( l1 eq l2 ) or
|
|
|
|
(( t1 == mlsipcwritetoclr ) and ( h1 dom l2 ) and ( l1 domby l2 )) or
|
|
|
|
( t1 == mlsipcwrite ));
|
|
|
|
|
|
|
|
mlsconstrain shm lock
|
|
|
|
(( l1 eq l2 ) or
|
|
|
|
(( t1 == mlsipcwritetoclr ) and ( h1 dom l2 ) and ( l1 domby l2 )) or
|
|
|
|
( t1 == mlsipcwrite ));
|
|
|
|
|
|
|
|
mlsconstrain msg send
|
|
|
|
(( l1 eq l2 ) or
|
|
|
|
(( t1 == mlsipcwritetoclr ) and ( h1 dom l2 ) and ( l1 domby l2 )) or
|
|
|
|
( t1 == mlsipcwrite ));
|
|
|
|
|
|
|
|
# these access vectors have no MLS restrictions
|
|
|
|
# { ipc sem msgq shm } associate
|
|
|
|
|
|
|
|
|
2005-09-12 21:40:56 +00:00
|
|
|
|
|
|
|
|
2005-06-01 15:40:37 +00:00
|
|
|
#
|
|
|
|
# MLS policy for the fd class
|
|
|
|
#
|
|
|
|
|
2006-09-15 19:05:03 +00:00
|
|
|
# No sharing of open file descriptors between levels unless
|
|
|
|
# the process type is authorized to use fds created by
|
|
|
|
# other levels (mlsfduse) or the fd type is authorized to
|
|
|
|
# shared among levels (mlsfdshare).
|
|
|
|
mlsconstrain fd use (
|
|
|
|
l1 eq l2
|
|
|
|
or t1 == mlsfduse
|
|
|
|
or t2 == mlsfdshare
|
|
|
|
);
|
2005-06-01 15:40:37 +00:00
|
|
|
|
|
|
|
#
|
2005-09-12 21:40:56 +00:00
|
|
|
# MLS policy for the network object classes
|
2005-06-01 15:40:37 +00:00
|
|
|
#
|
|
|
|
|
2005-09-12 21:40:56 +00:00
|
|
|
# the netif/node "read" ops (implicit single level socket doing the read)
|
|
|
|
# (note the check is dominance of the low level)
|
|
|
|
mlsconstrain { node netif } { tcp_recv udp_recv rawip_recv }
|
|
|
|
(( l1 dom l2 ) or ( t1 == mlsnetrecvall ));
|
|
|
|
|
|
|
|
# the netif/node "write" ops (implicit single level socket doing the write)
|
|
|
|
mlsconstrain { netif node } { tcp_send udp_send rawip_send }
|
2007-08-24 14:14:29 +00:00
|
|
|
(( l1 eq l2 ) or
|
|
|
|
(( t1 == mlsnetwriteranged ) and ( l1 dom l2 ) and ( l1 domby h2 )));
|
2005-09-12 21:40:56 +00:00
|
|
|
|
2005-06-01 15:40:37 +00:00
|
|
|
# these access vectors have no MLS restrictions
|
2006-03-13 15:36:38 +00:00
|
|
|
# node enforce_dest
|
2005-09-12 21:40:56 +00:00
|
|
|
|
|
|
|
|
2005-06-01 15:40:37 +00:00
|
|
|
|
|
|
|
|
2009-03-02 15:16:49 +00:00
|
|
|
#
|
|
|
|
# MLS policy for the network ingress/egress controls
|
|
|
|
#
|
|
|
|
|
|
|
|
# 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 } { ingress }
|
|
|
|
((( l1 dom l2 ) and ( l1 domby h2 )) or
|
|
|
|
( t1 == mlsnetinbound ) or
|
|
|
|
( t1 == unlabeled_t ));
|
|
|
|
mlsconstrain { netif } { egress }
|
|
|
|
((( l1 dom l2 ) and ( l1 domby h2 )) or
|
|
|
|
( t1 == mlsnetoutbound ));
|
|
|
|
|
|
|
|
# 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 }
|
|
|
|
((( l1 dom l2 ) and ( l1 domby h2 )) or
|
|
|
|
( t1 == mlsnetinbound ) or
|
|
|
|
( t1 == unlabeled_t ));
|
|
|
|
mlsconstrain { node } { sendto }
|
|
|
|
((( l1 dom l2 ) and ( l1 domby h2 )) or
|
|
|
|
( t1 == mlsnetoutbound ));
|
|
|
|
|
|
|
|
# the forward ops, the forward_in permission is a "write" operation because the
|
|
|
|
# subject in this particular case is the remote domain which is writing data
|
|
|
|
# to the network with a secmark label, the object in this case
|
|
|
|
mlsconstrain { packet } { forward_in }
|
|
|
|
((( l1 dom l2 ) and ( l1 domby h2 )) or
|
|
|
|
( t1 == mlsnetinbound ) or
|
|
|
|
( t1 == unlabeled_t ));
|
|
|
|
mlsconstrain { packet } { forward_out }
|
|
|
|
((( l1 dom l2 ) and ( l1 domby h2 )) or
|
|
|
|
( t1 == mlsnetoutbound ) or
|
|
|
|
( t1 == unlabeled_t ));
|
|
|
|
|
|
|
|
#
|
|
|
|
# MLS policy for the secmark and peer controls
|
|
|
|
#
|
|
|
|
|
|
|
|
# the peer/packet recv op
|
|
|
|
mlsconstrain { peer packet } { recv }
|
|
|
|
(( l1 dom l2 ) or
|
|
|
|
(( t1 == mlsnetreadtoclr ) and ( h1 dom l2 )) or
|
|
|
|
( t1 == mlsnetread ));
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-06-01 15:40:37 +00:00
|
|
|
#
|
|
|
|
# MLS policy for the process class
|
|
|
|
#
|
|
|
|
|
2006-01-06 22:51:40 +00:00
|
|
|
# new process labels must be dominated by the relabeling subjects clearance
|
2005-09-12 21:40:56 +00:00
|
|
|
# and sensitivity level changes require privilege
|
|
|
|
mlsconstrain process transition
|
|
|
|
(( h1 dom h2 ) and
|
|
|
|
(( l1 eq l2 ) or ( t1 == mlsprocsetsl ) or
|
|
|
|
(( t1 == privrangetrans ) and ( t2 == mlsrangetrans ))));
|
|
|
|
mlsconstrain process dyntransition
|
2005-06-01 15:40:37 +00:00
|
|
|
(( h1 dom h2 ) and
|
|
|
|
(( l1 eq l2 ) or ( t1 == mlsprocsetsl )));
|
|
|
|
|
|
|
|
# all the process "read" ops
|
|
|
|
mlsconstrain process { getsched getsession getpgid getcap getattr ptrace share }
|
|
|
|
(( l1 dom l2 ) or
|
|
|
|
(( t1 == mlsprocreadtoclr ) and ( h1 dom l2 )) or
|
|
|
|
( t1 == mlsprocread ));
|
|
|
|
|
|
|
|
# all the process "write" ops (note the check is equality on the low level)
|
|
|
|
mlsconstrain process { sigkill sigstop signal setsched setpgid setcap setexec setfscreate setcurrent ptrace share }
|
|
|
|
(( l1 eq l2 ) or
|
|
|
|
(( t1 == mlsprocwritetoclr ) and ( h1 dom l2 ) and ( l1 domby l2 )) or
|
|
|
|
( t1 == mlsprocwrite ));
|
|
|
|
|
|
|
|
# these access vectors have no MLS restrictions
|
2006-03-13 15:36:38 +00:00
|
|
|
# process { fork sigchld signull noatsecure siginh setrlimit rlimitinh execmem execstack execheap }
|
2005-09-12 21:40:56 +00:00
|
|
|
|
|
|
|
|
2005-06-01 15:40:37 +00:00
|
|
|
|
|
|
|
|
|
|
|
#
|
|
|
|
# MLS policy for the security class
|
|
|
|
#
|
|
|
|
|
|
|
|
# these access vectors have no MLS restrictions
|
|
|
|
# security *
|
|
|
|
|
|
|
|
|
2005-09-12 21:40:56 +00:00
|
|
|
|
|
|
|
|
2005-06-01 15:40:37 +00:00
|
|
|
#
|
|
|
|
# MLS policy for the system class
|
|
|
|
#
|
|
|
|
|
|
|
|
# these access vectors have no MLS restrictions
|
|
|
|
# system *
|
|
|
|
|
|
|
|
|
2005-09-12 21:40:56 +00:00
|
|
|
|
|
|
|
|
2005-06-01 15:40:37 +00:00
|
|
|
#
|
|
|
|
# MLS policy for the capability class
|
|
|
|
#
|
|
|
|
|
|
|
|
# these access vectors have no MLS restrictions
|
|
|
|
# capability *
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-09-12 21:40:56 +00:00
|
|
|
|
2005-06-01 15:40:37 +00:00
|
|
|
#
|
|
|
|
# MLS policy for the passwd class
|
|
|
|
#
|
|
|
|
|
|
|
|
# these access vectors have no MLS restrictions
|
|
|
|
# passwd *
|
|
|
|
|
|
|
|
|
2005-09-12 21:40:56 +00:00
|
|
|
|
|
|
|
|
2005-06-01 15:40:37 +00:00
|
|
|
#
|
2008-04-01 20:23:23 +00:00
|
|
|
# MLS policy for the x_drawable class
|
2005-06-01 15:40:37 +00:00
|
|
|
#
|
|
|
|
|
2008-04-01 20:23:23 +00:00
|
|
|
# the x_drawable "read" ops (implicit single level)
|
|
|
|
mlsconstrain x_drawable { read blend getattr list_child list_property get_property receive }
|
2005-06-01 15:40:37 +00:00
|
|
|
(( l1 dom l2 ) or
|
|
|
|
(( t1 == mlsxwinreadtoclr ) and ( h1 dom l2 )) or
|
|
|
|
( t1 == mlsxwinread ));
|
|
|
|
|
2008-04-01 20:23:23 +00:00
|
|
|
# the x_drawable "write" ops (implicit single level)
|
|
|
|
mlsconstrain x_drawable { create destroy write setattr add_child remove_child send manage }
|
2005-06-01 15:40:37 +00:00
|
|
|
(( l1 eq l2 ) or
|
|
|
|
(( t1 == mlsxwinwritetoclr ) and ( h1 dom l2 ) and ( l1 domby l2 )) or
|
|
|
|
( t1 == mlsxwinwrite ));
|
|
|
|
|
2008-04-01 20:23:23 +00:00
|
|
|
# No MLS restrictions: x_drawable { show hide override }
|
2005-09-12 21:40:56 +00:00
|
|
|
|
|
|
|
|
2005-06-01 15:40:37 +00:00
|
|
|
#
|
2008-04-01 20:23:23 +00:00
|
|
|
# MLS policy for the x_gc class
|
2005-06-01 15:40:37 +00:00
|
|
|
#
|
|
|
|
|
2008-04-01 20:23:23 +00:00
|
|
|
# the x_gc "read" ops (implicit single level)
|
|
|
|
mlsconstrain x_gc { getattr use }
|
2005-06-01 15:40:37 +00:00
|
|
|
(( l1 dom l2 ) or
|
|
|
|
(( t1 == mlsxwinreadtoclr ) and ( h1 dom l2 )) or
|
|
|
|
( t1 == mlsxwinread ));
|
|
|
|
|
2008-04-01 20:23:23 +00:00
|
|
|
# the x_gc "write" ops (implicit single level)
|
|
|
|
mlsconstrain x_gc { create destroy setattr }
|
2005-06-01 15:40:37 +00:00
|
|
|
(( l1 eq l2 ) or
|
|
|
|
(( t1 == mlsxwinwritetoclr ) and ( h1 dom l2 ) and ( l1 domby l2 )) or
|
|
|
|
( t1 == mlsxwinwrite ));
|
|
|
|
|
|
|
|
|
|
|
|
#
|
2008-04-01 20:23:23 +00:00
|
|
|
# MLS policy for the x_font class
|
2005-06-01 15:40:37 +00:00
|
|
|
#
|
|
|
|
|
2008-04-01 20:23:23 +00:00
|
|
|
# the x_font "read" ops (implicit single level)
|
|
|
|
mlsconstrain x_font { use }
|
2005-06-01 15:40:37 +00:00
|
|
|
(( l1 dom l2 ) or
|
|
|
|
(( t1 == mlsxwinreadtoclr ) and ( h1 dom l2 )) or
|
|
|
|
( t1 == mlsxwinread ));
|
|
|
|
|
2008-04-01 20:23:23 +00:00
|
|
|
# the x_font "write" ops (implicit single level)
|
|
|
|
mlsconstrain x_font { create destroy add_glyph remove_glyph }
|
2005-06-01 15:40:37 +00:00
|
|
|
(( l1 eq l2 ) or
|
|
|
|
(( t1 == mlsxwinwritetoclr ) and ( h1 dom l2 ) and ( l1 domby l2 )) or
|
|
|
|
( t1 == mlsxwinwrite ));
|
|
|
|
|
|
|
|
# these access vectors have no MLS restrictions
|
|
|
|
# font use
|
|
|
|
|
|
|
|
|
|
|
|
#
|
2008-04-01 20:23:23 +00:00
|
|
|
# MLS policy for the x_colormap class
|
2005-06-01 15:40:37 +00:00
|
|
|
#
|
|
|
|
|
2008-04-01 20:23:23 +00:00
|
|
|
# the x_colormap "read" ops (implicit single level)
|
|
|
|
mlsconstrain x_colormap { read getattr use }
|
2005-06-01 15:40:37 +00:00
|
|
|
(( l1 dom l2 ) or
|
|
|
|
(( t1 == mlsxwinreadtoclr ) and ( h1 dom l2 )) or
|
2006-01-06 22:51:40 +00:00
|
|
|
( t1 == mlsxwinreadcolormap ) or
|
2005-06-01 15:40:37 +00:00
|
|
|
( t1 == mlsxwinread ));
|
|
|
|
|
2008-04-01 20:23:23 +00:00
|
|
|
# the x_colormap "write" ops (implicit single level)
|
|
|
|
mlsconstrain x_colormap { create destroy write add_color remove_color install uninstall }
|
2005-06-01 15:40:37 +00:00
|
|
|
(( l1 eq l2 ) or
|
|
|
|
(( t1 == mlsxwinwritetoclr ) and ( h1 dom l2 ) and ( l1 domby l2 )) or
|
2006-01-06 22:51:40 +00:00
|
|
|
( t1 == mlsxwinwritecolormap ) or
|
2005-06-01 15:40:37 +00:00
|
|
|
( t1 == mlsxwinwrite ));
|
|
|
|
|
|
|
|
|
|
|
|
#
|
2008-04-01 20:23:23 +00:00
|
|
|
# MLS policy for the x_property class
|
2005-06-01 15:40:37 +00:00
|
|
|
#
|
|
|
|
|
2008-04-01 20:23:23 +00:00
|
|
|
# the x_property "read" ops (implicit single level)
|
|
|
|
mlsconstrain x_property { read getattr }
|
2005-06-01 15:40:37 +00:00
|
|
|
(( l1 dom l2 ) or
|
|
|
|
(( t1 == mlsxwinreadtoclr ) and ( h1 dom l2 )) or
|
2006-01-06 22:51:40 +00:00
|
|
|
( t1 == mlsxwinreadproperty ) or
|
2005-06-01 15:40:37 +00:00
|
|
|
( t1 == mlsxwinread ));
|
|
|
|
|
2008-04-01 20:23:23 +00:00
|
|
|
# the x_property "write" ops (implicit single level)
|
|
|
|
mlsconstrain x_property { create destroy write append setattr }
|
2005-06-01 15:40:37 +00:00
|
|
|
(( l1 eq l2 ) or
|
|
|
|
(( t1 == mlsxwinwritetoclr ) and ( h1 dom l2 ) and ( l1 domby l2 )) or
|
2006-01-06 22:51:40 +00:00
|
|
|
( t1 == mlsxwinwriteproperty ) or
|
2005-06-01 15:40:37 +00:00
|
|
|
( t1 == mlsxwinwrite ));
|
|
|
|
|
2005-09-12 21:40:56 +00:00
|
|
|
|
2009-06-05 13:36:19 +00:00
|
|
|
#
|
|
|
|
# MLS policy for the x_selection class
|
|
|
|
#
|
|
|
|
|
|
|
|
# the x_selection "read" ops (implicit single level)
|
|
|
|
mlsconstrain x_selection { read getattr }
|
|
|
|
(( l1 dom l2 ) or
|
|
|
|
(( t1 == mlsxwinreadtoclr ) and ( h1 dom l2 )) or
|
|
|
|
( t1 == mlsxwinreadselection ) or
|
|
|
|
( t1 == mlsxwinread ));
|
|
|
|
|
|
|
|
# the x_selection "write" ops (implicit single level)
|
|
|
|
mlsconstrain x_selection { write setattr }
|
|
|
|
(( l1 eq l2 ) or
|
|
|
|
(( t1 == mlsxwinwritetoclr ) and ( h1 dom l2 ) and ( l1 domby l2 )) or
|
|
|
|
( t1 == mlsxwinwriteselection ) or
|
|
|
|
( t1 == mlsxwinwrite ));
|
|
|
|
|
|
|
|
|
2005-06-01 15:40:37 +00:00
|
|
|
#
|
2008-04-01 20:23:23 +00:00
|
|
|
# MLS policy for the x_cursor class
|
2005-06-01 15:40:37 +00:00
|
|
|
#
|
|
|
|
|
2008-04-01 20:23:23 +00:00
|
|
|
# the x_cursor "read" ops (implicit single level)
|
|
|
|
mlsconstrain x_cursor { read getattr use }
|
|
|
|
(( l1 dom l2 ) or
|
|
|
|
(( t1 == mlsxwinreadtoclr ) and ( h1 dom l2 )) or
|
|
|
|
( t1 == mlsxwinread ));
|
|
|
|
|
|
|
|
# the x_cursor "write" ops (implicit single level)
|
|
|
|
mlsconstrain x_cursor { create destroy write setattr }
|
2005-06-01 15:40:37 +00:00
|
|
|
(( l1 eq l2 ) or
|
|
|
|
(( t1 == mlsxwinwritetoclr ) and ( h1 dom l2 ) and ( l1 domby l2 )) or
|
|
|
|
( t1 == mlsxwinwrite ));
|
|
|
|
|
|
|
|
|
|
|
|
#
|
2008-04-01 20:23:23 +00:00
|
|
|
# MLS policy for the x_client class
|
2005-06-01 15:40:37 +00:00
|
|
|
#
|
|
|
|
|
2008-04-01 20:23:23 +00:00
|
|
|
# the x_client "read" ops (implicit single level)
|
|
|
|
mlsconstrain x_client { getattr }
|
|
|
|
(( l1 dom l2 ) or
|
|
|
|
(( t1 == mlsxwinreadtoclr ) and ( h1 dom l2 )) or
|
|
|
|
( t1 == mlsxwinread ));
|
|
|
|
|
|
|
|
# the x_client "write" ops (implicit single level)
|
|
|
|
mlsconstrain x_client { destroy setattr manage }
|
2005-06-01 15:40:37 +00:00
|
|
|
(( l1 eq l2 ) or
|
|
|
|
(( t1 == mlsxwinwritetoclr ) and ( h1 dom l2 ) and ( l1 domby l2 )) or
|
|
|
|
( t1 == mlsxwinwrite ));
|
|
|
|
|
|
|
|
|
|
|
|
#
|
2008-04-01 20:23:23 +00:00
|
|
|
# MLS policy for the x_device class
|
2005-06-01 15:40:37 +00:00
|
|
|
#
|
|
|
|
|
2008-04-01 20:23:23 +00:00
|
|
|
# the x_device "read" ops (implicit single level)
|
|
|
|
mlsconstrain x_device { getattr use read getfocus grab }
|
|
|
|
(( l1 dom l2 ) or
|
|
|
|
(( t1 == mlsxwinreadtoclr ) and ( h1 dom l2 )) or
|
|
|
|
( t1 == mlsxwinread ));
|
2005-06-01 15:40:37 +00:00
|
|
|
|
2008-04-01 20:23:23 +00:00
|
|
|
# the x_device "write" ops (implicit single level)
|
|
|
|
mlsconstrain x_device { setattr write setfocus bell force_cursor freeze manage }
|
2005-06-01 15:40:37 +00:00
|
|
|
(( l1 eq l2 ) or
|
|
|
|
(( t1 == mlsxwinwritetoclr ) and ( h1 dom l2 ) and ( l1 domby l2 )) or
|
2006-01-06 22:51:40 +00:00
|
|
|
( t1 == mlsxwinwritexinput ) or
|
2005-06-01 15:40:37 +00:00
|
|
|
( t1 == mlsxwinwrite ));
|
|
|
|
|
|
|
|
|
2008-04-01 20:23:23 +00:00
|
|
|
#
|
|
|
|
# MLS policy for the x_server class
|
|
|
|
#
|
|
|
|
|
|
|
|
# these access vectors have no MLS restrictions
|
|
|
|
# x_server *
|
2005-06-01 15:40:37 +00:00
|
|
|
|
|
|
|
|
|
|
|
#
|
2008-04-01 20:23:23 +00:00
|
|
|
# MLS policy for the x_extension class
|
2005-06-01 15:40:37 +00:00
|
|
|
#
|
|
|
|
|
2006-01-06 22:51:40 +00:00
|
|
|
# these access vectors have no MLS restrictions
|
2008-04-01 20:23:23 +00:00
|
|
|
# x_extension { query use }
|
|
|
|
|
2005-06-01 15:40:37 +00:00
|
|
|
|
2008-04-01 20:23:23 +00:00
|
|
|
#
|
|
|
|
# MLS policy for the x_resource class
|
|
|
|
#
|
|
|
|
|
|
|
|
# the x_resource "read" ops (implicit single level)
|
|
|
|
mlsconstrain x_resource { read }
|
|
|
|
(( l1 dom l2 ) or
|
|
|
|
(( t1 == mlsxwinreadtoclr ) and ( h1 dom l2 )) or
|
|
|
|
( t1 == mlsxwinread ));
|
2005-06-01 15:40:37 +00:00
|
|
|
|
2008-04-01 20:23:23 +00:00
|
|
|
# the x_resource "write" ops (implicit single level)
|
|
|
|
mlsconstrain x_resource { write }
|
|
|
|
(( l1 eq l2 ) or
|
|
|
|
(( t1 == mlsxwinwritetoclr ) and ( h1 dom l2 ) and ( l1 domby l2 )) or
|
|
|
|
( t1 == mlsxwinwritexinput ) or
|
|
|
|
( t1 == mlsxwinwrite ));
|
2005-09-12 21:40:56 +00:00
|
|
|
|
|
|
|
|
2005-06-01 15:40:37 +00:00
|
|
|
#
|
2008-04-01 20:23:23 +00:00
|
|
|
# MLS policy for the x_event class
|
2005-06-01 15:40:37 +00:00
|
|
|
#
|
|
|
|
|
2008-04-01 20:23:23 +00:00
|
|
|
# the x_event "read" ops (implicit single level)
|
|
|
|
mlsconstrain x_event { receive }
|
|
|
|
(( l1 dom l2 ) or
|
|
|
|
(( t1 == mlsxwinreadtoclr ) and ( h1 dom l2 )) or
|
|
|
|
( t1 == mlsxwinread ));
|
|
|
|
|
|
|
|
# the x_event "write" ops (implicit single level)
|
|
|
|
mlsconstrain x_event { send }
|
|
|
|
(( l1 eq l2 ) or
|
|
|
|
(( t1 == mlsxwinwritetoclr ) and ( h1 dom l2 ) and ( l1 domby l2 )) or
|
|
|
|
( t1 == mlsxwinwritexinput ) or
|
|
|
|
( t1 == mlsxwinwrite ));
|
|
|
|
|
2005-06-01 15:40:37 +00:00
|
|
|
|
2008-05-06 14:37:05 +00:00
|
|
|
#
|
|
|
|
# MLS policy for the x_application_data class
|
|
|
|
#
|
|
|
|
|
2008-09-05 14:27:01 +00:00
|
|
|
# the x_application_data "paste" ops
|
2008-05-06 14:37:05 +00:00
|
|
|
mlsconstrain x_application_data { paste }
|
2008-09-05 14:27:01 +00:00
|
|
|
( l1 domby l2 );
|
2008-05-06 14:37:05 +00:00
|
|
|
|
2008-09-05 14:27:01 +00:00
|
|
|
# the x_application_data "paste_after_confirm" ops
|
2008-05-06 14:37:05 +00:00
|
|
|
mlsconstrain x_application_data { paste_after_confirm }
|
2008-09-05 14:27:01 +00:00
|
|
|
( l1 dom l2 );
|
2008-05-06 14:37:05 +00:00
|
|
|
|
2005-06-01 15:40:37 +00:00
|
|
|
|
2005-09-12 21:40:56 +00:00
|
|
|
|
2005-06-01 15:40:37 +00:00
|
|
|
#
|
|
|
|
# MLS policy for the dbus class
|
|
|
|
#
|
|
|
|
|
2008-01-03 20:37:25 +00:00
|
|
|
mlsconstrain dbus { send_msg }
|
|
|
|
(( l1 eq l2 ) or
|
|
|
|
( t1 == mlsdbussend ) or
|
|
|
|
( t2 == mlsdbusrecv ));
|
|
|
|
|
2005-06-01 15:40:37 +00:00
|
|
|
# these access vectors have no MLS restrictions
|
2008-01-03 20:37:25 +00:00
|
|
|
# dbus { acquire_svc }
|
2005-06-01 15:40:37 +00:00
|
|
|
|
|
|
|
|
2005-09-12 21:40:56 +00:00
|
|
|
|
|
|
|
|
2005-06-01 15:40:37 +00:00
|
|
|
#
|
|
|
|
# MLS policy for the nscd class
|
|
|
|
#
|
|
|
|
|
|
|
|
# these access vectors have no MLS restrictions
|
|
|
|
# nscd { getpwd getgrp gethost getstat admin shmempwd shmemgrp shmemhost }
|
|
|
|
|
|
|
|
|
2005-09-12 21:40:56 +00:00
|
|
|
|
|
|
|
|
2005-06-01 15:40:37 +00:00
|
|
|
#
|
|
|
|
# MLS policy for the association class
|
|
|
|
#
|
|
|
|
|
2006-09-01 17:06:53 +00:00
|
|
|
mlsconstrain association { recvfrom }
|
|
|
|
((( l1 dom l2 ) and ( l1 domby h2 )) or
|
|
|
|
(( t1 == mlsnetreadtoclr ) and ( h1 dom l2 )) or
|
|
|
|
( t1 == mlsnetread ) or
|
|
|
|
( t2 == unlabeled_t ));
|
|
|
|
|
|
|
|
mlsconstrain association { sendto }
|
2007-08-24 14:14:29 +00:00
|
|
|
(( l1 eq l2 ) or
|
|
|
|
(( t1 == mlsnetwriteranged ) and ( l1 dom l2 ) and ( l1 domby h2 )) or
|
2006-09-01 17:06:53 +00:00
|
|
|
( t2 == unlabeled_t ));
|
|
|
|
|
|
|
|
mlsconstrain association { polmatch }
|
2006-11-16 13:38:14 +00:00
|
|
|
(( l1 dom l2 ) and ( h1 domby h2 ));
|
2005-06-01 15:40:37 +00:00
|
|
|
|
2006-10-20 14:44:23 +00:00
|
|
|
|
|
|
|
|
|
|
|
#
|
|
|
|
# MLS policy for the context class
|
|
|
|
#
|
|
|
|
|
|
|
|
mlsconstrain context translate
|
|
|
|
(( h1 dom h2 ) or ( t1 == mlstranslate ));
|
|
|
|
|
2006-11-14 13:38:52 +00:00
|
|
|
mlsconstrain context contains
|
2011-02-15 02:16:32 +00:00
|
|
|
(( h1 dom h2 ) and ( l1 domby l2));
|
2006-11-14 13:38:52 +00:00
|
|
|
|
2007-08-09 13:15:07 +00:00
|
|
|
#
|
|
|
|
# MLS policy for database classes
|
|
|
|
#
|
|
|
|
|
|
|
|
# make sure these database classes are "single level"
|
New database object classes
The attached patch adds a few database object classes, as follows:
* db_schema
------------
A schema object performs as a namespace in database; similar to
directories in filesystem.
It seems some of (but not all) database objects are stored within
a certain schema logically. We can qualify these objects using
schema name. For example, a table: "my_tbl" within a schema: "my_scm"
is identified by "my_scm.my_tbl". This table is completely different
from "your_scm.my_tbl" that it a table within a schema: "your_scm".
Its characteristics is similar to a directory in filesystem, so
it has similar permissions.
The 'search' controls to resolve object name within a schema.
The 'add_name' and 'remove_name' controls to add/remove an object
to/from a schema.
See also,
http://developer.postgresql.org/pgdocs/postgres/sql-createschema.html
In the past discussion, a rubix folks concerned about no object
class definition for schema and catalog which is an upper level
namespace. Since I'm not certain whether we have a disadvantage
when 'db_schema' class is applied on catalog class, I don't add
this definition yet.
Default security context of 'db_table' and 'db_procedure' classes
get being computed using type_transition with 'db_schema' class,
instead of 'db_database' class. It reflects logical hierarchy of
database object more correctly.
* db_view
----------
A view object performs as a virtual table. We can run SELECT
statement on views, although it has no physical entities.
The definition of views are expanded in run-time, so it allows
us to describe complex queries with keeping readability.
This object class uniquely provides 'expand' permission that
controls whether user can expand this view, or not.
The default security context shall be computed by type transition
rule with a schema object that owning the view.
See also,
http://developer.postgresql.org/pgdocs/postgres/sql-createview.html
* db_sequence
--------------
A sequence object is a sequential number generator.
This object class uniquely provides 'get_value', 'next_value' and
'set_value' permissions. The 'get_value' controls to reference the
sequence object. The 'next_value' controls to fetch and increment
the value of sequence object. The 'set_value' controls to set
an arbitrary value.
The default security context shall be computed by type transition
rule with a schema object that owning the sequence.
See also,
http://developer.postgresql.org/pgdocs/postgres/sql-createsequence.html
* db_language
--------------
A language object is an installed engine to execute procedures.
PostgreSQL supports to define SQL procedures using regular script
languages; such as Perl, Tcl, not only SQL or binary modules.
In addition, v9.0 or later supports DO statement. It allows us to
execute a script statement on server side without defining a SQL
procedure. It requires to control whether user can execute DO
statement on this language, or not.
This object class uniquely provides 'implement' and 'execute'
permissions. The 'implement' controls whether a procedure can
be implemented with this language, or not. So, it takes security
context of the procedure as subject. The 'execute' controls to
execute code block using DO statement.
The default security context shall be computed by type transition
rule with a database object, because it is not owned by a certain
schema.
In the default policy, we provide two types: 'sepgsql_lang_t' and
'sepgsql_safe_lang_t' that allows unpriv users to execute DO
statement. The default is 'sepgsql_leng_t'.
We assume newly installed language may be harm, so DBA has to relabel
it explicitly, if he want user defined procedures using the language.
See also,
http://developer.postgresql.org/pgdocs/postgres/sql-createlanguage.html
http://developer.postgresql.org/pgdocs/postgres/sql-do.html
P.S)
I found a bug in MCS. It didn't constraint 'relabelfrom' permission
of 'db_procedure' class. IIRC, I fixed it before, but it might be
only MLS side. Sorry.
Thanks,
--
KaiGai Kohei <kaigai@ak.jp.nec.com>
policy/flask/access_vectors | 29 ++++++++
policy/flask/security_classes | 6 ++
policy/mcs | 16 ++++-
policy/mls | 58 ++++++++++++++-
policy/modules/kernel/kernel.if | 8 ++
policy/modules/services/postgresql.if | 125 +++++++++++++++++++++++++++++++--
policy/modules/services/postgresql.te | 116 +++++++++++++++++++++++++++++-
7 files changed, 342 insertions(+), 16 deletions(-)
2010-12-10 09:49:24 +00:00
|
|
|
mlsconstrain { db_database db_schema db_table db_sequence db_view db_procedure db_language db_column db_blob } { create relabelto }
|
2007-08-09 13:15:07 +00:00
|
|
|
( l2 eq h2 );
|
|
|
|
mlsconstrain { db_tuple } { insert relabelto }
|
|
|
|
( l2 eq h2 );
|
|
|
|
|
|
|
|
# new database labels must be dominated by the relabeling subjects clearance
|
New database object classes
The attached patch adds a few database object classes, as follows:
* db_schema
------------
A schema object performs as a namespace in database; similar to
directories in filesystem.
It seems some of (but not all) database objects are stored within
a certain schema logically. We can qualify these objects using
schema name. For example, a table: "my_tbl" within a schema: "my_scm"
is identified by "my_scm.my_tbl". This table is completely different
from "your_scm.my_tbl" that it a table within a schema: "your_scm".
Its characteristics is similar to a directory in filesystem, so
it has similar permissions.
The 'search' controls to resolve object name within a schema.
The 'add_name' and 'remove_name' controls to add/remove an object
to/from a schema.
See also,
http://developer.postgresql.org/pgdocs/postgres/sql-createschema.html
In the past discussion, a rubix folks concerned about no object
class definition for schema and catalog which is an upper level
namespace. Since I'm not certain whether we have a disadvantage
when 'db_schema' class is applied on catalog class, I don't add
this definition yet.
Default security context of 'db_table' and 'db_procedure' classes
get being computed using type_transition with 'db_schema' class,
instead of 'db_database' class. It reflects logical hierarchy of
database object more correctly.
* db_view
----------
A view object performs as a virtual table. We can run SELECT
statement on views, although it has no physical entities.
The definition of views are expanded in run-time, so it allows
us to describe complex queries with keeping readability.
This object class uniquely provides 'expand' permission that
controls whether user can expand this view, or not.
The default security context shall be computed by type transition
rule with a schema object that owning the view.
See also,
http://developer.postgresql.org/pgdocs/postgres/sql-createview.html
* db_sequence
--------------
A sequence object is a sequential number generator.
This object class uniquely provides 'get_value', 'next_value' and
'set_value' permissions. The 'get_value' controls to reference the
sequence object. The 'next_value' controls to fetch and increment
the value of sequence object. The 'set_value' controls to set
an arbitrary value.
The default security context shall be computed by type transition
rule with a schema object that owning the sequence.
See also,
http://developer.postgresql.org/pgdocs/postgres/sql-createsequence.html
* db_language
--------------
A language object is an installed engine to execute procedures.
PostgreSQL supports to define SQL procedures using regular script
languages; such as Perl, Tcl, not only SQL or binary modules.
In addition, v9.0 or later supports DO statement. It allows us to
execute a script statement on server side without defining a SQL
procedure. It requires to control whether user can execute DO
statement on this language, or not.
This object class uniquely provides 'implement' and 'execute'
permissions. The 'implement' controls whether a procedure can
be implemented with this language, or not. So, it takes security
context of the procedure as subject. The 'execute' controls to
execute code block using DO statement.
The default security context shall be computed by type transition
rule with a database object, because it is not owned by a certain
schema.
In the default policy, we provide two types: 'sepgsql_lang_t' and
'sepgsql_safe_lang_t' that allows unpriv users to execute DO
statement. The default is 'sepgsql_leng_t'.
We assume newly installed language may be harm, so DBA has to relabel
it explicitly, if he want user defined procedures using the language.
See also,
http://developer.postgresql.org/pgdocs/postgres/sql-createlanguage.html
http://developer.postgresql.org/pgdocs/postgres/sql-do.html
P.S)
I found a bug in MCS. It didn't constraint 'relabelfrom' permission
of 'db_procedure' class. IIRC, I fixed it before, but it might be
only MLS side. Sorry.
Thanks,
--
KaiGai Kohei <kaigai@ak.jp.nec.com>
policy/flask/access_vectors | 29 ++++++++
policy/flask/security_classes | 6 ++
policy/mcs | 16 ++++-
policy/mls | 58 ++++++++++++++-
policy/modules/kernel/kernel.if | 8 ++
policy/modules/services/postgresql.if | 125 +++++++++++++++++++++++++++++++--
policy/modules/services/postgresql.te | 116 +++++++++++++++++++++++++++++-
7 files changed, 342 insertions(+), 16 deletions(-)
2010-12-10 09:49:24 +00:00
|
|
|
mlsconstrain { db_database db_schema db_table db_sequence db_view db_procedure db_language db_column db_tuple db_blob } { relabelto }
|
2007-08-09 13:15:07 +00:00
|
|
|
( h1 dom h2 );
|
|
|
|
|
|
|
|
# the database "read" ops (note the check is dominance of the low level)
|
|
|
|
mlsconstrain { db_database } { getattr access get_param }
|
|
|
|
(( l1 dom l2 ) or
|
|
|
|
(( t1 == mlsdbreadtoclr ) and ( h1 dom l2 )) or
|
|
|
|
( t1 == mlsdbread ) or
|
|
|
|
( t2 == mlstrustedobject ));
|
|
|
|
|
New database object classes
The attached patch adds a few database object classes, as follows:
* db_schema
------------
A schema object performs as a namespace in database; similar to
directories in filesystem.
It seems some of (but not all) database objects are stored within
a certain schema logically. We can qualify these objects using
schema name. For example, a table: "my_tbl" within a schema: "my_scm"
is identified by "my_scm.my_tbl". This table is completely different
from "your_scm.my_tbl" that it a table within a schema: "your_scm".
Its characteristics is similar to a directory in filesystem, so
it has similar permissions.
The 'search' controls to resolve object name within a schema.
The 'add_name' and 'remove_name' controls to add/remove an object
to/from a schema.
See also,
http://developer.postgresql.org/pgdocs/postgres/sql-createschema.html
In the past discussion, a rubix folks concerned about no object
class definition for schema and catalog which is an upper level
namespace. Since I'm not certain whether we have a disadvantage
when 'db_schema' class is applied on catalog class, I don't add
this definition yet.
Default security context of 'db_table' and 'db_procedure' classes
get being computed using type_transition with 'db_schema' class,
instead of 'db_database' class. It reflects logical hierarchy of
database object more correctly.
* db_view
----------
A view object performs as a virtual table. We can run SELECT
statement on views, although it has no physical entities.
The definition of views are expanded in run-time, so it allows
us to describe complex queries with keeping readability.
This object class uniquely provides 'expand' permission that
controls whether user can expand this view, or not.
The default security context shall be computed by type transition
rule with a schema object that owning the view.
See also,
http://developer.postgresql.org/pgdocs/postgres/sql-createview.html
* db_sequence
--------------
A sequence object is a sequential number generator.
This object class uniquely provides 'get_value', 'next_value' and
'set_value' permissions. The 'get_value' controls to reference the
sequence object. The 'next_value' controls to fetch and increment
the value of sequence object. The 'set_value' controls to set
an arbitrary value.
The default security context shall be computed by type transition
rule with a schema object that owning the sequence.
See also,
http://developer.postgresql.org/pgdocs/postgres/sql-createsequence.html
* db_language
--------------
A language object is an installed engine to execute procedures.
PostgreSQL supports to define SQL procedures using regular script
languages; such as Perl, Tcl, not only SQL or binary modules.
In addition, v9.0 or later supports DO statement. It allows us to
execute a script statement on server side without defining a SQL
procedure. It requires to control whether user can execute DO
statement on this language, or not.
This object class uniquely provides 'implement' and 'execute'
permissions. The 'implement' controls whether a procedure can
be implemented with this language, or not. So, it takes security
context of the procedure as subject. The 'execute' controls to
execute code block using DO statement.
The default security context shall be computed by type transition
rule with a database object, because it is not owned by a certain
schema.
In the default policy, we provide two types: 'sepgsql_lang_t' and
'sepgsql_safe_lang_t' that allows unpriv users to execute DO
statement. The default is 'sepgsql_leng_t'.
We assume newly installed language may be harm, so DBA has to relabel
it explicitly, if he want user defined procedures using the language.
See also,
http://developer.postgresql.org/pgdocs/postgres/sql-createlanguage.html
http://developer.postgresql.org/pgdocs/postgres/sql-do.html
P.S)
I found a bug in MCS. It didn't constraint 'relabelfrom' permission
of 'db_procedure' class. IIRC, I fixed it before, but it might be
only MLS side. Sorry.
Thanks,
--
KaiGai Kohei <kaigai@ak.jp.nec.com>
policy/flask/access_vectors | 29 ++++++++
policy/flask/security_classes | 6 ++
policy/mcs | 16 ++++-
policy/mls | 58 ++++++++++++++-
policy/modules/kernel/kernel.if | 8 ++
policy/modules/services/postgresql.if | 125 +++++++++++++++++++++++++++++++--
policy/modules/services/postgresql.te | 116 +++++++++++++++++++++++++++++-
7 files changed, 342 insertions(+), 16 deletions(-)
2010-12-10 09:49:24 +00:00
|
|
|
mlsconstrain { db_schema } { getattr search }
|
|
|
|
(( l1 dom l2 ) or
|
|
|
|
(( t1 == mlsdbreadtoclr ) and ( h1 dom l2 )) or
|
|
|
|
( t1 == mlsdbread ) or
|
|
|
|
( t2 == mlstrustedobject ));
|
|
|
|
|
2009-05-07 12:35:32 +00:00
|
|
|
mlsconstrain { db_table } { getattr use select lock }
|
|
|
|
(( l1 dom l2 ) or
|
|
|
|
(( t1 == mlsdbreadtoclr ) and ( h1 dom l2 )) or
|
|
|
|
( t1 == mlsdbread ) or
|
|
|
|
( t2 == mlstrustedobject ));
|
|
|
|
|
|
|
|
mlsconstrain { db_column } { getattr use select }
|
2007-08-09 13:15:07 +00:00
|
|
|
(( l1 dom l2 ) or
|
|
|
|
(( t1 == mlsdbreadtoclr ) and ( h1 dom l2 )) or
|
|
|
|
( t1 == mlsdbread ) or
|
|
|
|
( t2 == mlstrustedobject ));
|
|
|
|
|
New database object classes
The attached patch adds a few database object classes, as follows:
* db_schema
------------
A schema object performs as a namespace in database; similar to
directories in filesystem.
It seems some of (but not all) database objects are stored within
a certain schema logically. We can qualify these objects using
schema name. For example, a table: "my_tbl" within a schema: "my_scm"
is identified by "my_scm.my_tbl". This table is completely different
from "your_scm.my_tbl" that it a table within a schema: "your_scm".
Its characteristics is similar to a directory in filesystem, so
it has similar permissions.
The 'search' controls to resolve object name within a schema.
The 'add_name' and 'remove_name' controls to add/remove an object
to/from a schema.
See also,
http://developer.postgresql.org/pgdocs/postgres/sql-createschema.html
In the past discussion, a rubix folks concerned about no object
class definition for schema and catalog which is an upper level
namespace. Since I'm not certain whether we have a disadvantage
when 'db_schema' class is applied on catalog class, I don't add
this definition yet.
Default security context of 'db_table' and 'db_procedure' classes
get being computed using type_transition with 'db_schema' class,
instead of 'db_database' class. It reflects logical hierarchy of
database object more correctly.
* db_view
----------
A view object performs as a virtual table. We can run SELECT
statement on views, although it has no physical entities.
The definition of views are expanded in run-time, so it allows
us to describe complex queries with keeping readability.
This object class uniquely provides 'expand' permission that
controls whether user can expand this view, or not.
The default security context shall be computed by type transition
rule with a schema object that owning the view.
See also,
http://developer.postgresql.org/pgdocs/postgres/sql-createview.html
* db_sequence
--------------
A sequence object is a sequential number generator.
This object class uniquely provides 'get_value', 'next_value' and
'set_value' permissions. The 'get_value' controls to reference the
sequence object. The 'next_value' controls to fetch and increment
the value of sequence object. The 'set_value' controls to set
an arbitrary value.
The default security context shall be computed by type transition
rule with a schema object that owning the sequence.
See also,
http://developer.postgresql.org/pgdocs/postgres/sql-createsequence.html
* db_language
--------------
A language object is an installed engine to execute procedures.
PostgreSQL supports to define SQL procedures using regular script
languages; such as Perl, Tcl, not only SQL or binary modules.
In addition, v9.0 or later supports DO statement. It allows us to
execute a script statement on server side without defining a SQL
procedure. It requires to control whether user can execute DO
statement on this language, or not.
This object class uniquely provides 'implement' and 'execute'
permissions. The 'implement' controls whether a procedure can
be implemented with this language, or not. So, it takes security
context of the procedure as subject. The 'execute' controls to
execute code block using DO statement.
The default security context shall be computed by type transition
rule with a database object, because it is not owned by a certain
schema.
In the default policy, we provide two types: 'sepgsql_lang_t' and
'sepgsql_safe_lang_t' that allows unpriv users to execute DO
statement. The default is 'sepgsql_leng_t'.
We assume newly installed language may be harm, so DBA has to relabel
it explicitly, if he want user defined procedures using the language.
See also,
http://developer.postgresql.org/pgdocs/postgres/sql-createlanguage.html
http://developer.postgresql.org/pgdocs/postgres/sql-do.html
P.S)
I found a bug in MCS. It didn't constraint 'relabelfrom' permission
of 'db_procedure' class. IIRC, I fixed it before, but it might be
only MLS side. Sorry.
Thanks,
--
KaiGai Kohei <kaigai@ak.jp.nec.com>
policy/flask/access_vectors | 29 ++++++++
policy/flask/security_classes | 6 ++
policy/mcs | 16 ++++-
policy/mls | 58 ++++++++++++++-
policy/modules/kernel/kernel.if | 8 ++
policy/modules/services/postgresql.if | 125 +++++++++++++++++++++++++++++++--
policy/modules/services/postgresql.te | 116 +++++++++++++++++++++++++++++-
7 files changed, 342 insertions(+), 16 deletions(-)
2010-12-10 09:49:24 +00:00
|
|
|
mlsconstrain { db_sequence } { getattr get_value next_value }
|
|
|
|
(( l1 dom l2 ) or
|
|
|
|
(( t1 == mlsdbreadtoclr ) and ( h1 dom l2 )) or
|
|
|
|
( t1 == mlsdbread ) or
|
|
|
|
( t2 == mlstrustedobject ));
|
|
|
|
|
|
|
|
mlsconstrain { db_view } { getattr expand }
|
|
|
|
(( l1 dom l2 ) or
|
|
|
|
(( t1 == mlsdbreadtoclr ) and ( h1 dom l2 )) or
|
|
|
|
( t1 == mlsdbread ) or
|
|
|
|
( t2 == mlstrustedobject ));
|
|
|
|
|
2009-01-23 19:49:36 +00:00
|
|
|
mlsconstrain { db_procedure } { getattr execute install }
|
2007-08-09 13:15:07 +00:00
|
|
|
(( l1 dom l2 ) or
|
|
|
|
(( t1 == mlsdbreadtoclr ) and ( h1 dom l2 )) or
|
|
|
|
( t1 == mlsdbread ) or
|
|
|
|
( t2 == mlstrustedobject ));
|
|
|
|
|
New database object classes
The attached patch adds a few database object classes, as follows:
* db_schema
------------
A schema object performs as a namespace in database; similar to
directories in filesystem.
It seems some of (but not all) database objects are stored within
a certain schema logically. We can qualify these objects using
schema name. For example, a table: "my_tbl" within a schema: "my_scm"
is identified by "my_scm.my_tbl". This table is completely different
from "your_scm.my_tbl" that it a table within a schema: "your_scm".
Its characteristics is similar to a directory in filesystem, so
it has similar permissions.
The 'search' controls to resolve object name within a schema.
The 'add_name' and 'remove_name' controls to add/remove an object
to/from a schema.
See also,
http://developer.postgresql.org/pgdocs/postgres/sql-createschema.html
In the past discussion, a rubix folks concerned about no object
class definition for schema and catalog which is an upper level
namespace. Since I'm not certain whether we have a disadvantage
when 'db_schema' class is applied on catalog class, I don't add
this definition yet.
Default security context of 'db_table' and 'db_procedure' classes
get being computed using type_transition with 'db_schema' class,
instead of 'db_database' class. It reflects logical hierarchy of
database object more correctly.
* db_view
----------
A view object performs as a virtual table. We can run SELECT
statement on views, although it has no physical entities.
The definition of views are expanded in run-time, so it allows
us to describe complex queries with keeping readability.
This object class uniquely provides 'expand' permission that
controls whether user can expand this view, or not.
The default security context shall be computed by type transition
rule with a schema object that owning the view.
See also,
http://developer.postgresql.org/pgdocs/postgres/sql-createview.html
* db_sequence
--------------
A sequence object is a sequential number generator.
This object class uniquely provides 'get_value', 'next_value' and
'set_value' permissions. The 'get_value' controls to reference the
sequence object. The 'next_value' controls to fetch and increment
the value of sequence object. The 'set_value' controls to set
an arbitrary value.
The default security context shall be computed by type transition
rule with a schema object that owning the sequence.
See also,
http://developer.postgresql.org/pgdocs/postgres/sql-createsequence.html
* db_language
--------------
A language object is an installed engine to execute procedures.
PostgreSQL supports to define SQL procedures using regular script
languages; such as Perl, Tcl, not only SQL or binary modules.
In addition, v9.0 or later supports DO statement. It allows us to
execute a script statement on server side without defining a SQL
procedure. It requires to control whether user can execute DO
statement on this language, or not.
This object class uniquely provides 'implement' and 'execute'
permissions. The 'implement' controls whether a procedure can
be implemented with this language, or not. So, it takes security
context of the procedure as subject. The 'execute' controls to
execute code block using DO statement.
The default security context shall be computed by type transition
rule with a database object, because it is not owned by a certain
schema.
In the default policy, we provide two types: 'sepgsql_lang_t' and
'sepgsql_safe_lang_t' that allows unpriv users to execute DO
statement. The default is 'sepgsql_leng_t'.
We assume newly installed language may be harm, so DBA has to relabel
it explicitly, if he want user defined procedures using the language.
See also,
http://developer.postgresql.org/pgdocs/postgres/sql-createlanguage.html
http://developer.postgresql.org/pgdocs/postgres/sql-do.html
P.S)
I found a bug in MCS. It didn't constraint 'relabelfrom' permission
of 'db_procedure' class. IIRC, I fixed it before, but it might be
only MLS side. Sorry.
Thanks,
--
KaiGai Kohei <kaigai@ak.jp.nec.com>
policy/flask/access_vectors | 29 ++++++++
policy/flask/security_classes | 6 ++
policy/mcs | 16 ++++-
policy/mls | 58 ++++++++++++++-
policy/modules/kernel/kernel.if | 8 ++
policy/modules/services/postgresql.if | 125 +++++++++++++++++++++++++++++++--
policy/modules/services/postgresql.te | 116 +++++++++++++++++++++++++++++-
7 files changed, 342 insertions(+), 16 deletions(-)
2010-12-10 09:49:24 +00:00
|
|
|
mlsconstrain { db_language } { getattr execute }
|
|
|
|
(( l1 dom l2 ) or
|
|
|
|
(( t1 == mlsdbreadtoclr ) and ( h1 dom l2 )) or
|
|
|
|
( t1 == mlsdbread ) or
|
|
|
|
( t2 == mlstrustedobject ));
|
|
|
|
|
2009-05-07 12:35:32 +00:00
|
|
|
mlsconstrain { db_blob } { getattr read export }
|
2007-08-09 13:15:07 +00:00
|
|
|
(( l1 dom l2 ) or
|
|
|
|
(( t1 == mlsdbreadtoclr ) and ( h1 dom l2 )) or
|
|
|
|
( t1 == mlsdbread ) or
|
|
|
|
( t2 == mlstrustedobject ));
|
|
|
|
|
|
|
|
mlsconstrain { db_tuple } { use select }
|
|
|
|
(( l1 dom l2 ) or
|
|
|
|
(( t1 == mlsdbreadtoclr ) and ( h1 dom l2 )) or
|
|
|
|
( t1 == mlsdbread ) or
|
|
|
|
( t2 == mlstrustedobject ));
|
|
|
|
|
|
|
|
# the "single level" file "write" ops
|
|
|
|
mlsconstrain { db_database } { create drop setattr relabelfrom install_module load_module set_param }
|
|
|
|
(( l1 eq l2 ) or
|
|
|
|
(( t1 == mlsdbwritetoclr ) and ( h1 dom l2 ) and ( l1 domby l2 )) or
|
|
|
|
(( t2 == mlsdbwriteinrange ) and ( l1 dom l2 ) and ( h1 domby h2 )) or
|
|
|
|
( t1 == mlsdbwrite ) or
|
|
|
|
( t2 == mlstrustedobject ));
|
|
|
|
|
New database object classes
The attached patch adds a few database object classes, as follows:
* db_schema
------------
A schema object performs as a namespace in database; similar to
directories in filesystem.
It seems some of (but not all) database objects are stored within
a certain schema logically. We can qualify these objects using
schema name. For example, a table: "my_tbl" within a schema: "my_scm"
is identified by "my_scm.my_tbl". This table is completely different
from "your_scm.my_tbl" that it a table within a schema: "your_scm".
Its characteristics is similar to a directory in filesystem, so
it has similar permissions.
The 'search' controls to resolve object name within a schema.
The 'add_name' and 'remove_name' controls to add/remove an object
to/from a schema.
See also,
http://developer.postgresql.org/pgdocs/postgres/sql-createschema.html
In the past discussion, a rubix folks concerned about no object
class definition for schema and catalog which is an upper level
namespace. Since I'm not certain whether we have a disadvantage
when 'db_schema' class is applied on catalog class, I don't add
this definition yet.
Default security context of 'db_table' and 'db_procedure' classes
get being computed using type_transition with 'db_schema' class,
instead of 'db_database' class. It reflects logical hierarchy of
database object more correctly.
* db_view
----------
A view object performs as a virtual table. We can run SELECT
statement on views, although it has no physical entities.
The definition of views are expanded in run-time, so it allows
us to describe complex queries with keeping readability.
This object class uniquely provides 'expand' permission that
controls whether user can expand this view, or not.
The default security context shall be computed by type transition
rule with a schema object that owning the view.
See also,
http://developer.postgresql.org/pgdocs/postgres/sql-createview.html
* db_sequence
--------------
A sequence object is a sequential number generator.
This object class uniquely provides 'get_value', 'next_value' and
'set_value' permissions. The 'get_value' controls to reference the
sequence object. The 'next_value' controls to fetch and increment
the value of sequence object. The 'set_value' controls to set
an arbitrary value.
The default security context shall be computed by type transition
rule with a schema object that owning the sequence.
See also,
http://developer.postgresql.org/pgdocs/postgres/sql-createsequence.html
* db_language
--------------
A language object is an installed engine to execute procedures.
PostgreSQL supports to define SQL procedures using regular script
languages; such as Perl, Tcl, not only SQL or binary modules.
In addition, v9.0 or later supports DO statement. It allows us to
execute a script statement on server side without defining a SQL
procedure. It requires to control whether user can execute DO
statement on this language, or not.
This object class uniquely provides 'implement' and 'execute'
permissions. The 'implement' controls whether a procedure can
be implemented with this language, or not. So, it takes security
context of the procedure as subject. The 'execute' controls to
execute code block using DO statement.
The default security context shall be computed by type transition
rule with a database object, because it is not owned by a certain
schema.
In the default policy, we provide two types: 'sepgsql_lang_t' and
'sepgsql_safe_lang_t' that allows unpriv users to execute DO
statement. The default is 'sepgsql_leng_t'.
We assume newly installed language may be harm, so DBA has to relabel
it explicitly, if he want user defined procedures using the language.
See also,
http://developer.postgresql.org/pgdocs/postgres/sql-createlanguage.html
http://developer.postgresql.org/pgdocs/postgres/sql-do.html
P.S)
I found a bug in MCS. It didn't constraint 'relabelfrom' permission
of 'db_procedure' class. IIRC, I fixed it before, but it might be
only MLS side. Sorry.
Thanks,
--
KaiGai Kohei <kaigai@ak.jp.nec.com>
policy/flask/access_vectors | 29 ++++++++
policy/flask/security_classes | 6 ++
policy/mcs | 16 ++++-
policy/mls | 58 ++++++++++++++-
policy/modules/kernel/kernel.if | 8 ++
policy/modules/services/postgresql.if | 125 +++++++++++++++++++++++++++++++--
policy/modules/services/postgresql.te | 116 +++++++++++++++++++++++++++++-
7 files changed, 342 insertions(+), 16 deletions(-)
2010-12-10 09:49:24 +00:00
|
|
|
mlsconstrain { db_schema } { create drop setattr relabelfrom add_name remove_name }
|
|
|
|
(( l1 eq l2 ) or
|
|
|
|
(( t1 == mlsdbwritetoclr ) and ( h1 dom l2 ) and ( l1 domby l2 )) or
|
|
|
|
(( t2 == mlsdbwriteinrange ) and ( l1 dom l2 ) and ( h1 domby h2 )) or
|
|
|
|
( t1 == mlsdbwrite ) or
|
|
|
|
( t2 == mlstrustedobject ));
|
|
|
|
|
2009-05-07 12:35:32 +00:00
|
|
|
mlsconstrain { db_table } { create drop setattr relabelfrom update insert delete }
|
2007-08-09 13:15:07 +00:00
|
|
|
(( l1 eq l2 ) or
|
|
|
|
(( t1 == mlsdbwritetoclr ) and ( h1 dom l2 ) and ( l1 domby l2 )) or
|
|
|
|
(( t2 == mlsdbwriteinrange ) and ( l1 dom l2 ) and ( h1 domby h2 )) or
|
|
|
|
( t1 == mlsdbwrite ) or
|
|
|
|
( t2 == mlstrustedobject ));
|
|
|
|
|
|
|
|
mlsconstrain { db_column } { create drop setattr relabelfrom update insert }
|
|
|
|
(( l1 eq l2 ) or
|
|
|
|
(( t1 == mlsdbwritetoclr ) and ( h1 dom l2 ) and ( l1 domby l2 )) or
|
|
|
|
(( t2 == mlsdbwriteinrange ) and ( l1 dom l2 ) and ( h1 domby h2 )) or
|
|
|
|
( t1 == mlsdbwrite ) or
|
|
|
|
( t2 == mlstrustedobject ));
|
|
|
|
|
New database object classes
The attached patch adds a few database object classes, as follows:
* db_schema
------------
A schema object performs as a namespace in database; similar to
directories in filesystem.
It seems some of (but not all) database objects are stored within
a certain schema logically. We can qualify these objects using
schema name. For example, a table: "my_tbl" within a schema: "my_scm"
is identified by "my_scm.my_tbl". This table is completely different
from "your_scm.my_tbl" that it a table within a schema: "your_scm".
Its characteristics is similar to a directory in filesystem, so
it has similar permissions.
The 'search' controls to resolve object name within a schema.
The 'add_name' and 'remove_name' controls to add/remove an object
to/from a schema.
See also,
http://developer.postgresql.org/pgdocs/postgres/sql-createschema.html
In the past discussion, a rubix folks concerned about no object
class definition for schema and catalog which is an upper level
namespace. Since I'm not certain whether we have a disadvantage
when 'db_schema' class is applied on catalog class, I don't add
this definition yet.
Default security context of 'db_table' and 'db_procedure' classes
get being computed using type_transition with 'db_schema' class,
instead of 'db_database' class. It reflects logical hierarchy of
database object more correctly.
* db_view
----------
A view object performs as a virtual table. We can run SELECT
statement on views, although it has no physical entities.
The definition of views are expanded in run-time, so it allows
us to describe complex queries with keeping readability.
This object class uniquely provides 'expand' permission that
controls whether user can expand this view, or not.
The default security context shall be computed by type transition
rule with a schema object that owning the view.
See also,
http://developer.postgresql.org/pgdocs/postgres/sql-createview.html
* db_sequence
--------------
A sequence object is a sequential number generator.
This object class uniquely provides 'get_value', 'next_value' and
'set_value' permissions. The 'get_value' controls to reference the
sequence object. The 'next_value' controls to fetch and increment
the value of sequence object. The 'set_value' controls to set
an arbitrary value.
The default security context shall be computed by type transition
rule with a schema object that owning the sequence.
See also,
http://developer.postgresql.org/pgdocs/postgres/sql-createsequence.html
* db_language
--------------
A language object is an installed engine to execute procedures.
PostgreSQL supports to define SQL procedures using regular script
languages; such as Perl, Tcl, not only SQL or binary modules.
In addition, v9.0 or later supports DO statement. It allows us to
execute a script statement on server side without defining a SQL
procedure. It requires to control whether user can execute DO
statement on this language, or not.
This object class uniquely provides 'implement' and 'execute'
permissions. The 'implement' controls whether a procedure can
be implemented with this language, or not. So, it takes security
context of the procedure as subject. The 'execute' controls to
execute code block using DO statement.
The default security context shall be computed by type transition
rule with a database object, because it is not owned by a certain
schema.
In the default policy, we provide two types: 'sepgsql_lang_t' and
'sepgsql_safe_lang_t' that allows unpriv users to execute DO
statement. The default is 'sepgsql_leng_t'.
We assume newly installed language may be harm, so DBA has to relabel
it explicitly, if he want user defined procedures using the language.
See also,
http://developer.postgresql.org/pgdocs/postgres/sql-createlanguage.html
http://developer.postgresql.org/pgdocs/postgres/sql-do.html
P.S)
I found a bug in MCS. It didn't constraint 'relabelfrom' permission
of 'db_procedure' class. IIRC, I fixed it before, but it might be
only MLS side. Sorry.
Thanks,
--
KaiGai Kohei <kaigai@ak.jp.nec.com>
policy/flask/access_vectors | 29 ++++++++
policy/flask/security_classes | 6 ++
policy/mcs | 16 ++++-
policy/mls | 58 ++++++++++++++-
policy/modules/kernel/kernel.if | 8 ++
policy/modules/services/postgresql.if | 125 +++++++++++++++++++++++++++++++--
policy/modules/services/postgresql.te | 116 +++++++++++++++++++++++++++++-
7 files changed, 342 insertions(+), 16 deletions(-)
2010-12-10 09:49:24 +00:00
|
|
|
mlsconstrain { db_sequence } { create drop setattr relabelfrom set_value }
|
|
|
|
(( l1 eq l2 ) or
|
|
|
|
(( t1 == mlsdbwritetoclr ) and ( h1 dom l2 ) and ( l1 domby l2 )) or
|
|
|
|
(( t2 == mlsdbwriteinrange ) and ( l1 dom l2 ) and ( h1 domby h2 )) or
|
|
|
|
( t1 == mlsdbwrite ) or
|
|
|
|
( t2 == mlstrustedobject ));
|
|
|
|
|
|
|
|
mlsconstrain { db_view } { create drop setattr relabelfrom }
|
|
|
|
(( l1 eq l2 ) or
|
|
|
|
(( t1 == mlsdbwritetoclr ) and ( h1 dom l2 ) and ( l1 domby l2 )) or
|
|
|
|
(( t2 == mlsdbwriteinrange ) and ( l1 dom l2 ) and ( h1 domby h2 )) or
|
|
|
|
( t1 == mlsdbwrite ) or
|
|
|
|
( t2 == mlstrustedobject ));
|
|
|
|
|
2009-05-07 12:35:32 +00:00
|
|
|
mlsconstrain { db_procedure } { create drop setattr relabelfrom }
|
|
|
|
(( l1 eq l2 ) or
|
|
|
|
(( t1 == mlsdbwritetoclr ) and ( h1 dom l2 ) and ( l1 domby l2 )) or
|
|
|
|
(( t2 == mlsdbwriteinrange ) and ( l1 dom l2 ) and ( h1 domby h2 )) or
|
|
|
|
( t1 == mlsdbwrite ) or
|
|
|
|
( t2 == mlstrustedobject ));
|
|
|
|
|
New database object classes
The attached patch adds a few database object classes, as follows:
* db_schema
------------
A schema object performs as a namespace in database; similar to
directories in filesystem.
It seems some of (but not all) database objects are stored within
a certain schema logically. We can qualify these objects using
schema name. For example, a table: "my_tbl" within a schema: "my_scm"
is identified by "my_scm.my_tbl". This table is completely different
from "your_scm.my_tbl" that it a table within a schema: "your_scm".
Its characteristics is similar to a directory in filesystem, so
it has similar permissions.
The 'search' controls to resolve object name within a schema.
The 'add_name' and 'remove_name' controls to add/remove an object
to/from a schema.
See also,
http://developer.postgresql.org/pgdocs/postgres/sql-createschema.html
In the past discussion, a rubix folks concerned about no object
class definition for schema and catalog which is an upper level
namespace. Since I'm not certain whether we have a disadvantage
when 'db_schema' class is applied on catalog class, I don't add
this definition yet.
Default security context of 'db_table' and 'db_procedure' classes
get being computed using type_transition with 'db_schema' class,
instead of 'db_database' class. It reflects logical hierarchy of
database object more correctly.
* db_view
----------
A view object performs as a virtual table. We can run SELECT
statement on views, although it has no physical entities.
The definition of views are expanded in run-time, so it allows
us to describe complex queries with keeping readability.
This object class uniquely provides 'expand' permission that
controls whether user can expand this view, or not.
The default security context shall be computed by type transition
rule with a schema object that owning the view.
See also,
http://developer.postgresql.org/pgdocs/postgres/sql-createview.html
* db_sequence
--------------
A sequence object is a sequential number generator.
This object class uniquely provides 'get_value', 'next_value' and
'set_value' permissions. The 'get_value' controls to reference the
sequence object. The 'next_value' controls to fetch and increment
the value of sequence object. The 'set_value' controls to set
an arbitrary value.
The default security context shall be computed by type transition
rule with a schema object that owning the sequence.
See also,
http://developer.postgresql.org/pgdocs/postgres/sql-createsequence.html
* db_language
--------------
A language object is an installed engine to execute procedures.
PostgreSQL supports to define SQL procedures using regular script
languages; such as Perl, Tcl, not only SQL or binary modules.
In addition, v9.0 or later supports DO statement. It allows us to
execute a script statement on server side without defining a SQL
procedure. It requires to control whether user can execute DO
statement on this language, or not.
This object class uniquely provides 'implement' and 'execute'
permissions. The 'implement' controls whether a procedure can
be implemented with this language, or not. So, it takes security
context of the procedure as subject. The 'execute' controls to
execute code block using DO statement.
The default security context shall be computed by type transition
rule with a database object, because it is not owned by a certain
schema.
In the default policy, we provide two types: 'sepgsql_lang_t' and
'sepgsql_safe_lang_t' that allows unpriv users to execute DO
statement. The default is 'sepgsql_leng_t'.
We assume newly installed language may be harm, so DBA has to relabel
it explicitly, if he want user defined procedures using the language.
See also,
http://developer.postgresql.org/pgdocs/postgres/sql-createlanguage.html
http://developer.postgresql.org/pgdocs/postgres/sql-do.html
P.S)
I found a bug in MCS. It didn't constraint 'relabelfrom' permission
of 'db_procedure' class. IIRC, I fixed it before, but it might be
only MLS side. Sorry.
Thanks,
--
KaiGai Kohei <kaigai@ak.jp.nec.com>
policy/flask/access_vectors | 29 ++++++++
policy/flask/security_classes | 6 ++
policy/mcs | 16 ++++-
policy/mls | 58 ++++++++++++++-
policy/modules/kernel/kernel.if | 8 ++
policy/modules/services/postgresql.if | 125 +++++++++++++++++++++++++++++++--
policy/modules/services/postgresql.te | 116 +++++++++++++++++++++++++++++-
7 files changed, 342 insertions(+), 16 deletions(-)
2010-12-10 09:49:24 +00:00
|
|
|
mlsconstrain { db_language } { create drop setattr relabelfrom }
|
|
|
|
(( l1 eq l2 ) or
|
|
|
|
(( t1 == mlsdbwritetoclr ) and ( h1 dom l2 ) and ( l1 domby l2 )) or
|
|
|
|
(( t2 == mlsdbwriteinrange ) and ( l1 dom l2 ) and ( h1 domby h2 )) or
|
|
|
|
( t1 == mlsdbwrite ) or
|
|
|
|
( t2 == mlstrustedobject ));
|
|
|
|
|
2009-05-07 12:35:32 +00:00
|
|
|
mlsconstrain { db_blob } { create drop setattr relabelfrom write import }
|
2007-08-09 13:15:07 +00:00
|
|
|
(( l1 eq l2 ) or
|
|
|
|
(( t1 == mlsdbwritetoclr ) and ( h1 dom l2 ) and ( l1 domby l2 )) or
|
|
|
|
(( t2 == mlsdbwriteinrange ) and ( l1 dom l2 ) and ( h1 domby h2 )) or
|
|
|
|
( t1 == mlsdbwrite ) or
|
|
|
|
( t2 == mlstrustedobject ));
|
|
|
|
|
|
|
|
mlsconstrain { db_tuple } { relabelfrom update insert delete }
|
|
|
|
(( l1 eq l2 ) or
|
|
|
|
(( t1 == mlsdbwritetoclr ) and ( h1 dom l2 ) and ( l1 domby l2 )) or
|
|
|
|
(( t2 == mlsdbwriteinrange ) and ( l1 dom l2 ) and ( h1 domby h2 )) or
|
|
|
|
( t1 == mlsdbwrite ) or
|
|
|
|
( t2 == mlstrustedobject ));
|
|
|
|
|
|
|
|
# the database upgrade/downgrade rule
|
New database object classes
The attached patch adds a few database object classes, as follows:
* db_schema
------------
A schema object performs as a namespace in database; similar to
directories in filesystem.
It seems some of (but not all) database objects are stored within
a certain schema logically. We can qualify these objects using
schema name. For example, a table: "my_tbl" within a schema: "my_scm"
is identified by "my_scm.my_tbl". This table is completely different
from "your_scm.my_tbl" that it a table within a schema: "your_scm".
Its characteristics is similar to a directory in filesystem, so
it has similar permissions.
The 'search' controls to resolve object name within a schema.
The 'add_name' and 'remove_name' controls to add/remove an object
to/from a schema.
See also,
http://developer.postgresql.org/pgdocs/postgres/sql-createschema.html
In the past discussion, a rubix folks concerned about no object
class definition for schema and catalog which is an upper level
namespace. Since I'm not certain whether we have a disadvantage
when 'db_schema' class is applied on catalog class, I don't add
this definition yet.
Default security context of 'db_table' and 'db_procedure' classes
get being computed using type_transition with 'db_schema' class,
instead of 'db_database' class. It reflects logical hierarchy of
database object more correctly.
* db_view
----------
A view object performs as a virtual table. We can run SELECT
statement on views, although it has no physical entities.
The definition of views are expanded in run-time, so it allows
us to describe complex queries with keeping readability.
This object class uniquely provides 'expand' permission that
controls whether user can expand this view, or not.
The default security context shall be computed by type transition
rule with a schema object that owning the view.
See also,
http://developer.postgresql.org/pgdocs/postgres/sql-createview.html
* db_sequence
--------------
A sequence object is a sequential number generator.
This object class uniquely provides 'get_value', 'next_value' and
'set_value' permissions. The 'get_value' controls to reference the
sequence object. The 'next_value' controls to fetch and increment
the value of sequence object. The 'set_value' controls to set
an arbitrary value.
The default security context shall be computed by type transition
rule with a schema object that owning the sequence.
See also,
http://developer.postgresql.org/pgdocs/postgres/sql-createsequence.html
* db_language
--------------
A language object is an installed engine to execute procedures.
PostgreSQL supports to define SQL procedures using regular script
languages; such as Perl, Tcl, not only SQL or binary modules.
In addition, v9.0 or later supports DO statement. It allows us to
execute a script statement on server side without defining a SQL
procedure. It requires to control whether user can execute DO
statement on this language, or not.
This object class uniquely provides 'implement' and 'execute'
permissions. The 'implement' controls whether a procedure can
be implemented with this language, or not. So, it takes security
context of the procedure as subject. The 'execute' controls to
execute code block using DO statement.
The default security context shall be computed by type transition
rule with a database object, because it is not owned by a certain
schema.
In the default policy, we provide two types: 'sepgsql_lang_t' and
'sepgsql_safe_lang_t' that allows unpriv users to execute DO
statement. The default is 'sepgsql_leng_t'.
We assume newly installed language may be harm, so DBA has to relabel
it explicitly, if he want user defined procedures using the language.
See also,
http://developer.postgresql.org/pgdocs/postgres/sql-createlanguage.html
http://developer.postgresql.org/pgdocs/postgres/sql-do.html
P.S)
I found a bug in MCS. It didn't constraint 'relabelfrom' permission
of 'db_procedure' class. IIRC, I fixed it before, but it might be
only MLS side. Sorry.
Thanks,
--
KaiGai Kohei <kaigai@ak.jp.nec.com>
policy/flask/access_vectors | 29 ++++++++
policy/flask/security_classes | 6 ++
policy/mcs | 16 ++++-
policy/mls | 58 ++++++++++++++-
policy/modules/kernel/kernel.if | 8 ++
policy/modules/services/postgresql.if | 125 +++++++++++++++++++++++++++++++--
policy/modules/services/postgresql.te | 116 +++++++++++++++++++++++++++++-
7 files changed, 342 insertions(+), 16 deletions(-)
2010-12-10 09:49:24 +00:00
|
|
|
mlsvalidatetrans { db_database db_schema db_table db_sequence db_view db_procedure db_language db_column db_tuple db_blob }
|
2007-08-09 13:15:07 +00:00
|
|
|
((( l1 eq l2 ) or
|
|
|
|
(( t3 == mlsdbupgrade ) and ( l1 domby l2 )) or
|
|
|
|
(( t3 == mlsdbdowngrade ) and ( l1 dom l2 )) or
|
|
|
|
(( t3 == mlsdbdowngrade ) and ( l1 incomp l2 ))) and
|
|
|
|
(( l1 eq h2 ) or
|
|
|
|
(( t3 == mlsdbupgrade ) and ( h1 domby h2 )) or
|
|
|
|
(( t3 == mlsdbdowngrade ) and ( h1 dom h2 )) or
|
|
|
|
(( t3 == mlsdbdowngrade ) and ( h1 incomp h2 ))));
|
|
|
|
|
2005-06-01 15:40:37 +00:00
|
|
|
') dnl end enable_mls
|