Add policy for the new TUN driver access controls which allow policy to
control which domains have the ability to create and attach to TUN/TAP
devices. The policy rules for creating and attaching to a device are as
shown below:
# create a new device
allow domain_t self:tun_socket { create };
# attach to a persistent device (created by tunlbl_t)
allow domain_t tunlbl_t:tun_socket { relabelfrom };
allow domain_t self:tun_socket { relabelto };
Further discussion can be found on this thread:
* http://marc.info/?t=125080850900002&r=1&w=2
Signed-off-by: Paul Moore <paul.moore@hp.com>
The X policy for users is currently split between
userdom_xwindows_client_template() and xserver_role(). Deprecate
the former and put the rules into the latter.
For preserving restricted X roles (xguest), divide the rules
into xserver_restricted_role() and xserver_role().
The latest revision of the labeled policy patches which enable both labeled
and unlabeled policy support for NetLabel. This revision takes into account
Chris' feedback from the first version and reduces the number of interface
calls in each domain down to two at present: one for unlabeled access, one for
NetLabel access. The older, transport layer specific interfaces, are still
present for use by third-party modules but are not used in the default policy
modules.
trunk: Use netmsg initial SID for MLS-only Netlabel packets, from Paul Moore.
This patch changes the policy to use the netmsg initial SID as the "base"
SID/context for NetLabel packets which only have MLS security attributes.
Currently we use the unlabeled initial SID which makes it very difficult to
distinquish between actual unlabeled packets and those packets which have MLS
security attributes.
- Allow semanage to read from /root on strict non-MLS for
local policy modules.
- Gentoo init script fixes for udev.
- Allow udev to read kernel modules.inputmap.
- Dnsmasq fixes from testing.
- Allow kernel NFS server to getattr filesystems so df can work
on clients.
This policy is much tighter than the GConf policy from the old example
policy. It only allows gconfd to access configuration data stored by
GConf. Users can modify configuration data using gconftool-2 or
gconf-editor, both of which use gconfd. GConf manages multiple
configuration sources, so gconfd should be used to make any changes
anyway. Normal users who aren't trying to directly edit the
configuration data of GConf won't notice anything different.
There is also a difference between this policy and the old example
policy in handling directories in /tmp. The old example policy
labeled /tmp/gconfd-USER with ROLE_gconfd_tmp_t, but, since there was no
use of the file_type_auto_trans macro, if that directory was deleted
gconfd would create one labeled as tmp_t. This policy uses the
files_tmp-filetrans macro to cause a directory in /tmp created by gconfd
to be labeled as $1_tmp_t. It is not labeled with $1_gconf_tmp_t,
because if /tmp/orbit-USER is deleted, gconfd will create it (through
use of ORBit) and it would get the $1_gconf_tmp_t label. By having
gconfd create $1_tmp_t directories in /tmp and $1_gconf_tmp_t files and
directories in directories labeled with $1_tmp_t, it can control its
data without requiring any future bonobo or Gnome policies to have
access to $1_gconf_tmp_t.
This patch is related to work that I am doing in making gconfd an
userspace object manager. If any user program can modify the
configuration data that GConf stores, than making gconfd an userspace
object manager would be useless.
Signed-off-by: James Carter <jwcart2@tycho.nsa.gov>
* fix userdom_search_all_users_home_content() to use search_dir_perms;
* change ssh daemon macro to use userdom_search_all_users_home_dirs() instead of _home_content()
