1. 27 5月, 2011 1 次提交
    • K
      selinux: fix case of names with whitespace/multibytes on /selinux/create · 0f7e4c33
      Kohei Kaigai 提交于
      I submit the patch again, according to patch submission convension.
      
      This patch enables to accept percent-encoded object names as forth
      argument of /selinux/create interface to avoid possible bugs when we
      give an object name including whitespace or multibutes.
      
      E.g) if and when a userspace object manager tries to create a new object
       named as "resolve.conf but fake", it shall give this name as the forth
       argument of the /selinux/create. But sscanf() logic in kernel space
       fetches only the part earlier than the first whitespace.
       In this case, selinux may unexpectedly answer a default security context
       configured to "resolve.conf", but it is bug.
      
      Although I could not test this patch on named TYPE_TRANSITION rules
      actually, But debug printk() message seems to me the logic works
      correctly.
      I assume the libselinux provides an interface to apply this logic
      transparently, so nothing shall not be changed from the viewpoint of
      application.
      Signed-off-by: NKaiGai Kohei <kohei.kaigai@emea.nec.com>
      Signed-off-by: NEric Paris <eparis@redhat.com>
      0f7e4c33
  2. 13 5月, 2011 1 次提交
  3. 12 5月, 2011 1 次提交
    • G
      SELINUX: add /sys/fs/selinux mount point to put selinuxfs · 7a627e3b
      Greg Kroah-Hartman 提交于
      In the interest of keeping userspace from having to create new root
      filesystems all the time, let's follow the lead of the other in-kernel
      filesystems and provide a proper mount point for it in sysfs.
      
      For selinuxfs, this mount point should be in /sys/fs/selinux/
      
      Cc: Stephen Smalley <sds@tycho.nsa.gov>
      Cc: James Morris <jmorris@namei.org>
      Cc: Eric Paris <eparis@parisplace.org>
      Cc: Lennart Poettering <mzerqung@0pointer.de>
      Cc: Daniel J Walsh <dwalsh@redhat.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      [include kobject.h - Eric Paris]
      [use selinuxfs_obj throughout - Eric Paris]
      Signed-off-by: NEric Paris <eparis@redhat.com>
      7a627e3b
  4. 29 4月, 2011 11 次提交
  5. 26 4月, 2011 4 次提交
  6. 25 4月, 2011 3 次提交
  7. 23 4月, 2011 1 次提交
  8. 20 4月, 2011 1 次提交
  9. 08 4月, 2011 2 次提交
  10. 02 4月, 2011 1 次提交
  11. 31 3月, 2011 1 次提交
  12. 29 3月, 2011 4 次提交
  13. 24 3月, 2011 2 次提交
    • S
      userns: rename is_owner_or_cap to inode_owner_or_capable · 2e149670
      Serge E. Hallyn 提交于
      And give it a kernel-doc comment.
      
      [akpm@linux-foundation.org: btrfs changed in linux-next]
      Signed-off-by: NSerge E. Hallyn <serge.hallyn@canonical.com>
      Cc: "Eric W. Biederman" <ebiederm@xmission.com>
      Cc: Daniel Lezcano <daniel.lezcano@free.fr>
      Acked-by: NDavid Howells <dhowells@redhat.com>
      Cc: James Morris <jmorris@namei.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      2e149670
    • S
      userns: security: make capabilities relative to the user namespace · 3486740a
      Serge E. Hallyn 提交于
      - Introduce ns_capable to test for a capability in a non-default
        user namespace.
      - Teach cap_capable to handle capabilities in a non-default
        user namespace.
      
      The motivation is to get to the unprivileged creation of new
      namespaces.  It looks like this gets us 90% of the way there, with
      only potential uid confusion issues left.
      
      I still need to handle getting all caps after creation but otherwise I
      think I have a good starter patch that achieves all of your goals.
      
      Changelog:
      	11/05/2010: [serge] add apparmor
      	12/14/2010: [serge] fix capabilities to created user namespaces
      	Without this, if user serge creates a user_ns, he won't have
      	capabilities to the user_ns he created.  THis is because we
      	were first checking whether his effective caps had the caps
      	he needed and returning -EPERM if not, and THEN checking whether
      	he was the creator.  Reverse those checks.
      	12/16/2010: [serge] security_real_capable needs ns argument in !security case
      	01/11/2011: [serge] add task_ns_capable helper
      	01/11/2011: [serge] add nsown_capable() helper per Bastian Blank suggestion
      	02/16/2011: [serge] fix a logic bug: the root user is always creator of
      		    init_user_ns, but should not always have capabilities to
      		    it!  Fix the check in cap_capable().
      	02/21/2011: Add the required user_ns parameter to security_capable,
      		    fixing a compile failure.
      	02/23/2011: Convert some macros to functions as per akpm comments.  Some
      		    couldn't be converted because we can't easily forward-declare
      		    them (they are inline if !SECURITY, extern if SECURITY).  Add
      		    a current_user_ns function so we can use it in capability.h
      		    without #including cred.h.  Move all forward declarations
      		    together to the top of the #ifdef __KERNEL__ section, and use
      		    kernel-doc format.
      	02/23/2011: Per dhowells, clean up comment in cap_capable().
      	02/23/2011: Per akpm, remove unreachable 'return -EPERM' in cap_capable.
      
      (Original written and signed off by Eric;  latest, modified version
      acked by him)
      
      [akpm@linux-foundation.org: fix build]
      [akpm@linux-foundation.org: export current_user_ns() for ecryptfs]
      [serge.hallyn@canonical.com: remove unneeded extra argument in selinux's task_has_capability]
      Signed-off-by: NEric W. Biederman <ebiederm@xmission.com>
      Signed-off-by: NSerge E. Hallyn <serge.hallyn@canonical.com>
      Acked-by: N"Eric W. Biederman" <ebiederm@xmission.com>
      Acked-by: NDaniel Lezcano <daniel.lezcano@free.fr>
      Acked-by: NDavid Howells <dhowells@redhat.com>
      Cc: James Morris <jmorris@namei.org>
      Signed-off-by: NSerge E. Hallyn <serge.hallyn@canonical.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      3486740a
  14. 13 3月, 2011 1 次提交
  15. 04 3月, 2011 5 次提交
  16. 26 2月, 2011 1 次提交
    • E
      Revert "selinux: simplify ioctl checking" · 0b24dcb7
      Eric Paris 提交于
      This reverts commit 242631c4.
      
      Conflicts:
      
      	security/selinux/hooks.c
      
      SELinux used to recognize certain individual ioctls and check
      permissions based on the knowledge of the individual ioctl.  In commit
      242631c4 the SELinux code stopped trying to understand
      individual ioctls and to instead looked at the ioctl access bits to
      determine in we should check read or write for that operation.  This
      same suggestion was made to SMACK (and I believe copied into TOMOYO).
      But this suggestion is total rubbish.  The ioctl access bits are
      actually the access requirements for the structure being passed into the
      ioctl, and are completely unrelated to the operation of the ioctl or the
      object the ioctl is being performed upon.
      
      Take FS_IOC_FIEMAP as an example.  FS_IOC_FIEMAP is defined as:
      
      FS_IOC_FIEMAP _IOWR('f', 11, struct fiemap)
      
      So it has access bits R and W.  What this really means is that the
      kernel is going to both read and write to the struct fiemap.  It has
      nothing at all to do with the operations that this ioctl might perform
      on the file itself!
      Signed-off-by: NEric Paris <eparis@redhat.com>
      Acked-by: NStephen Smalley <sds@tycho.nsa.gov>
      0b24dcb7