This is needed to allow more fine-grained control over X devices without
using different types. Using different types is problematic because
devices act as subjects in the X Flask implementation, and subjects
cannot be labeled through a type transition (since the output role is
hardcoded to object_r).
Signed-off-by: Eamon Walsh <ewalsh@tycho.nsa.gov>
Hello
This a patch for adding xscreensaver policy.
I think it need a specific policy because of the auth_domtrans_chk_passwd.
cordially
Signed-off-by: LABBE Corentin <corentin.labbe@geomatys.fr>
The nscd policy module uses the old nscd cache location. The cache location
changed with glibc 2.7-1, and the current nscd does place the files in
/var/cache/nscd/.
Signed-off-by: Manoj Srivastava <srivasta@debian.org>
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>
Add the new "tun_socket" class to the flask definitions. The "tun_socket"
object class is used by the new TUN driver hooks which allow policy to control
access to TUN/TAP devices.
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 unconfined role is running java in the unconfined_java_t. The current
policy only has a domtrans interface, so the unconfined_java_t domain is not
added to unconfined_r. Add a run interface and change the unconfined module
to use this new interface.
> Whats the difference between add/remove and create/destroy?
>
> The devices are in a kind of hierarchy. You can now create one or more
> "master devices" (mouse cursor and keyboard focus). The physical input
> devices are "slave devices" that attach to master devices.
>
> Add/remove controls the ability to add/remove slave devices from a
> master device. Create/destroy controls the ability to create new master
> devices.
Unconfined_cronjob_t is not a valid cron job domain because the cron
module is lacking a transition from the crond to the unconfined_cronjob_t
domain. This adds the transition and also a constraints exemption since
part of the transition is also a seuser and role change typically.
> From my understanding of the FUSE website, the data from the userland FS
> is transferred through this device. Since the data may go up to system
> high, I believe the device should still be system high.
>
Making it systemhigh will generate lots of AVC messages on every login
at X Since fusefs is mounted at ~/.gfs. It will also make it unusable I
believe on an MLS machine. Mostly I have seen fusefs used for remote
access to data. sshfs for example.
switch dbus ranged calls from daemon domain to system domain. This works
around a type transition conflict. It is also why the non-ranged
init_system_domain() is used instead of init_daemon_domain().
