Skip to content

R
raspberrypi-kernel

openeuler / raspberrypi-kernel

通知 13
Star 1
Fork 0
R
raspberrypi-kernel
切换分支/标签
  1. 10 4月, 2012 5 次提交
    • E
      SELinux: remove inode_has_perm_noadp · 602a8dd6
      由 Eric Paris 提交于 
      Both callers could better be using file_has_perm() to get better audit
results.
Signed-off-by: NEric Paris <eparis@redhat.com>
      602a8dd6
    • E
      SELinux: delay initialization of audit data in selinux_inode_permission · 2e334057
      由 Eric Paris 提交于 
      We pay a rather large overhead initializing the common_audit_data.
Since we only need this information if we actually emit an audit
message there is little need to set it up in the hot path.  This patch
splits the functionality of avc_has_perm() into avc_has_perm_noaudit(),
avc_audit_required() and slow_avc_audit().  But we take care of setting
up to audit between required() and the actual audit call.  Thus saving
measurable time in a hot path.
Signed-off-by: NStephen Smalley <sds@tycho.nsa.gov>
Signed-off-by: NEric Paris <eparis@redhat.com>
      2e334057
    • E
      SELinux: audit failed attempts to set invalid labels · d6ea83ec
      由 Eric Paris 提交于 
      We know that some yum operation is causing CAP_MAC_ADMIN failures.  This
implies that an RPM is laying down (or attempting to lay down) a file with
an invalid label.  The problem is that we don't have any information to
track down the cause.  This patch will cause such a failure to report the
failed label in an SELINUX_ERR audit message.  This is similar to the
SELINUX_ERR reports on invalid transitions and things like that.  It should
help run down problems on what is trying to set invalid labels in the
future.

Resulting records look something like:
type=AVC msg=audit(1319659241.138:71): avc:  denied  { mac_admin } for pid=2594 comm="chcon" capability=33 scontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tclass=capability2
type=SELINUX_ERR msg=audit(1319659241.138:71): op=setxattr invalid_context=unconfined_u:object_r:hello:s0
type=SYSCALL msg=audit(1319659241.138:71): arch=c000003e syscall=188 success=no exit=-22 a0=a2c0e0 a1=390341b79b a2=a2d620 a3=1f items=1 ppid=2519 pid=2594 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0 ses=1 comm="chcon" exe="/usr/bin/chcon" subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 key=(null)
type=CWD msg=audit(1319659241.138:71):  cwd="/root" type=PATH msg=audit(1319659241.138:71): item=0 name="test" inode=785879 dev=fc:03 mode=0100644 ouid=0 ogid=0 rdev=00:00 obj=unconfined_u:object_r:admin_home_t:s0
Signed-off-by: NEric Paris <eparis@redhat.com>
      d6ea83ec
    • E
      SELinux: rename dentry_open to file_open · 83d49856
      由 Eric Paris 提交于 
      dentry_open takes a file, rename it to file_open
Signed-off-by: NEric Paris <eparis@redhat.com>
      83d49856
    • E
      SELinux: check OPEN on truncate calls · 95dbf739
      由 Eric Paris 提交于 
      In RH BZ 578841 we realized that the SELinux sandbox program was allowed to
truncate files outside of the sandbox.  The reason is because sandbox
confinement is determined almost entirely by the 'open' permission.  The idea
was that if the sandbox was unable to open() files it would be unable to do
harm to those files.  This turns out to be false in light of syscalls like
truncate() and chmod() which don't require a previous open() call.  I looked
at the syscalls that did not have an associated 'open' check and found that
truncate(), did not have a seperate permission and even if it did have a
separate permission such a permission owuld be inadequate for use by
sandbox (since it owuld have to be granted so liberally as to be useless).
This patch checks the OPEN permission on truncate.  I think a better solution
for sandbox is a whole new permission, but at least this fixes what we have
today.
Signed-off-by: NEric Paris <eparis@redhat.com>
      95dbf739
  3. 04 4月, 2012 2 次提交
    • E
      LSM: shrink the common_audit_data data union · 48c62af6
      由 Eric Paris 提交于 
      After shrinking the common_audit_data stack usage for private LSM data I'm
not going to shrink the data union.  To do this I'm going to move anything
larger than 2 void * ptrs to it's own structure and require it to be declared
separately on the calling stack.  Thus hot paths which don't need more than
a couple pointer don't have to declare space to hold large unneeded
structures.  I could get this down to one void * by dealing with the key
struct and the struct path.  We'll see if that is helpful after taking care of
networking.
Signed-off-by: NEric Paris <eparis@redhat.com>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      48c62af6
    • E
      LSM: shrink sizeof LSM specific portion of common_audit_data · 3b3b0e4f
      由 Eric Paris 提交于 
      Linus found that the gigantic size of the common audit data caused a big
perf hit on something as simple as running stat() in a loop.  This patch
requires LSMs to declare the LSM specific portion separately rather than
doing it in a union.  Thus each LSM can be responsible for shrinking their
portion and don't have to pay a penalty just because other LSMs have a
bigger space requirement.
Signed-off-by: NEric Paris <eparis@redhat.com>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      3b3b0e4f
  5. 01 4月, 2012 1 次提交
  7. 20 2月, 2012 1 次提交
    • D
      Replace the fd_sets in struct fdtable with an array of unsigned longs · 1fd36adc
      由 David Howells 提交于 
      Replace the fd_sets in struct fdtable with an array of unsigned longs and then
use the standard non-atomic bit operations rather than the FD_* macros.

This:

 (1) Removes the abuses of struct fd_set:

     (a) Since we don't want to allocate a full fd_set the vast majority of the
     	 time, we actually, in effect, just allocate a just-big-enough array of
     	 unsigned longs and cast it to an fd_set type - so why bother with the
     	 fd_set at all?

     (b) Some places outside of the core fdtable handling code (such as
     	 SELinux) want to look inside the array of unsigned longs hidden inside
     	 the fd_set struct for more efficient iteration over the entire set.

 (2) Eliminates the use of FD_*() macros in the kernel completely.

 (3) Permits the __FD_*() macros to be deleted entirely where not exposed to
     userspace.
Signed-off-by: NDavid Howells <dhowells@redhat.com>
Link: http://lkml.kernel.org/r/20120216174954.23314.48147.stgit@warthog.procyon.org.ukSigned-off-by: NH. Peter Anvin <hpa@zytor.com>
Cc: Al Viro <viro@zeniv.linux.org.uk>
      1fd36adc
  9. 14 2月, 2012 1 次提交
  11. 07 1月, 2012 1 次提交
  13. 06 1月, 2012 7 次提交
  15. 04 1月, 2012 4 次提交
  17. 07 12月, 2011 1 次提交
  19. 04 12月, 2011 1 次提交
  21. 23 11月, 2011 1 次提交
  23. 01 11月, 2011 1 次提交
  25. 10 9月, 2011 4 次提交
  27. 02 8月, 2011 2 次提交
  29. 27 7月, 2011 1 次提交
  31. 20 7月, 2011 2 次提交
  33. 23 6月, 2011 1 次提交
  35. 09 6月, 2011 1 次提交
    • L
      selinux: simplify and clean up inode_has_perm() · 95f4efb2
      由 Linus Torvalds 提交于 
      This is a rather hot function that is called with a potentially NULL
"struct common_audit_data" pointer argument.  And in that case it has to
provide and initialize its own dummy common_audit_data structure.

However, all the _common_ cases already pass it a real audit-data
structure, so that uncommon NULL case not only creates a silly run-time
test, more importantly it causes that function to have a big stack frame
for the dummy variable that isn't even used in the common case!

So get rid of that stupid run-time behavior, and make the (few)
functions that currently call with a NULL pointer just call a new helper
function instead (naturally called inode_has_perm_noapd(), since it has
no adp argument).

This makes the run-time test be a static code generation issue instead,
and allows for a much denser stack since none of the common callers need
the dummy structure.  And a denser stack not only means less stack space
usage, it means better cache behavior.  So we have a win-win-win from
this simplification: less code executed, smaller stack footprint, and
better cache behavior.
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      95f4efb2
  37. 29 4月, 2011 3 次提交
    • E
      SELinux: pass last path component in may_create · cb1e922f
      由 Eric Paris 提交于 
      New inodes are created in a two stage process.  We first will compute the
label on a new inode in security_inode_create() and check if the
operation is allowed.  We will then actually re-compute that same label and
apply it in security_inode_init_security().  The change to do new label
calculations based in part on the last component of the path name only
passed the path component information all the way down the
security_inode_init_security hook.  Down the security_inode_create hook the
path information did not make it past may_create.  Thus the two calculations
came up differently and the permissions check might not actually be against
the label that is created.  Pass and use the same information in both places
to harmonize the calculations and checks.
Reported-by: NDominick Grift <domg472@gmail.com>
Signed-off-by: NEric Paris <eparis@redhat.com>
      cb1e922f
    • E
      SELinux: introduce path_has_perm · 2875fa00
      由 Eric Paris 提交于 
      We currently have inode_has_perm and dentry_has_perm.  dentry_has_perm just
calls inode_has_perm with additional audit data.  But dentry_has_perm can
take either a dentry or a path.  Split those to make the code obvious and
to fix the previous problem where I thought dentry_has_perm always had a
valid dentry and mnt.
Signed-off-by: NEric Paris <eparis@redhat.com>
      2875fa00
    • E
      SELinux: pass last path component in may_create · 562abf62
      由 Eric Paris 提交于 
      New inodes are created in a two stage process.  We first will compute the
label on a new inode in security_inode_create() and check if the
operation is allowed.  We will then actually re-compute that same label and
apply it in security_inode_init_security().  The change to do new label
calculations based in part on the last component of the path name only
passed the path component information all the way down the
security_inode_init_security hook.  Down the security_inode_create hook the
path information did not make it past may_create.  Thus the two calculations
came up differently and the permissions check might not actually be against
the label that is created.  Pass and use the same information in both places
to harmonize the calculations and checks.
Reported-by: NDominick Grift <domg472@gmail.com>
Signed-off-by: NEric Paris <eparis@redhat.com>
      562abf62