1. 22 Sep, 2006 1 commit
    • Venkat Yekkirala's avatar
      [MLSXFRM]: Granular IPSec associations for use in MLS environments · 51bd3986
      Venkat Yekkirala authored
      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
      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: default avatarVenkat Yekkirala <vyekkirala@TrustedCS.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
  2. 26 Jun, 2006 2 commits
    • Eric Paris's avatar
      [PATCH] SELinux: Add sockcreate node to procattr API · 42c3e03e
      Eric Paris authored
      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: default avatarEric Paris <eparis@redhat.com>
      Signed-off-by: default avatarJames Morris <jmorris@namei.org>
      Cc: Chris Wright <chrisw@sous-sol.org>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
    • Michael LeMay's avatar
      [PATCH] keys: add a way to store the appropriate context for newly-created keys · 4eb582cf
      Michael LeMay authored
      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: default avatarMichael LeMay <mdlemay@epoch.ncsc.mil>
      Signed-off-by: default avatarJames Morris <jmorris@namei.org>
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
  3. 22 Jun, 2006 1 commit
  4. 17 Jun, 2006 2 commits
  5. 06 Jan, 2006 1 commit
  6. 03 Jan, 2006 1 commit
    • Trent Jaeger's avatar
      [LSM-IPSec]: Per-packet access control. · d28d1e08
      Trent Jaeger authored
      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
      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,
      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
      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
      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: default avatarTrent Jaeger <tjaeger@cse.psu.edu>
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
  7. 25 Jun, 2005 2 commits
  8. 01 May, 2005 1 commit
    • James Morris's avatar
      [PATCH] SELinux: add finer grained permissions to Netlink audit processing · b207a290
      James Morris authored
      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: default avatarJames Morris <jmorris@redhat.com>
      Signed-off-by: default avatarStephen Smalley <sds@tycho.nsa.gov>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
  9. 16 Apr, 2005 2 commits
    • James Morris's avatar
      [PATCH] SELinux: add support for NETLINK_KOBJECT_UEVENT · 0c9b7942
      James Morris authored
      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
      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: default avatarJames Morris <jmorris@redhat.com>
      Signed-off-by: default avatarStephen Smalley <sds@tycho.nsa.gov>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
    • Linus Torvalds's avatar
      Linux-2.6.12-rc2 · 1da177e4
      Linus Torvalds authored
      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!