During build and eventual activation of the base policy, the load_policy_t
domain attempts to use a portage file descriptor. However, this serves no
purpose (the loading is done correctly and everything is logged
appropriately).
Hence, we dontaudit this use.
Signed-off-by: Sven Vermeulen <sven.vermeulen@siphos.be>
Systems that use LDAPS (LDAP over SSL/TLS) for their sysnet_* activities
currently fail since these domains do not allow proper access to the random
devices (needed for SSL/TLS). This patch adds this privilege to
sysnet_use_ldap.
Signed-off-by: Sven Vermeulen <sven.vermeulen@siphos.be>
This small patch updates the dhcpc_t (DHCP client domain) to allow updating the
kernel's routing tables (as that is a primary purpose of a DHCP client) as well
as interact with the kernel through the net_sysctls.
Also, one client (dhcpcd) uses /var/run/dhcpcd so add that in the file context
definition as well.
Signed-off-by: Sven Vermeulen <sven.vermeulen@siphos.be>
Since april, the *-multi applications offered through iptables are combined
through a single binary called xtables-multi. The previous commands are now
symbolic links towards this application.
Signed-off-by: Sven Vermeulen <sven.vermeulen@siphos.be>
When audit subsystem is enabled, and setfiles works from root
dir, setfiles would send the AUDIT_FS_RELABEL information to
audit system, If no permission to send the information to audit
by netlink, setfiles would return error.
The test cases to reproduce this defect:
=> restorecon -R /
=> echo $?
255
=>
Signed-off-by: Roy.Li <rongqing.li@windriver.com>
This is intended to label /run/udev, but I am assuming that everyone
will use file_contexts.subs(_dist)? to substitute /var/run for /run,
since there are currently no other fcs for /run in refpolicy.
The label is udev_tbl_t instead of udev_var_run_t, because /run/udev
contains the data which used to be in /dev/.udev.
After a quick discussion with dominique, new attempt due to two issues:
1. No need (or even forbidden) to have "role $1 types foo_exec_t"
2. Suggestion to use the raid_run_mdadm name instead of raid_mdadm_role. The
idea here is to use raid_mdadm_role for prefixed domains (cfr. screen)
whereas raid_run_mdadm is to transition and run into a specific domain
Without wanting to (re?)start any discussion on prefixed versus non-prefixed
domains, such a naming convention could help us to keep the reference policy
cleaner (and naming conventions easy).
Also, refpolicy InterfaceNaming document only talks about run, not role.
So, without much further ado... ;-)
The system administrator (sysadm_r role) needs to use mdadm, but is not
allowed to use the mdadm_t type.
Rather than extend raid_domtrans_mdadm to allow this as well, use a
raid_mdadm_role (a bit more conform other role usages).
The other users of raid_domtrans_mdadm are all domains that run in system_r
role, which does have this type allowed (as per the system/raid.te
definition), so it wouldn't hurt to use raid_domtrans_mdadm for this.
Signed-off-by: Sven Vermeulen <sven.vermeulen@siphos.be>
I realized the policy wasn't complete for handling udev_tbl_t dirs, and
updating it wouldn't work because we couldn't make a filetrans on dirs,
since all the dirs in /dev would become udev_tbl_t. i.e. this would have
been required, but would make problems: dev_filetrans(udev_t, udev_tbl_t, dir);
Various changes to the Xen userspace policy, including:
- Add gntdev and gntalloc device node labeling.
- Create separate domains for blktap and qemu-dm rather than leaving them in xend_t.
- No need to allow xen userspace to create its own device nodes anymore;
this is handled automatically by the kernel/udev.
- No need to allow xen userspace access to generic raw storage; even if
using dedicated partitions/LVs for disk images, you can just label them
with xen_image_t.
The blktap and qemu-dm domains are stubs and will likely need to be
further expanded, but they should definitely not be left in xend_t. Not
sure if I should try to use qemu_domain_template() instead for qemu-dm,
but I don't see any current users of that template (qemu_t uses
virt_domain_template instead), and qemu-dm has specific interactions
with Xen.
Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov>
Since sudo 1.7.4, the timestamp directory has moved from /var/run/sudo to
/var/db/sudo, lib or adm (in that order). See also the sudo changeset
http://www.sudo.ws/repos/sudo/rev/8c9440423d98
Keeping the "old" one (/var/run/sudo) for a while for those systems where
sudo has not been updated yet (change is since 1.7.4, Jul 14 2010).
Signed-off-by: Sven Vermeulen <sven.vermeulen@siphos.be>
