The ioctl operations code is being renamed to the more generic
"extended permissions." This commit brings the policy compiler
up to date with the kernel patch.
Signed-off-by: Jeff Vander Stoep <jeffv@google.com>
Adds support for new policy statements whitelisting individual ioctl
commands. Ioctls provide many of the operations necessary for driver control.
The typical driver supports a device specific set of operations accessible
by the ioctl system call and specified by the command argument. SELinux
provides per operation access control to many system operations e.g. chown,
kill, setuid, ipc_lock, etc. Ioclts on the other hand are granted on a per
file descriptor basis using the ioctl permission, meaning that the set of
operations provided by the driver are granted on an all-or-nothing basis.
In some cases this may be acceptable, but often the same driver provides a
large and diverse set of operations such as benign and necessary functionality
as well as dangerous capabilities or access to system information that should
be restricted.
Example policy:
allow <source> <target>:<class> { 0x8900-0x8905 0x8910 }
auditallow <source> <target>:<class> 0x8901
The ioctl permission is still required in order to make an ioctl call. If no
individual ioctl commands are specified, only the ioctl permission is
checked by the kernel - i.e. status quo. This allows ioctl whitelisting to
done in a targeted manner, protecting desired drivers without requiring every
ioctl command to be known and specified before use and otherwise allowing
existing policy to be used as-is.
This only implements ioctl whitelisting support for monolithic kernel policies
built via checkpolicy. Support for modules and CIL remains to be done.
Bug: 19419509
Change-Id: I198e8c9279b94d8ce4ae5625018daa99577ee970
Signed-off-by: Jeff Vander Stoep <jeffv@google.com>
Acked-by: Stephen Smalley <sds@tycho.nsa.gov>
In Xen on ARM, device tree nodes identified by a path (string) need to
be labeled by the security policy.
Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
This expands IOMEMCON device context entries to 64 bits. This change is
required to support static I/O memory range labeling for systems with
over 16TB of physical address space. The policy version number change
is shared with the next patch.
While this makes no changes to SELinux policy, a new SELinux policy
compatibility entry was added in order to avoid breaking compilation of
an SELinux policy without explicitly specifying the policy version.
Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
We currently have a mechanism in which the default user, role, and range
can be picked up from the source or the target object. This implements
the same thing for types. The kernel will override this with type
transition rules and similar. This is just the default if nothing
specific is given.
Signed-off-by: Eric Paris <eparis@redhat.com>
Acked-by: Dan Walsh <dwalsh@redhat.com>
We would like to be able to say that the user, role, or range of a newly
created object should be based on the user, role, or range of either the
source or the target of the creation operation. aka, for a new file
this could be the user of the creating process or the user or the parent
directory. This patch implements the new language and the policydb
support to give this information to the kernel.
Signed-off-by: Eric Paris <eparis@redhat.com>
Acked-by: Dan Walsh <dwalsh@redhat.com>
Both boolean and tunable keywords are processed by define_bool_tunable(),
argument 0 and 1 would be passed for boolean and tunable respectively.
For tunable, a TUNABLE flag would be set in cond_bool_datum_t.flags.
Note, when creating an if-else conditional we can not know if the
tunable identifier is indeed a tunable(for example, a boolean may be
misused in tunable_policy() or vice versa), thus the TUNABLE flag
for cond_node_t would be calculated and used in expansion when all
booleans/tunables copied during link.
Signed-off-by: Harry Ciao <qingtao.cao@windriver.com>
Signed-off-by: Eric Paris <eparis@redhat.com>
Acked-by: Dan Walsh <dwalsh@redhat.com>
1. Add a uint32_t "flavor" field and an ebitmap "roles" to the
role_datum_t structure;
2. Add a new "attribute_role" statement and its handler to declare
a role attribute;
3. Modify declare_role() to setup role_datum_t.flavor according
to the isattr argument;
4. Add a new "roleattribute" rule and its handler, which will record
the regular role's (policy value - 1) into the role attribute's
role_datum_t.roles ebitmap;
5. Modify the syntax for the role-types rule only to define the
role-type associations;
6. Add a new role-attr rule to support the declaration of a single
role, and optionally the role attribute that the role belongs to;
7. Check if the new_role used in role-transition rule is a regular role;
8. Support to require a role attribute;
9. Modify symtab_insert() to allow multiple declarations only for
the regular role, while a role attribute can't be declared more than once
and can't share a same name with another regular role.
Signed-off-by: Harry Ciao <qingtao.cao@windriver.com>
Signed-off-by: Steve Lawrence <slawrence@tresys.com>
This patch adds support for using the last path component as part of the
information in making labeling decisions for new objects. A example
rule looks like so:
type_transition unconfined_t etc_t:file system_conf_t eric;
This rule says if unconfined_t creates a file in a directory labeled
etc_t and the last path component is "eric" (no globbing, no matching
magic, just exact strcmp) it should be labeled system_conf_t.
The kernel and policy representation does not have support for such
rules in conditionals, and thus policy explicitly notes that fact if
such a rule is added to a conditional.
Signed-off-by: Eric Paris <eparis@redhat.com>
Signed-off-by: Steve Lawrence <slawrence@tresys.com>
Handle the class field in the role_transition rule. If no class is
specified, then it would be set to the "process" class by default.
Signed-off-by: Harry Ciao <qingtao.cao@windriver.com>
Signed-off-by: Steve Lawrence <slawrence@tresys.com>
