1. 03 Mar, 2011 1 commit
  2. 25 Feb, 2011 1 commit
  3. 28 Nov, 2010 1 commit
    • Serge E. Hallyn's avatar
      security: Define CAP_SYSLOG · ce6ada35
      Serge E. Hallyn authored
      Privileged syslog operations currently require CAP_SYS_ADMIN.  Split
      this off into a new CAP_SYSLOG privilege which we can sanely take away
      from a container through the capability bounding set.
      With this patch, an lxc container can be prevented from messing with
      the host's syslog (i.e. dmesg -c).
      Changelog: mar 12 2010: add selinux capability2:cap_syslog perm
      Changelog: nov 22 2010:
      	. port to new kernel
      	. add a WARN_ONCE if userspace isn't using CAP_SYSLOG
      Signed-off-by: default avatarSerge Hallyn <serge.hallyn@ubuntu.com>
      Acked-by: default avatarAndrew G. Morgan <morgan@kernel.org>
      Acked-By: default avatarKees Cook <kees.cook@canonical.com>
      Cc: James Morris <jmorris@namei.org>
      Cc: Michael Kerrisk <mtk.manpages@gmail.com>
      Cc: Stephen Smalley <sds@tycho.nsa.gov>
      Cc: "Christopher J. PeBenito" <cpebenito@tresys.com>
      Cc: Eric Paris <eparis@parisplace.org>
      Signed-off-by: default avatarJames Morris <jmorris@namei.org>
  4. 20 Oct, 2010 1 commit
  5. 02 Aug, 2010 3 commits
    • Eric Paris's avatar
      SELinux: Move execmod to the common perms · b424485a
      Eric Paris authored
      execmod "could" show up on non regular files and non chr files.  The current
      implementation would actually make these checks against non-existant bits
      since the code assumes the execmod permission is same for all file types.
      To make this line up for chr files we had to define execute_no_trans and
      entrypoint permissions.  These permissions are unreachable and only existed
      to to make FILE__EXECMOD and CHR_FILE__EXECMOD the same.  This patch drops
      those needless perms as well.
      Signed-off-by: default avatarEric Paris <eparis@redhat.com>
      Acked-by: default avatarStephen D. Smalley <sds@tycho.nsa.gov>
      Signed-off-by: default avatarJames Morris <jmorris@namei.org>
    • Eric Paris's avatar
      selinux: place open in the common file perms · 49b7b8de
      Eric Paris authored
      kernel can dynamically remap perms.  Drop the open lookup table and put open
      in the common file perms.
      Signed-off-by: default avatarEric Paris <eparis@redhat.com>
      Acked-by: default avatarStephen D. Smalley <sds@tycho.nsa.gov>
      Signed-off-by: default avatarJames Morris <jmorris@namei.org>
    • Eric Paris's avatar
      SELinux: special dontaudit for access checks · b782e0a6
      Eric Paris authored
      Currently there are a number of applications (nautilus being the main one) which
      calls access() on files in order to determine how they should be displayed.  It
      is normal and expected that nautilus will want to see if files are executable
      or if they are really read/write-able.  access() should return the real
      permission.  SELinux policy checks are done in access() and can result in lots
      of AVC denials as policy denies RWX on files which DAC allows.  Currently
      SELinux must dontaudit actual attempts to read/write/execute a file in
      order to silence these messages (and not flood the logs.)  But dontaudit rules
      like that can hide real attacks.  This patch addes a new common file
      permission audit_access.  This permission is special in that it is meaningless
      and should never show up in an allow rule.  Instead the only place this
      permission has meaning is in a dontaudit rule like so:
      dontaudit nautilus_t sbin_t:file audit_access
      With such a rule if nautilus just checks access() we will still get denied and
      thus userspace will still get the correct answer but we will not log the denial.
      If nautilus attempted to actually perform one of the forbidden actions
      (rather than just querying access(2) about it) we would still log a denial.
      This type of dontaudit rule should be used sparingly, as it could be a
      method for an attacker to probe the system permissions without detection.
      Signed-off-by: default avatarEric Paris <eparis@redhat.com>
      Acked-by: default avatarStephen D. Smalley <sds@tycho.nsa.gov>
      Signed-off-by: default avatarJames Morris <jmorris@namei.org>
  6. 07 Oct, 2009 1 commit
    • Stephen Smalley's avatar
      selinux: dynamic class/perm discovery · c6d3aaa4
      Stephen Smalley authored
      Modify SELinux to dynamically discover class and permission values
      upon policy load, based on the dynamic object class/perm discovery
      logic from libselinux.  A mapping is created between kernel-private
      class and permission indices used outside the security server and the
      policy values used within the security server.
      The mappings are only applied upon kernel-internal computations;
      similar mappings for the private indices of userspace object managers
      is handled on a per-object manager basis by the userspace AVC.  The
      interfaces for compute_av and transition_sid are split for kernel
      vs. userspace; the userspace functions are distinguished by a _user
      The kernel-private class indices are no longer tied to the policy
      values and thus do not need to skip indices for userspace classes;
      thus the kernel class index values are compressed.  The flask.h
      definitions were regenerated by deleting the userspace classes from
      refpolicy's definitions and then regenerating the headers.  Going
      forward, we can just maintain the flask.h, av_permissions.h, and
      classmap.h definitions separately from policy as they are no longer
      tied to the policy values.  The next patch introduces a utility to
      automate generation of flask.h and av_permissions.h from the
      classmap.h definitions.
      The older kernel class and permission string tables are removed and
      replaced by a single security class mapping table that is walked at
      policy load to generate the mapping.  The old kernel class validation
      logic is completely replaced by the mapping logic.
      The handle unknown logic is reworked.  reject_unknown=1 is handled
      when the mappings are computed at policy load time, similar to the old
      handling by the class validation logic.  allow_unknown=1 is handled
      when computing and mapping decisions - if the permission was not able
      to be mapped (i.e. undefined, mapped to zero), then it is
      automatically added to the allowed vector.  If the class was not able
      to be mapped (i.e. undefined, mapped to zero), then all permissions
      are allowed for it if allow_unknown=1.
      avc_audit leverages the new security class mapping table to lookup the
      class and permission names from the kernel-private indices.
      The mdp program is updated to use the new table when generating the
      class definitions and allow rules for a minimal boot policy for the
      kernel.  It should be noted that this policy will not include any
      userspace classes, nor will its policy index values for the kernel
      classes correspond with the ones in refpolicy (they will instead match
      the kernel-private indices).
      Signed-off-by: default avatarStephen Smalley <sds@tycho.nsa.gov>
      Signed-off-by: default avatarJames Morris <jmorris@namei.org>