1. 23 Jun, 2006 1 commit
  2. 22 Jun, 2006 1 commit
  3. 18 Jun, 2006 2 commits
    • David S. Miller's avatar
      [NET]: Fix warnings after LSM-IPSEC changes. · 6f68dc37
      David S. Miller authored
      
      
      Assignment used as truth value in xfrm_del_sa()
      and xfrm_get_policy().
      
      Wrong argument type declared for security_xfrm_state_delete()
      when SELINUX is disabled.
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      6f68dc37
    • Catherine Zhang's avatar
      [LSM-IPsec]: SELinux Authorize · c8c05a8e
      Catherine Zhang authored
      
      
      This patch contains a fix for the previous patch that adds security
      contexts to IPsec policies and security associations.  In the previous
      patch, no authorization (besides the check for write permissions to
      SAD and SPD) is required to delete IPsec policies and security
      assocations with security contexts.  Thus a user authorized to change
      SAD and SPD can bypass the IPsec policy authorization by simply
      deleteing policies with security contexts.  To fix this security hole,
      an additional authorization check is added for removing security
      policies and security associations with security contexts.
      
      Note that if no security context is supplied on add or present on
      policy to be deleted, the SELinux module allows the change
      unconditionally.  The hook is called on deletion when no context is
      present, which we may want to change.  At present, I left it up to the
      module.
      
      LSM changes:
      
      The patch adds two new LSM hooks: xfrm_policy_delete and
      xfrm_state_delete.  The new hooks are necessary to authorize deletion
      of IPsec policies that have security contexts.  The existing hooks
      xfrm_policy_free and xfrm_state_free lack the context to do the
      authorization, so I decided to split authorization of deletion and
      memory management of security data, as is typical in the LSM
      interface.
      
      Use:
      
      The new delete hooks are checked when xfrm_policy or xfrm_state are
      deleted by either the xfrm_user interface (xfrm_get_policy,
      xfrm_del_sa) or the pfkey interface (pfkey_spddelete, pfkey_delete).
      
      SELinux changes:
      
      The new policy_delete and state_delete functions are added.
      Signed-off-by: default avatarCatherine Zhang <cxzhang@watson.ibm.com>
      Signed-off-by: default avatarTrent Jaeger <tjaeger@cse.psu.edu>
      Acked-by: default avatarJames Morris <jmorris@namei.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      c8c05a8e
  4. 01 May, 2006 1 commit
  5. 25 Mar, 2006 1 commit
  6. 21 Mar, 2006 1 commit
    • Catherine Zhang's avatar
      [SECURITY]: TCP/UDP getpeersec · 2c7946a7
      Catherine Zhang authored
      
      
      This patch implements an application of the LSM-IPSec networking
      controls whereby an application can determine the label of the
      security association its TCP or UDP sockets are currently connected to
      via getsockopt and the auxiliary data mechanism of recvmsg.
      
      Patch purpose:
      
      This patch enables a security-aware application to retrieve the
      security context of an IPSec security association a particular TCP or
      UDP socket is using.  The application can then use this security
      context to determine the security context for processing on behalf of
      the peer at the other end of this connection.  In the case of UDP, the
      security context is for each individual packet.  An example
      application is the inetd daemon, which could be modified to start
      daemons running at security contexts dependent on the remote client.
      
      Patch design approach:
      
      - Design for TCP
      The patch enables the SELinux LSM to set the peer security context for
      a socket based on the security context of the IPSec security
      association.  The application may retrieve this context using
      getsockopt.  When called, the kernel determines if the socket is a
      connected (TCP_ESTABLISHED) TCP socket and, if so, uses the dst_entry
      cache on the socket to retrieve the security associations.  If a
      security association has a security context, the context string is
      returned, as for UNIX domain sockets.
      
      - Design for UDP
      Unlike TCP, UDP is connectionless.  This requires a somewhat different
      API to retrieve the peer security context.  With TCP, the peer
      security context stays the same throughout the connection, thus it can
      be retrieved at any time between when the connection is established
      and when it is torn down.  With UDP, each read/write can have
      different peer and thus the security context might change every time.
      As a result the security context retrieval must be done TOGETHER with
      the packet retrieval.
      
      The solution is to build upon the existing Unix domain socket API for
      retrieving user credentials.  Linux offers the API for obtaining user
      credentials via ancillary messages (i.e., out of band/control messages
      that are bundled together with a normal message).
      
      Patch implementation details:
      
      - Implementation for TCP
      The security context can be retrieved by applications using getsockopt
      with the existing SO_PEERSEC flag.  As an example (ignoring error
      checking):
      
      getsockopt(sockfd, SOL_SOCKET, SO_PEERSEC, optbuf, &optlen);
      printf("Socket peer context is: %s\n", optbuf);
      
      The SELinux function, selinux_socket_getpeersec, is extended to check
      for labeled security associations for connected (TCP_ESTABLISHED ==
      sk->sk_state) TCP sockets only.  If so, the socket has a dst_cache of
      struct dst_entry values that may refer to security associations.  If
      these have security associations with security contexts, the security
      context is returned.
      
      getsockopt returns a buffer that contains a security context string or
      the buffer is unmodified.
      
      - Implementation for UDP
      To retrieve the security context, the application first indicates to
      the kernel such desire by setting the IP_PASSSEC option via
      getsockopt.  Then the application retrieves the security context using
      the auxiliary data mechanism.
      
      An example server application for UDP should look like this:
      
      toggle = 1;
      toggle_len = sizeof(toggle);
      
      setsockopt(sockfd, SOL_IP, IP_PASSSEC, &toggle, &toggle_len);
      recvmsg(sockfd, &msg_hdr, 0);
      if (msg_hdr.msg_controllen > sizeof(struct cmsghdr)) {
          cmsg_hdr = CMSG_FIRSTHDR(&msg_hdr);
          if (cmsg_hdr->cmsg_len <= CMSG_LEN(sizeof(scontext)) &&
              cmsg_hdr->cmsg_level == SOL_IP &&
              cmsg_hdr->cmsg_type == SCM_SECURITY) {
              memcpy(&scontext, CMSG_DATA(cmsg_hdr), sizeof(scontext));
          }
      }
      
      ip_setsockopt is enhanced with a new socket option IP_PASSSEC to allow
      a server socket to receive security context of the peer.  A new
      ancillary message type SCM_SECURITY.
      
      When the packet is received we get the security context from the
      sec_path pointer which is contained in the sk_buff, and copy it to the
      ancillary message space.  An additional LSM hook,
      selinux_socket_getpeersec_udp, is defined to retrieve the security
      context from the SELinux space.  The existing function,
      selinux_socket_getpeersec does not suit our purpose, because the
      security context is copied directly to user space, rather than to
      kernel space.
      
      Testing:
      
      We have tested the patch by setting up TCP and UDP connections between
      applications on two machines using the IPSec policies that result in
      labeled security associations being built.  For TCP, we can then
      extract the peer security context using getsockopt on either end.  For
      UDP, the receiving end can retrieve the security context using the
      auxiliary data mechanism of recvmsg.
      Signed-off-by: default avatarCatherine Zhang <cxzhang@watson.ibm.com>
      Acked-by: default avatarJames Morris <jmorris@namei.org>
      Acked-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      2c7946a7
  7. 20 Mar, 2006 2 commits
    • Dustin Kirkland's avatar
      [PATCH] Miscellaneous bug and warning fixes · 7306a0b9
      Dustin Kirkland authored
      
      
      This patch fixes a couple of bugs revealed in new features recently
      added to -mm1:
      * fixes warnings due to inconsistent use of const struct inode *inode
      * fixes bug that prevent a kernel from booting with audit on, and SELinux off
        due to a missing function in security/dummy.c
      * fixes a bug that throws spurious audit_panic() messages due to a missing
        return just before an error_path label
      * some reasonable house cleaning in audit_ipc_context(),
        audit_inode_context(), and audit_log_task_context()
      Signed-off-by: default avatarDustin Kirkland <dustin.kirkland@us.ibm.com>
      Signed-off-by: default avatarDavid Woodhouse <dwmw2@infradead.org>
      7306a0b9
    • Dustin Kirkland's avatar
      [PATCH] Capture selinux subject/object context information. · 8c8570fb
      Dustin Kirkland authored
      
      
      This patch extends existing audit records with subject/object context
      information. Audit records associated with filesystem inodes, ipc, and
      tasks now contain SELinux label information in the field "subj" if the
      item is performing the action, or in "obj" if the item is the receiver
      of an action.
      
      These labels are collected via hooks in SELinux and appended to the
      appropriate record in the audit code.
      
      This additional information is required for Common Criteria Labeled
      Security Protection Profile (LSPP).
      
      [AV: fixed kmalloc flags use]
      [folded leak fixes]
      [folded cleanup from akpm (kfree(NULL)]
      [folded audit_inode_context() leak fix]
      [folded akpm's fix for audit_ipc_perm() definition in case of !CONFIG_AUDIT]
      Signed-off-by: default avatarDustin Kirkland <dustin.kirkland@us.ibm.com>
      Signed-off-by: default avatarDavid Woodhouse <dwmw2@infradead.org>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
      8c8570fb
  8. 04 Feb, 2006 1 commit
  9. 01 Feb, 2006 1 commit
    • Randy Dunlap's avatar
      [PATCH] tpm_bios: needs more securityfs_ functions · ed5a9270
      Randy Dunlap authored
      tpm_bios.c needs securityfs_xyz() functions.
      
      Does include/linux/security.h need stubs for these, or should
      char/tpm/Makefile just be modified to say:
      
      ifdef CONFIG_ACPI
      ifdef CONFIG_SECURITY
      	obj-$(CONFIG_TCG_TPM) += tpm_bios.o
      endif
      endif
      
      drivers/char/tpm/tpm_bios.c:494: warning: implicit declaration of function 'securityfs_create_dir'
      drivers/char/tpm/tpm_bios.c:494: warning: assignment makes pointer from integer without a cast
      drivers/char/tpm/tpm_bios.c:499: warning: implicit declaration of function 'securityfs_create_file'
      drivers/char/tpm/tpm_bios.c:501: warning: assignment makes pointer from integer without a cast
      drivers/char/tpm/tpm_bios.c:508: warning: assignment makes pointer from integer without a cast
      drivers/char/tpm/tpm_bios.c:523: warning: implicit declaration of function 'securityfs_remove'
      *** Warning: "securityfs_create_file" [drivers/char/tpm/tpm_bios.ko] undefined!
      *** Warning: "securityfs_create_dir" [drivers/char/tpm/tpm_bios.ko] undefined!
      *** Warning: "securityfs_remove" [drivers/char/tpm/tpm_bios.ko] undefined!
      
      There are also some gcc and sparse warnings that could be fixed.
      (see http://www.xenotime.net/linux/doc/build-tpm.out
      
      )
      Signed-off-by: default avatarRandy Dunlap <rdunlap@xenotime.net>
      Cc: Serge Hallyn <serue@us.ibm.com>
      Cc: Greg KH <greg@kroah.com>
      Cc: Kylene Jo Hall <kjhall@us.ibm.com>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      ed5a9270
  10. 03 Jan, 2006 1 commit
    • Trent Jaeger's avatar
      [LSM-IPSec]: Security association restriction. · df71837d
      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 XFRM subsystem,
      pfkey interface, ipv4/ipv6, and xfrm_user interface to restrict a
      socket to use only authorized security associations (or no security
      association) to send/receive network packets.
      
      Patch purpose:
      
      The patch is designed to enable access control per packets based on
      the strongly authenticated IPSec security association.  Such access
      controls augment the existing ones based on network interface and IP
      address.  The former are very coarse-grained, and the latter can be
      spoofed.  By using IPSec, the system 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 overall approach is that policy (xfrm_policy) entries set by
      user-level programs (e.g., setkey for ipsec-tools) are extended with a
      security context that is used at policy selection time in the XFRM
      subsystem to restrict the sockets that can send/receive packets via
      security associations (xfrm_states) that are built from those
      policies.
      
      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:
      
      On output, the policy retrieved (via xfrm_policy_lookup or
      xfrm_sk_policy_lookup) must be authorized for the security context of
      the socket and the same security context is required for resultant
      security association (retrieved or negotiated via racoon in
      ipsec-tools).  This is enforced in xfrm_state_find.
      
      On input, the policy retrieved must also be authorized for the socket
      (at __xfrm_policy_check), and the security context of the policy must
      also match the security association being used.
      
      The patch has virtually no impact on packets that do not use IPSec.
      The existing Netfilter (outgoing) and LSM rcv_skb hooks are used as
      before.
      
      Also, if IPSec is used without security contexts, the impact is
      minimal.  The LSM must allow such policies to be selected for the
      combination of socket and remote machine, but subsequent IPSec
      processing proceeds as in the original case.
      
      Testing:
      
      The pfkey interface is tested using the ipsec-tools.  ipsec-tools have
      been modified (a separate ipsec-tools patch is available for version
      0.5) that supports assignment of xfrm_policy entries and security
      associations with security contexts via setkey and the negotiation
      using the security contexts via racoon.
      
      The xfrm_user interface is tested via ad hoc programs that set
      security contexts.  These programs are also available from me, and
      contain programs for setting, getting, and deleting policy for testing
      this interface.  Testing of sa functions was done by tracing kernel
      behavior.
      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>
      df71837d
  11. 31 Oct, 2005 2 commits
    • David Howells's avatar
      [PATCH] Keys: Add LSM hooks for key management [try #3] · 29db9190
      David Howells authored
      
      
      The attached patch adds LSM hooks for key management facilities. The notable
      changes are:
      
       (1) The key struct now supports a security pointer for the use of security
           modules. This will permit key labelling and restrictions on which
           programs may access a key.
      
       (2) Security modules get a chance to note (or abort) the allocation of a key.
      
       (3) The key permission checking can now be enhanced by the security modules;
           the permissions check consults LSM if all other checks bear out.
      
       (4) The key permissions checking functions now return an error code rather
           than a boolean value.
      
       (5) An extra permission has been added to govern the modification of
           attributes (UID, GID, permissions).
      
      Note that there isn't an LSM hook specifically for each keyctl() operation,
      but rather the permissions hook allows control of individual operations based
      on the permission request bits.
      
      Key management access control through LSM is enabled by automatically if both
      CONFIG_KEYS and CONFIG_SECURITY are enabled.
      
      This should be applied on top of the patch ensubjected:
      
      	[PATCH] Keys: Possessor permissions should be additive
      Signed-Off-By: default avatarDavid Howells <dhowells@redhat.com>
      Signed-off-by: default avatarChris Wright <chrisw@osdl.org>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      29db9190
    • James Morris's avatar
      [PATCH] SELinux: canonicalize getxattr() · d381d8a9
      James Morris authored
      
      
      This patch allows SELinux to canonicalize the value returned from
      getxattr() via the security_inode_getsecurity() hook, which is called after
      the fs level getxattr() function.
      
      The purpose of this is to allow the in-core security context for an inode
      to override the on-disk value.  This could happen in cases such as
      upgrading a system to a different labeling form (e.g.  standard SELinux to
      MLS) without needing to do a full relabel of the filesystem.
      
      In such cases, we want getxattr() to return the canonical security context
      that the kernel is using rather than what is stored on disk.
      
      The implementation hooks into the inode_getsecurity(), adding another
      parameter to indicate the result of the preceding fs-level getxattr() call,
      so that SELinux knows whether to compare a value obtained from disk with
      the kernel value.
      
      We also now allow getxattr() to work for mountpoint labeled filesystems
      (i.e.  mount with option context=foo_t), as we are able to return the
      kernel value to the user.
      Signed-off-by: default avatarJames Morris <jmorris@namei.org>
      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>
      d381d8a9
  12. 28 Oct, 2005 1 commit
  13. 08 Oct, 2005 1 commit
  14. 09 Sep, 2005 3 commits
    • Stephen Smalley's avatar
      [PATCH] remove the inode_post_link and inode_post_rename LSM hooks · e31e14ec
      Stephen Smalley authored
      
      
      This patch removes the inode_post_link and inode_post_rename LSM hooks as
      they are unused (and likely useless).
      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>
      e31e14ec
    • Stephen Smalley's avatar
      [PATCH] Remove security_inode_post_create/mkdir/symlink/mknod hooks · a74574aa
      Stephen Smalley authored
      
      
      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: 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>
      a74574aa
    • Stephen Smalley's avatar
      [PATCH] security: enable atomic inode security labeling · 5e41ff9e
      Stephen Smalley authored
      
      
      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: 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>
      5e41ff9e
  15. 29 Aug, 2005 1 commit
  16. 09 Jul, 2005 1 commit
    • Greg KH's avatar
      [PATCH] add securityfs for all LSMs to use · b67dbf9d
      Greg KH authored
      
      
      Here's a small patch against 2.6.13-rc2 that adds securityfs, a virtual
      fs that all LSMs can use instead of creating their own.  The fs should
      be mounted at /sys/kernel/security, and the fs creates that mount point.
      This will make the LSB people happy that we aren't creating a new
      /my_lsm_fs directory in the root for every different LSM.
      
      It has changed a bit since the last version, thanks to comments from
      Mike Waychison.
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      Signed-off-by: default avatarChris Wright <chrisw@osdl.org>
      b67dbf9d
  17. 16 Apr, 2005 1 commit
    • 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!
      1da177e4