This patch contains two corrections to the LSM-IPsec Nethooks patches
previously applied.  

(1) free a security context on a failed insert via xfrm_user 
interface in xfrm_add_policy.  Memory leak.

(2) change the authorization of the allocation of a security context
in a xfrm_policy or xfrm_state from both relabelfrom and relabelto 
to setcontext.
Signed-off-by: NTrent Jaeger <tjaeger@cse.psu.edu>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

This patch series implements per packet access control via the
extension of the Linux Security Modules (LSM) interface by hooks in
the XFRM and pfkey subsystems that leverage IPSec security
associations to label packets.  Extensions to the SELinux LSM are
included that leverage the patch for this purpose.

This patch implements the changes necessary to the SELinux LSM to
create, deallocate, and use security contexts for policies
(xfrm_policy) and security associations (xfrm_state) that enable
control of a socket's ability to send and receive packets.

Patch purpose:

The patch is designed to enable the SELinux LSM to implement access
control on individual packets based on the strongly authenticated
IPSec security association.  Such access controls augment the existing
ones in SELinux based on network interface and IP address.  The former
are very coarse-grained, and the latter can be spoofed.  By using
IPSec, the SELinux can control access to remote hosts based on
cryptographic keys generated using the IPSec mechanism.  This enables
access control on a per-machine basis or per-application if the remote
machine is running the same mechanism and trusted to enforce the
access control policy.

Patch design approach:

The patch's main function is to authorize a socket's access to a IPSec
policy based on their security contexts.  Since the communication is
implemented by a security association, the patch ensures that the
security association's negotiated and used have the same security
context.  The patch enables allocation and deallocation of such
security contexts for policies and security associations.  It also
enables copying of the security context when policies are cloned.
Lastly, the patch ensures that packets that are sent without using a
IPSec security assocation with a security context are allowed to be
sent in that manner.

A presentation available at
www.selinux-symposium.org/2005/presentations/session2/2-3-jaeger.pdf
from the SELinux symposium describes the overall approach.

Patch implementation details:

The function which authorizes a socket to perform a requested
operation (send/receive) on a IPSec policy (xfrm_policy) is
selinux_xfrm_policy_lookup.  The Netfilter and rcv_skb hooks ensure
that if a IPSec SA with a securit y association has not been used,
then the socket is allowed to send or receive the packet,
respectively.

The patch implements SELinux function for allocating security contexts
when policies (xfrm_policy) are created via the pfkey or xfrm_user
interfaces via selinux_xfrm_policy_alloc.  When a security association
is built, SELinux allocates the security context designated by the
XFRM subsystem which is based on that of the authorized policy via
selinux_xfrm_state_alloc.

When a xfrm_policy is cloned, the security context of that policy, if
any, is copied to the clone via selinux_xfrm_policy_clone.

When a xfrm_policy or xfrm_state is freed, its security context, if
any is also freed at selinux_xfrm_policy_free or
selinux_xfrm_state_free.

Testing:

The SELinux authorization function is tested using ipsec-tools.  We
created policies and security associations with particular security
contexts and added SELinux access control policy entries to verify the
authorization decision.  We also made sure that packets for which no
security context was supplied (which either did or did not use
security associations) were authorized using an unlabelled context.
Signed-off-by: NTrent Jaeger <tjaeger@cse.psu.edu>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

This patch removes the inode_post_create/mkdir/mknod/symlink LSM hooks as
they are obsoleted by the new inode_init_security hook that enables atomic
inode security labeling.

If anyone sees any reason to retain these hooks, please speak now.  Also,
is anyone using the post_rename/link hooks; if not, those could also be
removed.
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>

The following patch set enables atomic security labeling of newly created
inodes by altering the fs code to invoke a new LSM hook to obtain the security
attribute to apply to a newly created inode and to set up the incore inode
security state during the inode creation transaction.  This parallels the
existing processing for setting ACLs on newly created inodes.  Otherwise, it
is possible for new inodes to be accessed by another thread via the dcache
prior to complete security setup (presently handled by the
post_create/mkdir/...  LSM hooks in the VFS) and a newly created inode may be
left unlabeled on the disk in the event of a crash.  SELinux presently works
around the issue by ensuring that the incore inode security label is
initialized to a special SID that is inaccessible to unprivileged processes
(in accordance with policy), thereby preventing inappropriate access but
potentially causing false denials on legitimate accesses.  A simple test
program demonstrates such false denials on SELinux, and the patch solves the
problem.  Similar such false denials have been encountered in real
applications.

This patch defines a new inode_init_security LSM hook to obtain the security
attribute to apply to a newly created inode and to set up the incore inode
security state for it, and adds a corresponding hook function implementation
to SELinux.
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 improves memory use by SELinux by both reducing the avtab node
size and reducing the number of avtab nodes.  The memory savings are
substantial, e.g.  on a 64-bit system after boot, James Morris reported the
following data for the targeted and strict policies:

            #objs  objsize   kernmem
Targeted:
  Before:  237888       40     9.1MB
  After:    19968       24     468KB

Strict:
  Before:  571680       40   21.81MB
  After:   221052       24    5.06MB

The improvement in memory use comes at a cost in the speed of security
server computations of access vectors, but these computations are only
required on AVC cache misses, and performance measurements by James Morris
using a number of benchmarks have shown that the change does not cause any
significant degradation.

Note that a rebuilt policy via an updated policy toolchain
(libsepol/checkpolicy) is required in order to gain the full benefits of
this patch, although some memory savings benefits are immediately applied
even to older policies (in particular, the reduction in avtab node size).
Sources for the updated toolchain are presently available from the
sourceforge CVS tree (http://sourceforge.net/cvs/?group_id=21266), and
tarballs are available from http://www.flux.utah.edu/~sds.
Signed-off-by: NStephen Smalley <sds@tycho.nsa.gov>
Signed-off-by: NJames Morris <jmorris@namei.org>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

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!