Implement kernel labeling of the MLS (multilevel security) field of
security contexts for files which have no existing MLS field.  This is to
enable upgrades of a system from non-MLS to MLS without performing a full
filesystem relabel including all of the mountpoints, which would be quite
painful for users.

With this patch, with MLS enabled, if a file has no MLS field, the kernel
internally adds an MLS field to the in-core inode (but not to the on-disk
file).  This MLS field added is the default for the superblock, allowing
per-mountpoint control over the values via fixed policy or mount options.

This patch has been tested by enabling MLS without relabeling its
filesystem, and seems to be working correctly.
Signed-off-by: NJames Morris <jmorris@redhat.com>
Signed-off-by: NStephen Smalley <sds@epoch.ncsc.mil>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

This patch,based on sample code by Roland McGrath, adds an execheap
permission check that controls the ability to make the heap executable so
that this can be prevented in almost all cases (the X server is presently
an exception, but this will hopefully be resolved in the future) so that
even programs with execmem permission will need to have the anonymous
memory mapped in order to make it executable.

The only reason that we use a permission check for such restriction (vs.
making it unconditional) is that the X module loader presently needs it; it
could possibly be made unconditional in the future when X is changed.

The policy patch for the execheap permission is available at:
http://pearls.tuxedo-es.org/patches/selinux/policy-execheap.patchSigned-off-by: NLorenzo Hernandez Garcia-Hierro <lorenzo@gnu.org>
Acked-by: NJames Morris <jmorris@redhat.com>
Acked-by: NStephen Smalley <sds@tycho.nsa.gov>
Cc: Ingo Molnar <mingo@elte.hu>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

This patch adds an execstack permission check that controls the ability to
make the main process stack executable so that attempts to make the stack
executable can still be prevented even if the process is allowed the
existing execmem permission in order to e.g.  perform runtime code
generation.  Note that this does not yet address thread stacks.  Note also
that unlike the execmem check, the execstack check is only applied on
mprotect calls, not mmap calls, as the current security_file_mmap hook is
not passed the necessary information presently.

The original author of the code that makes the distinction of the stack
region, is Ingo Molnar, who wrote it within his patch for
/proc/<pid>/maps markers.
(http://marc.theaimsgroup.com/?l=linux-kernel&m=110719881508591&w=2)

The patches also can be found at:
http://pearls.tuxedo-es.org/patches/selinux/policy-execstack.patch
http://pearls.tuxedo-es.org/patches/selinux/kernel-execstack.patch

policy-execstack.patch is the patch that needs to be applied to the policy in
order to support the execstack permission and exclude it
from general_domain_access within macros/core_macros.te.

kernel-execstack.patch adds such permission to the SELinux code within
the kernel and adds the proper permission check to the selinux_file_mprotect() hook.
Signed-off-by: NLorenzo Hernandez Garcia-Hierro <lorenzo@gnu.org>
Acked-by: NJames Morris <jmorris@redhat.com>
Acked-by: NStephen Smalley <sds@tycho.nsa.gov>
Cc: Ingo Molnar <mingo@elte.hu>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

This patch provides finer grained permissions for the audit family of
Netlink sockets under SELinux.

1.  We need a way to differentiate between privileged and unprivileged
   reads of kernel data maintained by the audit subsystem.  The AUDIT_GET
   operation is unprivileged: it returns the current status of the audit
   subsystem (e.g.  whether it's enabled etc.).  The AUDIT_LIST operation
   however returns a list of the current audit ruleset, which is considered
   privileged by the audit folk.  To deal with this, a new SELinux
   permission has been implemented and applied to the operation:
   nlmsg_readpriv, which can be allocated to appropriately privileged
   domains.  Unprivileged domains would only be allocated nlmsg_read.

2.  There is a requirement for certain domains to generate audit events
   from userspace.  These events need to be collected by the kernel,
   collated and transmitted sequentially back to the audit daemon.  An
   example is user level login, an auditable event under CAPP, where
   login-related domains generate AUDIT_USER messages via PAM which are
   relayed back to auditd via the kernel.  To prevent handing out
   nlmsg_write permissions to such domains, a new permission has been
   added, nlmsg_relay, which is intended for this type of purpose: data is
   passed via the kernel back to userspace but no privileged information is
   written to the kernel.

Also, AUDIT_LOGIN messages are now valid only for kernel->user messaging,
so this value has been removed from the SELinux nlmsgtab (which is only
used to check user->kernel messages).
Signed-off-by: NJames Morris <jmorris@redhat.com>
Signed-off-by: NStephen Smalley <sds@tycho.nsa.gov>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

This patch adds SELinux support for the KOBJECT_UEVENT Netlink family, so
that SELinux can apply finer grained controls to it.  For example, security
policy for hald can be locked down to the KOBJECT_UEVENT Netlink family
only.  Currently, this family simply defaults to the default Netlink socket
class.

Note that some new permission definitions are added to sync with changes in
the core userspace policy package, which auto-generates header files.
Signed-off-by: NJames Morris <jmorris@redhat.com>
Signed-off-by: NStephen Smalley <sds@tycho.nsa.gov>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

Initial git repository build. I'm not bothering with the full history,
even though we have it. We can create a separate "historical" git
archive of that later if we want to, and in the meantime it's about
3.2GB when imported into git - space that would just make the early
git days unnecessarily complicated, when we don't have a lot of good
infrastructure for it.

Let it rip!