Adds a new open permission inside SELinux when 'opening' a file.  The idea
is that opening a file and reading/writing to that file are not the same
thing.  Its different if a program had its stdout redirected to /tmp/output
than if the program tried to directly open /tmp/output. This should allow
policy writers to more liberally give read/write permissions across the
policy while still blocking many design and programing flaws SELinux is so
good at catching today.
Signed-off-by: NEric Paris <eparis@redhat.com>
Acked-by: NStephen Smalley <sds@tycho.nsa.gov>
Reviewed-by: NPaul Moore <paul.moore@hp.com>
Signed-off-by: NJames Morris <jmorris@namei.org>

Fix SELinux to handle 64-bit capabilities correctly, and to catch
future extensions of capabilities beyond 64 bits to ensure that SELinux
is properly updated.
Signed-off-by: NStephen Smalley <sds@tycho.nsa.gov>
Signed-off-by: NJames Morris <jmorris@namei.org>

Add additional Flask definitions to support the new "peer" object class and
additional permissions to the netif, node, and packet object classes.  Also,
bring the kernel Flask definitions up to date with the Fedora SELinux policies
by adding the "flow_in" and "flow_out" permissions to the "packet" class.
Signed-off-by: NPaul Moore <paul.moore@hp.com>
Signed-off-by: NJames Morris <jmorris@namei.org>

Add a new security check on mmap operations to see if the user is attempting
to mmap to low area of the address space.  The amount of space protected is
indicated by the new proc tunable /proc/sys/vm/mmap_min_addr and defaults to
0, preserving existing behavior.

This patch uses a new SELinux security class "memprotect."  Policy already
contains a number of allow rules like a_t self:process * (unconfined_t being
one of them) which mean that putting this check in the process class (its
best current fit) would make it useless as all user processes, which we also
want to protect against, would be allowed. By taking the memprotect name of
the new class it will also make it possible for us to move some of the other
memory protect permissions out of 'process' and into the new class next time
we bump the policy version number (which I also think is a good future idea)
Acked-by: NStephen Smalley <sds@tycho.nsa.gov>
Acked-by: NChris Wright <chrisw@sous-sol.org>
Signed-off-by: NEric Paris <eparis@redhat.com>
Signed-off-by: NJames Morris <jmorris@namei.org>

Remove userland security class and permission definitions from the kernel
as the kernel only needs to use and validate its own class and permission
definitions and userland definitions may change.
Signed-off-by: NStephen Smalley <sds@tycho.nsa.gov>
Signed-off-by: NJames Morris <jmorris@namei.org>

This patch implements SELinux kernel support for DCCP
(http://linux-net.osdl.org/index.php/DCCP), which is similar in
operation to TCP in terms of connected state between peers.

The SELinux support for DCCP is thus modeled on existing handling of
TCP.

A new DCCP socket class is introduced, to allow protocol
differentation.  The permissions for this class inherit all of the
socket permissions, as well as the current TCP permissions (node_bind,
name_bind etc). IPv4 and IPv6 are supported, although labeled
networking is not, at this stage.

Patches for SELinux userspace are at:
http://people.redhat.com/jmorris/selinux/dccp/user/

I've performed some basic testing, and it seems to be working as
expected.  Adding policy support is similar to TCP, the only real
difference being that it's a different protocol.
Acked-by: NStephen Smalley <sds@tycho.nsa.gov>
Signed-off-by: NJames Morris <jmorris@namei.org>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

The current approach to labeling Security Associations for SELinux
purposes uses a one-to-one mapping between xfrm policy rules and
security associations.

This doesn't address the needs of real world MLS (Multi-level System,
traditional Bell-LaPadula) environments where a single xfrm policy
rule (pertaining to a range, classified to secret for example) might
need to map to multiple Security Associations (one each for
classified, secret, top secret and all the compartments applicable to
these security levels).

This patch set addresses the above problem by allowing for the mapping
of a single xfrm policy rule to multiple security associations, with
each association used in the security context it is defined for. It
also includes the security context to be used in IKE negotiation in
the acquire messages sent to the IKE daemon so that a unique SA can be
negotiated for each unique security context. A couple of bug fixes are
also included; checks to make sure the SAs used by a packet match
policy (security context-wise) on the inbound and also that the bundle
used for the outbound matches the security context of the flow. This
patch set also makes the use of the SELinux sid in flow cache lookups
seemless by including the sid in the flow key itself. Also, open
requests as well as connection-oriented child sockets are labeled
automatically to be at the same level as the peer to allow for use of
appropriately labeled IPSec associations.

Description of changes:

A "sid" member has been added to the flow cache key resulting in the
sid being available at all needed locations and the flow cache lookups
automatically using the sid. The flow sid is derived from the socket
on the outbound and the SAs (unlabeled where an SA was not used) on
the inbound.

Outbound case:
1. Find policy for the socket.

2. OLD: Find an SA that matches the policy.
 NEW: Find an SA that matches BOTH the policy and the flow/socket.
   This is necessary since not every SA that matches the policy
   can be used for the flow/socket. Consider policy range Secret-TS,
   and SAs each for Secret and TS. We don't want a TS socket to
   use the Secret SA. Hence the additional check for the SA Vs. flow/socket.

3. NEW: When looking thru bundles for a policy, make sure the
        flow/socket can use the bundle. If a bundle is not found,
        create one, calling for IKE if necessary. If using IKE,
        include the security context in the acquire message to the IKE
        daemon.

Inbound case:
1. OLD: Find policy for the socket.
 NEW: Find policy for the incoming packet based on the sid of the
      SA(s) it used or the unlabeled sid if no SAs were
      used. (Consider a case where a socket is "authorized" for two
      policies (unclassified-confidential, secret-top_secret). If the
      packet has come in using a secret SA, we really ought to be
      using the latter policy (secret-top_secret).)

2. OLD: BUG: No check to see if the SAs used by the packet agree with
             the policy sec_ctx-wise.

             (It was indicated in selinux_xfrm_sock_rcv_skb() that
              this was being accomplished by
              (x->id.spi == tmpl->id.spi || !tmpl->id.spi) in xfrm_state_ok,
	      but it turns out tmpl->id.spi
              would normally be zero (unless xfrm policy rules specify one
              at the template level, which they usually don't).
 NEW: The socket is checked for access to the SAs used (based on the
      sid of the SAs) in selinux_xfrm_sock_rcv_skb().

Forward case:
 This would be Step 1 from the Inbound case, followed by Steps 2 and 3
from the Outbound case.

Outstanding items/issues:

- Timewait acknowledgements and such are generated in the
  current/upstream implementation using a NULL socket resulting in the
  any_socket sid (SYSTEM_HIGH) to be used. This problem is not addressed
  by this patch set.

This patch: Add new flask definitions to SELinux

Adds a new avperm "polmatch" to arbitrate flow/state access to a xfrm
policy rule.
Signed-off-by: NVenkat Yekkirala <vyekkirala@TrustedCS.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Below is a patch to add a new /proc/self/attr/sockcreate A process may write a
context into this interface and all subsequent sockets created will be labeled
with that context.  This is the same idea as the fscreate interface where a
process can specify the label of a file about to be created.  At this time one
envisioned user of this will be xinetd.  It will be able to better label
sockets for the actual services.  At this time all sockets take the label of
the creating process, so all xinitd sockets would just be labeled the same.

I tested this by creating a tcp sender and listener.  The sender was able to
write to this new proc file and then create sockets with the specified label.
I am able to be sure the new label was used since the avc denial messages
kicked out by the kernel included both the new security permission
setsockcreate and all the socket denials were for the new label, not the label
of the running process.
Signed-off-by: NEric Paris <eparis@redhat.com>
Signed-off-by: NJames Morris <jmorris@namei.org>
Cc: Chris Wright <chrisw@sous-sol.org>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

Add a /proc/<pid>/attr/keycreate entry that stores the appropriate context for
newly-created keys.  Modify the selinux_key_alloc hook to make use of the new
entry.  Update the flask headers to include a new "setkeycreate" permission
for processes.  Update the flask headers to include a new "create" permission
for keys.  Use the create permission to restrict which SIDs each task can
assign to newly-created keys.  Add a new parameter to the security hook
"security_key_alloc" to indicate whether it is being invoked by the kernel, or
from userspace.  If it is being invoked by the kernel, the security hook
should never fail.  Update the documentation to reflect these changes.
Signed-off-by: NMichael LeMay <mdlemay@epoch.ncsc.mil>
Signed-off-by: NJames Morris <jmorris@namei.org>
Signed-off-by: NDavid Howells <dhowells@redhat.com>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

Introduce SELinux hooks to support the access key retention subsystem
within the kernel.  Incorporate new flask headers from a modified version
of the SELinux reference policy, with support for the new security class
representing retained keys.  Extend the "key_alloc" security hook with a
task parameter representing the intended ownership context for the key
being allocated.  Attach security information to root's default keyrings
within the SELinux initialization routine.

Has passed David's testsuite.
Signed-off-by: NMichael LeMay <mdlemay@epoch.ncsc.mil>
Signed-off-by: NDavid Howells <dhowells@redhat.com>
Signed-off-by: NJames Morris <jmorris@namei.org>
Acked-by: NChris Wright <chrisw@sous-sol.org>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

Secmark implements a new scheme for adding security markings to
packets via iptables, as well as changes to SELinux to use these
markings for security policy enforcement.  The rationale for this
scheme is explained and discussed in detail in the original threads:

 http://thread.gmane.org/gmane.linux.network/34927/
 http://thread.gmane.org/gmane.linux.network/35244/

Examples of policy and rulesets, as well as a full archive of patches
for iptables and SELinux userland, may be found at:

http://people.redhat.com/jmorris/selinux/secmark/

The code has been tested with various compilation options and in
several scenarios, including with 'complicated' protocols such as FTP
and also with the new generic conntrack code with IPv6 connection
tracking.

This patch:

Add support for a new object class ('packet'), and associated
permissions ('send', 'recv', 'relabelto').  These are used to enforce
security policy for network packets labeled with SECMARK, and for
adding labeling rules.
Signed-off-by: NJames Morris <jmorris@namei.org>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

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,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!