[redhat-lspp] why do we have an lspp policy module?

Linda Knippers linda.knippers at hp.com
Tue Dec 5 19:58:54 UTC 2006


The current kickstart script installs an LSPP policy module that
includes things that look like bug fixes to the mls policy.  I
think the file has become out of date with the updates that Dan
has been making to the mls policy so do we need this anymore?

If there are policy bugs I'd really like to see them fixed in
one place and Dan seems to be doing a great job of generating
policy rpms.  Right now having a separate policy module means
our testing is out of sync.  We might need an lspp policy post-RHEL5
GA but is there a reason we need it now?

The current lspp_policy.te contents is below.

-- ljk

## Customized SELinux policy for LSPP evaluated configuration

policy_module(lspp_policy,1.0)

#############################################################################
### Additional audit
#############################################################################

gen_require(`
        attribute domain;
')

# Audit setting of security relevant process attributes
# These settings are OPTIONAL
auditallow domain self:process setcurrent;
auditallow domain self:process setexec;
auditallow domain self:process setfscreate;
#auditallow domain self:process setsocketcreate; # FIXME
#auditallow domain self:process setipccreate; # FIXME

#############################################################################
### Relabeling printer devices
#############################################################################

gen_require(`
        type secadm_t, printer_device_t;
')

allow secadm_t printer_device_t:chr_file {getattr relabelfrom relabelto};

#############################################################################
### Polyinstantiation support
#############################################################################

gen_require(`
        type newrole_t, sshd_t, local_login_t;
        type user_t, staff_t;
        type tmp_t, user_home_dir_t, staff_home_dir_t;
        type user_tmp_t, staff_tmp_t, user_home_t, staff_home_t;
        attribute userdomain;
')

type polyparent_t;
type polymember_t;
files_poly_parent(polyparent_t)
files_poly_member(polymember_t)

## FIXME: these don't work?
#allow userdomain polyparent_t:dir manage_dir_perms;
#allow userdomain polymember_t:dir manage_dir_perms;
#type_member userdomain polyparent_t:dir polymember_t;
#allow user_t polymember_t:dir manage_dir_perms;
#allow staff_t polymember_t:dir manage_dir_perms;

files_poly(tmp_t)
files_poly(user_home_dir_t)
files_poly(staff_home_dir_t)

type_member user_t tmp_t:dir user_tmp_t;
type_member staff_t tmp_t:dir staff_tmp_t;

type_member user_t user_home_dir_t:dir user_home_t;
type_member staff_t staff_home_dir_t:dir staff_home_t;

files_polyinstantiate_all(sshd_t)
files_polyinstantiate_all(local_login_t)
files_polyinstantiate_all(newrole_t)

### additional polyinst workarounds
### (FIXME, should these be fixed in refpolicy?)

gen_require(`
        type bin_t, sshd_t, newrole_t, staff_su_t, run_init_t;
')

# let newrole execute the PAM framework (it didn't do that originally)
auth_exec_pam(newrole_t)

# sshd needs to write the faillog / tallylog file
# FIXME, needs: semanage fcontext -a -t faillog_t /var/log/tallylog
auth_rw_faillog(sshd_t)
auth_rw_faillog(newrole_t)
auth_rw_faillog(staff_su_t)
auth_rw_faillog(run_init_t)

# this seems to be missing from refpolicy files_polyinstantiate_all()?
allow sshd_t polyparent_t:dir {read search create remove_name};
allow local_login_t polyparent_t:dir {read search create remove_name};
allow newrole_t polyparent_t:dir {read search create remove_name};

# need to be able to execute /etc/security/namespace.init
# (that file needs to be labeled as bin_t, default label is bad)
allow sshd_t bin_t:file {read execute execute_no_trans ioctl};
allow local_login_t bin_t:file {read execute execute_no_trans ioctl};
allow newrole_t bin_t:file {read execute execute_no_trans ioctl};

gen_require(`
        type mount_t; # FIXME: why:
')
allow mount_t var_log_t:dir mounton; # FIXME: why ?!





More information about the redhat-lspp mailing list