From 78d6e4acfc000b07dbf85b076fa523e95e72da3f Sun, 13 Feb 2011 18:55:53 +0100
From: Dominick Grift <domg472@gmail.com>
Date: Sun, 13 Feb 2011 18:55:09 +0100
Subject: [PATCH] Users calling apache_role were not able to manage httpd_user_content_t files, directories and symbolic links.
Users calling apache_role were not able to manage httpd_user_content_t files, directories and symbolic links.
Signed-off-by: Dominick Grift <domg472@gmail.com>
Change build.conf to default to modular policy builds rather than
monolithic policy builds. Rationale: All modern Linux distributions
that incorporate SELinux support have switched to using modular policy,
and many of the policy tools (semodule, semanage, and even modern
versions of setsebool) only work if using modular policy.
Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov>
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>
On an Xorg 1.9 system with evdev driver (for keyboard InputClass), the
xserver_t domain needs to be able to read from the proper device nodes as
well as query the udev_tbl_t directory and udev itself.
Signed-off-by: Sven Vermeulen <sven.vermeulen@siphos.be>
The mdadm application will write into /sys/.../uevent whenever arrays are
assembled or disassembled.
Signed-off-by: Sven Vermeulen <sven.vermeulen@siphos.be>
The LVM subsystem uses system-wide semaphores for various activities.
Although the system boots properly without these (apart from the AVC denials
of course), I would assume that they are here to ensure no corruption of any
kind happens in case of concurrent execution / race conditions.
As such, I rather enable it explicitly in the security policy.
Signed-off-by: Sven Vermeulen <sven.vermeulen@siphos.be>
The modprobe utility is sometimes used (for instance for ALSA) to request
the Linux kernel to load a module (through aliases) rather than explicitly
loading the module.
Signed-off-by: Sven Vermeulen <sven.vermeulen@siphos.be>
When SELinux user system_u starts crond during system booting up, its
cron job process should be in the system_cronjob_t domain, which has
the required entrypoint permission on system crontab files labeled as
system_cron_spool_t. Otherwise we can run into below error messages:
Jan 31 08:40:53 QtCao crond[535]: (system_u) Unauthorized SELinux context (/etc/crontab)
Jan 31 08:40:53 QtCao crond[535]: (system_u) Unauthorized SELinux context (/etc/cron.d/sysstat)
The weird thing is that the getdefaultcon command even can not fetch
"system_r:cronjob_t:s0" but "system_r:logrotate_t:s0" ! After fixing
default_contexts files the getdefaultcon command could properly fetch
"system_r:system_cronjob_t:s0" :
root@QtCao:/root> getdefaultcon system_u system_u:system_r:crond_t:s0
system_u:system_r:logrotate_t:s0
root@QtCao:/root>
root@QtCao:/root> grep crond_t /etc/selinux/refpolicy-mls/contexts/default_contexts
system_r:crond_t:s0 user_r:cronjob_t:s0 staff_r:cronjob_t:s0 sysadm_r:cronjob_t:s0 system_r:system_cronjob_t:s0 unconfined_r:unconfined_cronjob_t:s0
root@QtCao:/root>
root@QtCao:/root> getdefaultcon system_u system_u:system_r:crond_t:s0
system_u:system_r:system_cronjob_t:s0
root@QtCao:/root>
Signed-off-by: Harry Ciao <qingtao.cao@windriver.com>
The below patch changes a typo "directores" to "directories", and also
fixes a comment to sound more proper.
Signed-off-by: Justin P. Mattock <justinmattock@gmail.com>
The below patch, changes the workd SElinux to SELinux to match the rest
in the policy and outside.
Signed-off-by: Justin P. Mattock <justinmattock@gmail.com>
Add the support to login and use the system from /dev/console.
1. Make gettty_t able to use the /dev/console;
2. Make local_login_t able to relabel /dev/console to user tty types;
3. Provide the type_change rule for relabeling /dev/console.
All above supports are controlled by the allow_console tunable.
Signed-off-by: Harry Ciao <qingtao.cao@windriver.com>
The attached patch adds a few database object classes, as follows:
* db_schema
------------
A schema object performs as a namespace in database; similar to
directories in filesystem.
It seems some of (but not all) database objects are stored within
a certain schema logically. We can qualify these objects using
schema name. For example, a table: "my_tbl" within a schema: "my_scm"
is identified by "my_scm.my_tbl". This table is completely different
from "your_scm.my_tbl" that it a table within a schema: "your_scm".
Its characteristics is similar to a directory in filesystem, so
it has similar permissions.
The 'search' controls to resolve object name within a schema.
The 'add_name' and 'remove_name' controls to add/remove an object
to/from a schema.
See also,
http://developer.postgresql.org/pgdocs/postgres/sql-createschema.html
In the past discussion, a rubix folks concerned about no object
class definition for schema and catalog which is an upper level
namespace. Since I'm not certain whether we have a disadvantage
when 'db_schema' class is applied on catalog class, I don't add
this definition yet.
Default security context of 'db_table' and 'db_procedure' classes
get being computed using type_transition with 'db_schema' class,
instead of 'db_database' class. It reflects logical hierarchy of
database object more correctly.
* db_view
----------
A view object performs as a virtual table. We can run SELECT
statement on views, although it has no physical entities.
The definition of views are expanded in run-time, so it allows
us to describe complex queries with keeping readability.
This object class uniquely provides 'expand' permission that
controls whether user can expand this view, or not.
The default security context shall be computed by type transition
rule with a schema object that owning the view.
See also,
http://developer.postgresql.org/pgdocs/postgres/sql-createview.html
* db_sequence
--------------
A sequence object is a sequential number generator.
This object class uniquely provides 'get_value', 'next_value' and
'set_value' permissions. The 'get_value' controls to reference the
sequence object. The 'next_value' controls to fetch and increment
the value of sequence object. The 'set_value' controls to set
an arbitrary value.
The default security context shall be computed by type transition
rule with a schema object that owning the sequence.
See also,
http://developer.postgresql.org/pgdocs/postgres/sql-createsequence.html
* db_language
--------------
A language object is an installed engine to execute procedures.
PostgreSQL supports to define SQL procedures using regular script
languages; such as Perl, Tcl, not only SQL or binary modules.
In addition, v9.0 or later supports DO statement. It allows us to
execute a script statement on server side without defining a SQL
procedure. It requires to control whether user can execute DO
statement on this language, or not.
This object class uniquely provides 'implement' and 'execute'
permissions. The 'implement' controls whether a procedure can
be implemented with this language, or not. So, it takes security
context of the procedure as subject. The 'execute' controls to
execute code block using DO statement.
The default security context shall be computed by type transition
rule with a database object, because it is not owned by a certain
schema.
In the default policy, we provide two types: 'sepgsql_lang_t' and
'sepgsql_safe_lang_t' that allows unpriv users to execute DO
statement. The default is 'sepgsql_leng_t'.
We assume newly installed language may be harm, so DBA has to relabel
it explicitly, if he want user defined procedures using the language.
See also,
http://developer.postgresql.org/pgdocs/postgres/sql-createlanguage.htmlhttp://developer.postgresql.org/pgdocs/postgres/sql-do.html
P.S)
I found a bug in MCS. It didn't constraint 'relabelfrom' permission
of 'db_procedure' class. IIRC, I fixed it before, but it might be
only MLS side. Sorry.
Thanks,
--
KaiGai Kohei <kaigai@ak.jp.nec.com>
policy/flask/access_vectors | 29 ++++++++
policy/flask/security_classes | 6 ++
policy/mcs | 16 ++++-
policy/mls | 58 ++++++++++++++-
policy/modules/kernel/kernel.if | 8 ++
policy/modules/services/postgresql.if | 125 +++++++++++++++++++++++++++++++--
policy/modules/services/postgresql.te | 116 +++++++++++++++++++++++++++++-
7 files changed, 342 insertions(+), 16 deletions(-)
On 01/05/2011 08:48 AM, Christopher J. PeBenito wrote:
> On 12/16/10 12:32, Paul Nuzzi wrote:
>> On 12/15/2010 03:54 PM, Christopher J. PeBenito wrote:
>>> On 12/10/10 18:22, Paul Nuzzi wrote:
>>>> Added labeled IPSec support to hadoop. SELinux will be able to enforce what services are allowed to
>>>> connect to. Labeled IPSec can enforce the range of services they can receive from. This enforces
>>>> the architecture of Hadoop without having to modify any of the code. This adds a level of
>>>> confidentiality, integrity, and authentication provided outside the software stack.
>>>
>>> A few things.
>>>
>>> The verb used in Reference Policy interfaces for peer recv is recvfrom
>>> (a holdover from previous labeled networking implementations). So the
>>> interfaces are like hadoop_recvfrom_datanode().
>>
>> Easy change.
>>
>>> It seems like setkey should be able to setcontext any type used on ipsec
>>> associations. I think the best thing would be to add additional support
>>> to either the ipsec or corenetwork modules (I haven't decided which one
>>> yet) for associations. So, say we have an interface called
>>> ipsec_spd_type() which adds the parameter type to the attribute
>>> ipsec_spd_types. Then we can have an allow setkey_t
>>> ipsec_spd_types:association setkey; rule and we don't have to update it
>>> every time more labeled network is added.
>>
>> That seems a lot less clunky than updating setkey every time we add a new association.
>>
>>> This is definitely wrong since its not a file:
>>> +files_type(hadoop_lan_t)
>>
>> Let me know how you would like to handle associations and I could update the
>> patch.
>
> Lets go with putting the associations in corenetwork.
>
>> Will the files_type error be cleared up when we re-engineer this?
>
> I'm not sure what you mean. The incorrect rule was added in your patch.
>
Adds labeled IPSec policy to hadoop to control the remote processes that are allowed to connect to the cloud's services.
Signed-off-by: Paul Nuzzi <pjnuzzi@tycho.ncsc.mil>
