My previous version had a minor bug in admin_role where it was using cobblerd_var_log_t, and cobblerd_var_lib_t instead of cobbler_var_log_t, and cobbler_var_lib_t.
Whilst i was at it, i decided the implement a cobbler_etc_t for cobbler content in /etc. This because you cannot admin a cobbler environment witouth having access to cobbler config files and i dont want to give cobbler_admin access to manage etc_t.
As a consequence if this i also removed the files_read_etc_files(cobblerd_t), as i think that cobbler only needed it to read its own files in /etc. However this is not confirmed, and it may need read access to etc_t afteral.
Also i would like to underscore my reason for using public_content_rw_t. One of the reasons is that i do not want to give cobbler access to manage httpd_sys_content_rw_t. In general i do not want to depend on apache module at all.
Signed-off-by: Dominick Grift <domg472@gmail.com>
Signed-off-by: Chris PeBenito <pebenito@gentoo.org>
This one makes an effort to check for syntax and that it actually compiles.
Signed-off-by: Matthew Ife <deleriux@airattack-central.com>
Signed-off-by: Chris PeBenito <cpebenito@tresys.com>
The motivation for this was xdm_t objects not getting cleaned up,
so the user session tried to interact with them. But since the
default user type is unconfined this problem has gone away for now.
Signed-off-by: Eamon Walsh <ewalsh@tycho.nsa.gov>
Signed-off-by: Chris PeBenito <cpebenito@tresys.com>
X Object Manager policy revisions to xserver.if.
This commit consists of two parts:
1. Revisions to xserver_object_types_template and
xserver_common_x_domain_template. This reflects the dropping
of many of the specific event, extension, and property types.
2. New interfaces:
xserver_manage_core_devices: Gives control over core mouse/keyboard.
xserver_unprotected: Allows all clients to access a domain's X objects.
Modified interfaces:
xserver_unconfined: Added x_domain typeattribute statement.
Signed-off-by: Eamon Walsh <ewalsh@tycho.nsa.gov>
Signed-off-by: Chris PeBenito <cpebenito@tresys.com>
X Object Manager policy revisions to xserver.te.
This commit consists of three main parts:
1. Code movement. There were X object manager-related statements
scattered somewhat throughout the file; these have been consolidated,
which resulted in some other statements moving (e.g. iceauth_t).
2. Type changes. Many of the specific event, extension, and property
types have been dropped for the time being. The rootwindow_t and
remote_xclient_t types have been renamed, and a root_xcolormap_t
type has been (re-)added. This is for naming consistency.
An "xserver_unprotected" alias has been added for use in labeling
clients whose resources should be globally accessible (e.g. xdm_t).
3. Policy changes. These are mostly related to devices, which now have
separate x_keyboard and x_pointer classes. The "Hacks" section
has been cleaned up, and various other classes have had the default
permissions tweaked.
Signed-off-by: Eamon Walsh <ewalsh@tycho.nsa.gov>
Signed-off-by: Chris PeBenito <cpebenito@tresys.com>
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().
A recent update added an generic context for the lock files, so the
entry in distro_redhat can be removed.
Signed-off-by: Manoj Srivastava <srivasta@debian.org>
Signed-off-by: Chris PeBenito <cpebenito@tresys.com>
The attached patch allows unprivileged clients to export from or import
to the largeobject owned by themselves.
The current security policy does not allow them to import/export any
largeobjects without any clear reason.
NOTE: Export of the largeobject means that it dumps whole of the
largeobject into a local file, so SE-PostgreSQL checks both of
db_blob:{read export} on the largeobject and file:{write} on the
local file. Import is a reversal behavior.
KaiGai Kohei
The attached patch fixes incorrect behavior in sepgsql_enable_users_ddl.
The current policy allows users/unprivs to run ALTER TABLE statement
unconditionally, because db_table/db_column:{setattr} is allowed outside
of the boolean. It should be moved to conditional section.
In addition, they are also allowed to db_procedure:{create drop setattr}
for xxxx_sepgsql_proc_exec_t, but it means we allows them to create, drop
or alter definition of the functions unconditionally. So, it also should
be moved to conditional section.
The postgresql.te allows sepgsql_client_type to modify sepgsql_table_t
and sepgsql_sysobj_t when sepgsql_enable_users_ddl is enabled, but
it should not be allowed.
KaiGai Kohei
OK, the attached patch adds the following types for unprivileged clients.
- unpriv_sepgsql_table_t
- unpriv_sepgsql_sysobj_t
- unpriv_sepgsql_proc_exec_t
- unpriv_sepgsql_blob_t
These types are the default for unprivileged and unprefixed domains,
such as httpd_t and others.
In addition, TYPE_TRANSITION rules are moved to outside of tunable
of the sepgsql_enable_users_ddl. IIRC, it was enclosed within the
tunable because UBAC domains (user_t and so on) were allowed to
create sepgsql_table_t, and its default was pointed to this type
when sepgsql_enable_users_ddl is disabled.
However, it has different meanings now, so the TYPE_TRANSITION rules
should be unconditional.
KaiGai Kohei
- rework: Add a comment of "deprecated" for deprecated permissions.
- bugfix: MCS policy did not constrain the following permissions.
db_database:{getattr}
db_table:{getattr lock}
db_column:{getattr}
db_procedure:{drop getattr setattr}
db_blob:{getattr import export}
- rework: db_table:{lock} is moved to reader side, because it makes
impossible to refer read-only table with foreign-key constraint.
(FK checks internally acquire explicit locks.)
- bugfix: some of permissions in db_procedure class are allowed
on sepgsql_trusted_proc_t, but it is a domain, not a procedure.
It should allow them on sepgsql_trusted_proc_exec_t.
I also aliased sepgsql_proc_t as sepgsql_proc_exec_t to avoid
such kind of confusion, as Chris suggested before.
- rework: we should not allow db_procedure:{install} on the
sepgsql_trusted_proc_exec_t, because of a risk to invoke trusted
procedure implicitly.
- bugfix: MLS policy dealt db_blob:{export} as writer-side permission,
but it is required whrn the largeobject is refered.
- bugfix: MLS policy didn't constrain the db_procedure class.
Add MLS constraints for several network related access controls including
the new ingress/egress controls and the older Secmark controls. Based on
the following post to the SELinux Reference Policy mailing list:
* http://oss.tresys.com/pipermail/refpolicy/2009-February/000579.html
