1. 14 11月, 2008 4 次提交
    • D
      KEYS: Alter use of key instantiation link-to-keyring argument · 8bbf4976
      David Howells 提交于
      Alter the use of the key instantiation and negation functions' link-to-keyring
      arguments.  Currently this specifies a keyring in the target process to link
      the key into, creating the keyring if it doesn't exist.  This, however, can be
      a problem for copy-on-write credentials as it means that the instantiating
      process can alter the credentials of the requesting process.
      
      This patch alters the behaviour such that:
      
       (1) If keyctl_instantiate_key() or keyctl_negate_key() are given a specific
           keyring by ID (ringid >= 0), then that keyring will be used.
      
       (2) If keyctl_instantiate_key() or keyctl_negate_key() are given one of the
           special constants that refer to the requesting process's keyrings
           (KEY_SPEC_*_KEYRING, all <= 0), then:
      
           (a) If sys_request_key() was given a keyring to use (destringid) then the
           	 key will be attached to that keyring.
      
           (b) If sys_request_key() was given a NULL keyring, then the key being
           	 instantiated will be attached to the default keyring as set by
           	 keyctl_set_reqkey_keyring().
      
       (3) No extra link will be made.
      
      Decision point (1) follows current behaviour, and allows those instantiators
      who've searched for a specifically named keyring in the requestor's keyring so
      as to partition the keys by type to still have their named keyrings.
      
      Decision point (2) allows the requestor to make sure that the key or keys that
      get produced by request_key() go where they want, whilst allowing the
      instantiator to request that the key is retained.  This is mainly useful for
      situations where the instantiator makes a secondary request, the key for which
      should be retained by the initial requestor:
      
      	+-----------+        +--------------+        +--------------+
      	|           |        |              |        |              |
      	| Requestor |------->| Instantiator |------->| Instantiator |
      	|           |        |              |        |              |
      	+-----------+        +--------------+        +--------------+
      	           request_key()           request_key()
      
      This might be useful, for example, in Kerberos, where the requestor requests a
      ticket, and then the ticket instantiator requests the TGT, which someone else
      then has to go and fetch.  The TGT, however, should be retained in the
      keyrings of the requestor, not the first instantiator.  To make this explict
      an extra special keyring constant is also added.
      Signed-off-by: NDavid Howells <dhowells@redhat.com>
      Reviewed-by: NJames Morris <jmorris@namei.org>
      Signed-off-by: NJames Morris <jmorris@namei.org>
      8bbf4976
    • D
      KEYS: Disperse linux/key_ui.h · e9e349b0
      David Howells 提交于
      Disperse the bits of linux/key_ui.h as the reason they were put here (keyfs)
      didn't get in.
      Signed-off-by: NDavid Howells <dhowells@redhat.com>
      Reviewed-by: NJames Morris <jmorris@namei.org>
      Signed-off-by: NJames Morris <jmorris@namei.org>
      e9e349b0
    • D
      CRED: Wrap task credential accesses in the capabilities code · b103c598
      David Howells 提交于
      Wrap access to task credentials so that they can be separated more easily from
      the task_struct during the introduction of COW creds.
      
      Change most current->(|e|s|fs)[ug]id to current_(|e|s|fs)[ug]id().
      
      Change some task->e?[ug]id to task_e?[ug]id().  In some places it makes more
      sense to use RCU directly rather than a convenient wrapper; these will be
      addressed by later patches.
      Signed-off-by: NDavid Howells <dhowells@redhat.com>
      Reviewed-by: NJames Morris <jmorris@namei.org>
      Acked-by: NSerge Hallyn <serue@us.ibm.com>
      Cc: Andrew G. Morgan <morgan@kernel.org>
      Signed-off-by: NJames Morris <jmorris@namei.org>
      b103c598
    • D
      CRED: Wrap task credential accesses in the key management code · 47d804bf
      David Howells 提交于
      Wrap access to task credentials so that they can be separated more easily from
      the task_struct during the introduction of COW creds.
      
      Change most current->(|e|s|fs)[ug]id to current_(|e|s|fs)[ug]id().
      
      Change some task->e?[ug]id to task_e?[ug]id().  In some places it makes more
      sense to use RCU directly rather than a convenient wrapper; these will be
      addressed by later patches.
      Signed-off-by: NDavid Howells <dhowells@redhat.com>
      Reviewed-by: NJames Morris <jmorris@namei.org>
      Acked-by: NSerge Hallyn <serue@us.ibm.com>
      Signed-off-by: NJames Morris <jmorris@namei.org>
      47d804bf
  2. 11 11月, 2008 4 次提交
    • E
      Currently SELinux jumps through some ugly hoops to not audit a capbility · 06674679
      Eric Paris 提交于
      check when determining if a process has additional powers to override
      memory limits or when trying to read/write illegal file labels.  Use
      the new noaudit call instead.
      Signed-off-by: NEric Paris <eparis@redhat.com>
      Acked-by: NStephen Smalley <sds@tycho.nsa.gov>
      Signed-off-by: NJames Morris <jmorris@namei.org>
      06674679
    • E
      Add a new capable interface that will be used by systems that use audit to · 06112163
      Eric Paris 提交于
      make an A or B type decision instead of a security decision.  Currently
      this is the case at least for filesystems when deciding if a process can use
      the reserved 'root' blocks and for the case of things like the oom
      algorithm determining if processes are root processes and should be less
      likely to be killed.  These types of security system requests should not be
      audited or logged since they are not really security decisions.  It would be
      possible to solve this problem like the vm_enough_memory security check did
      by creating a new LSM interface and moving all of the policy into that
      interface but proves the needlessly bloat the LSM and provide complex
      indirection.
      
      This merely allows those decisions to be made where they belong and to not
      flood logs or printk with denials for thing that are not security decisions.
      Signed-off-by: NEric Paris <eparis@redhat.com>
      Acked-by: NStephen Smalley <sds@tycho.nsa.gov>
      Signed-off-by: NJames Morris <jmorris@namei.org>
      06112163
    • E
      Any time fcaps or a setuid app under SECURE_NOROOT is used to result in a · 3fc689e9
      Eric Paris 提交于
      non-zero pE we will crate a new audit record which contains the entire set
      of known information about the executable in question, fP, fI, fE, fversion
      and includes the process's pE, pI, pP.  Before and after the bprm capability
      are applied.  This record type will only be emitted from execve syscalls.
      
      an example of making ping use fcaps instead of setuid:
      
      setcap "cat_net_raw+pe" /bin/ping
      
      type=SYSCALL msg=audit(1225742021.015:236): arch=c000003e syscall=59 success=yes exit=0 a0=1457f30 a1=14606b0 a2=1463940 a3=321b770a70 items=2 ppid=2929 pid=2963 auid=0 uid=500 gid=500 euid=500 suid=500 fsuid=500 egid=500 sgid=500 fsgid=500 tty=pts0 ses=3 comm="ping" exe="/bin/ping" subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 key=(null)
      type=UNKNOWN[1321] msg=audit(1225742021.015:236): fver=2 fp=0000000000002000 fi=0000000000000000 fe=1 old_pp=0000000000000000 old_pi=0000000000000000 old_pe=0000000000000000 new_pp=0000000000002000 new_pi=0000000000000000 new_pe=0000000000002000
      type=EXECVE msg=audit(1225742021.015:236): argc=2 a0="ping" a1="127.0.0.1"
      type=CWD msg=audit(1225742021.015:236):  cwd="/home/test"
      type=PATH msg=audit(1225742021.015:236): item=0 name="/bin/ping" inode=49256 dev=fd:00 mode=0100755 ouid=0 ogid=0 rdev=00:00 obj=system_u:object_r:ping_exec_t:s0 cap_fp=0000000000002000 cap_fe=1 cap_fver=2
      type=PATH msg=audit(1225742021.015:236): item=1 name=(null) inode=507915 dev=fd:00 mode=0100755 ouid=0 ogid=0 rdev=00:00 obj=system_u:object_r:ld_so_t:s0
      Signed-off-by: NEric Paris <eparis@redhat.com>
      Acked-by: NSerge Hallyn <serue@us.ibm.com>
      Signed-off-by: NJames Morris <jmorris@namei.org>
      3fc689e9
    • E
      This patch add a generic cpu endian caps structure and externally available · c0b00441
      Eric Paris 提交于
      functions which retrieve fcaps information from disk.  This information is
      necessary so fcaps information can be collected and recorded by the audit
      system.
      Signed-off-by: NEric Paris <eparis@redhat.com>
      Acked-by: NSerge Hallyn <serue@us.ibm.com>
      Signed-off-by: NJames Morris <jmorris@namei.org>
      c0b00441
  3. 09 11月, 2008 1 次提交
  4. 06 11月, 2008 2 次提交
    • S
      file capabilities: add no_file_caps switch (v4) · 1f29fae2
      Serge E. Hallyn 提交于
      Add a no_file_caps boot option when file capabilities are
      compiled into the kernel (CONFIG_SECURITY_FILE_CAPABILITIES=y).
      
      This allows distributions to ship a kernel with file capabilities
      compiled in, without forcing users to use (and understand and
      trust) them.
      
      When no_file_caps is specified at boot, then when a process executes
      a file, any file capabilities stored with that file will not be
      used in the calculation of the process' new capability sets.
      
      This means that booting with the no_file_caps boot option will
      not be the same as booting a kernel with file capabilities
      compiled out - in particular a task with  CAP_SETPCAP will not
      have any chance of passing capabilities to another task (which
      isn't "really" possible anyway, and which may soon by killed
      altogether by David Howells in any case), and it will instead
      be able to put new capabilities in its pI.  However since fI
      will always be empty and pI is masked with fI, it gains the
      task nothing.
      
      We also support the extra prctl options, setting securebits and
      dropping capabilities from the per-process bounding set.
      
      The other remaining difference is that killpriv, task_setscheduler,
      setioprio, and setnice will continue to be hooked.  That will
      be noticable in the case where a root task changed its uid
      while keeping some caps, and another task owned by the new uid
      tries to change settings for the more privileged task.
      
      Changelog:
      	Nov 05 2008: (v4) trivial port on top of always-start-\
      		with-clear-caps patch
      	Sep 23 2008: nixed file_caps_enabled when file caps are
      		not compiled in as it isn't used.
      		Document no_file_caps in kernel-parameters.txt.
      Signed-off-by: NSerge Hallyn <serue@us.ibm.com>
      Acked-by: NAndrew G. Morgan <morgan@kernel.org>
      Signed-off-by: NJames Morris <jmorris@namei.org>
      1f29fae2
    • M
      selinux: recognize netlink messages for 'ip addrlabel' · 2f99db28
      Michal Schmidt 提交于
      In enforcing mode '/sbin/ip addrlabel' results in a SELinux error:
      type=SELINUX_ERR msg=audit(1225698822.073:42): SELinux:  unrecognized
      netlink message type=74 for sclass=43
      
      The problem is missing RTM_*ADDRLABEL entries in SELinux's netlink
      message types table.
      
      Reported in https://bugzilla.redhat.com/show_bug.cgi?id=469423Signed-off-by: NMichal Schmidt <mschmidt@redhat.com>
      Acked-by: NStephen Smalley <sds@tycho.nsa.gov>
      Signed-off-by: NJames Morris <jmorris@namei.org>
      2f99db28
  5. 05 11月, 2008 1 次提交
  6. 02 11月, 2008 1 次提交
  7. 01 11月, 2008 1 次提交
  8. 31 10月, 2008 1 次提交
  9. 30 10月, 2008 1 次提交
  10. 20 10月, 2008 3 次提交
  11. 14 10月, 2008 3 次提交
  12. 13 10月, 2008 1 次提交
  13. 10 10月, 2008 11 次提交
  14. 04 10月, 2008 2 次提交
    • P
      selinux: Fix an uninitialized variable BUG/panic in selinux_secattr_to_sid() · 3040a6d5
      Paul Moore 提交于
      At some point during the 2.6.27 development cycle two new fields were added
      to the SELinux context structure, a string pointer and a length field.  The
      code in selinux_secattr_to_sid() was not modified and as a result these two
      fields were left uninitialized which could result in erratic behavior,
      including kernel panics, when NetLabel is used.  This patch fixes the
      problem by fully initializing the context in selinux_secattr_to_sid() before
      use and reducing the level of direct context manipulation done to help
      prevent future problems.
      
      Please apply this to the 2.6.27-rcX release stream.
      Signed-off-by: NPaul Moore <paul.moore@hp.com>
      Signed-off-by: NJames Morris <jmorris@namei.org>
      3040a6d5
    • P
      selinux: Fix an uninitialized variable BUG/panic in selinux_secattr_to_sid() · 81990fbd
      Paul Moore 提交于
      At some point during the 2.6.27 development cycle two new fields were added
      to the SELinux context structure, a string pointer and a length field.  The
      code in selinux_secattr_to_sid() was not modified and as a result these two
      fields were left uninitialized which could result in erratic behavior,
      including kernel panics, when NetLabel is used.  This patch fixes the
      problem by fully initializing the context in selinux_secattr_to_sid() before
      use and reducing the level of direct context manipulation done to help
      prevent future problems.
      
      Please apply this to the 2.6.27-rcX release stream.
      Signed-off-by: NPaul Moore <paul.moore@hp.com>
      Signed-off-by: NJames Morris <jmorris@namei.org>
      81990fbd
  15. 29 9月, 2008 1 次提交
    • S
      selinux: use default proc sid on symlinks · ea6b184f
      Stephen Smalley 提交于
      As we are not concerned with fine-grained control over reading of
      symlinks in proc, always use the default proc SID for all proc symlinks.
      This should help avoid permission issues upon changes to the proc tree
      as in the /proc/net -> /proc/self/net example.
      This does not alter labeling of symlinks within /proc/pid directories.
      ls -Zd /proc/net output before and after the patch should show the difference.
      Signed-off-by: NStephen D. Smalley <sds@tycho.nsa.gov>
      Signed-off-by: NJames Morris <jmorris@namei.org>
      ea6b184f
  16. 27 9月, 2008 1 次提交
  17. 14 9月, 2008 1 次提交
    • F
      timers: fix itimer/many thread hang · f06febc9
      Frank Mayhar 提交于
      Overview
      
      This patch reworks the handling of POSIX CPU timers, including the
      ITIMER_PROF, ITIMER_VIRT timers and rlimit handling.  It was put together
      with the help of Roland McGrath, the owner and original writer of this code.
      
      The problem we ran into, and the reason for this rework, has to do with using
      a profiling timer in a process with a large number of threads.  It appears
      that the performance of the old implementation of run_posix_cpu_timers() was
      at least O(n*3) (where "n" is the number of threads in a process) or worse.
      Everything is fine with an increasing number of threads until the time taken
      for that routine to run becomes the same as or greater than the tick time, at
      which point things degrade rather quickly.
      
      This patch fixes bug 9906, "Weird hang with NPTL and SIGPROF."
      
      Code Changes
      
      This rework corrects the implementation of run_posix_cpu_timers() to make it
      run in constant time for a particular machine.  (Performance may vary between
      one machine and another depending upon whether the kernel is built as single-
      or multiprocessor and, in the latter case, depending upon the number of
      running processors.)  To do this, at each tick we now update fields in
      signal_struct as well as task_struct.  The run_posix_cpu_timers() function
      uses those fields to make its decisions.
      
      We define a new structure, "task_cputime," to contain user, system and
      scheduler times and use these in appropriate places:
      
      struct task_cputime {
      	cputime_t utime;
      	cputime_t stime;
      	unsigned long long sum_exec_runtime;
      };
      
      This is included in the structure "thread_group_cputime," which is a new
      substructure of signal_struct and which varies for uniprocessor versus
      multiprocessor kernels.  For uniprocessor kernels, it uses "task_cputime" as
      a simple substructure, while for multiprocessor kernels it is a pointer:
      
      struct thread_group_cputime {
      	struct task_cputime totals;
      };
      
      struct thread_group_cputime {
      	struct task_cputime *totals;
      };
      
      We also add a new task_cputime substructure directly to signal_struct, to
      cache the earliest expiration of process-wide timers, and task_cputime also
      replaces the it_*_expires fields of task_struct (used for earliest expiration
      of thread timers).  The "thread_group_cputime" structure contains process-wide
      timers that are updated via account_user_time() and friends.  In the non-SMP
      case the structure is a simple aggregator; unfortunately in the SMP case that
      simplicity was not achievable due to cache-line contention between CPUs (in
      one measured case performance was actually _worse_ on a 16-cpu system than
      the same test on a 4-cpu system, due to this contention).  For SMP, the
      thread_group_cputime counters are maintained as a per-cpu structure allocated
      using alloc_percpu().  The timer functions update only the timer field in
      the structure corresponding to the running CPU, obtained using per_cpu_ptr().
      
      We define a set of inline functions in sched.h that we use to maintain the
      thread_group_cputime structure and hide the differences between UP and SMP
      implementations from the rest of the kernel.  The thread_group_cputime_init()
      function initializes the thread_group_cputime structure for the given task.
      The thread_group_cputime_alloc() is a no-op for UP; for SMP it calls the
      out-of-line function thread_group_cputime_alloc_smp() to allocate and fill
      in the per-cpu structures and fields.  The thread_group_cputime_free()
      function, also a no-op for UP, in SMP frees the per-cpu structures.  The
      thread_group_cputime_clone_thread() function (also a UP no-op) for SMP calls
      thread_group_cputime_alloc() if the per-cpu structures haven't yet been
      allocated.  The thread_group_cputime() function fills the task_cputime
      structure it is passed with the contents of the thread_group_cputime fields;
      in UP it's that simple but in SMP it must also safely check that tsk->signal
      is non-NULL (if it is it just uses the appropriate fields of task_struct) and,
      if so, sums the per-cpu values for each online CPU.  Finally, the three
      functions account_group_user_time(), account_group_system_time() and
      account_group_exec_runtime() are used by timer functions to update the
      respective fields of the thread_group_cputime structure.
      
      Non-SMP operation is trivial and will not be mentioned further.
      
      The per-cpu structure is always allocated when a task creates its first new
      thread, via a call to thread_group_cputime_clone_thread() from copy_signal().
      It is freed at process exit via a call to thread_group_cputime_free() from
      cleanup_signal().
      
      All functions that formerly summed utime/stime/sum_sched_runtime values from
      from all threads in the thread group now use thread_group_cputime() to
      snapshot the values in the thread_group_cputime structure or the values in
      the task structure itself if the per-cpu structure hasn't been allocated.
      
      Finally, the code in kernel/posix-cpu-timers.c has changed quite a bit.
      The run_posix_cpu_timers() function has been split into a fast path and a
      slow path; the former safely checks whether there are any expired thread
      timers and, if not, just returns, while the slow path does the heavy lifting.
      With the dedicated thread group fields, timers are no longer "rebalanced" and
      the process_timer_rebalance() function and related code has gone away.  All
      summing loops are gone and all code that used them now uses the
      thread_group_cputime() inline.  When process-wide timers are set, the new
      task_cputime structure in signal_struct is used to cache the earliest
      expiration; this is checked in the fast path.
      
      Performance
      
      The fix appears not to add significant overhead to existing operations.  It
      generally performs the same as the current code except in two cases, one in
      which it performs slightly worse (Case 5 below) and one in which it performs
      very significantly better (Case 2 below).  Overall it's a wash except in those
      two cases.
      
      I've since done somewhat more involved testing on a dual-core Opteron system.
      
      Case 1: With no itimer running, for a test with 100,000 threads, the fixed
      	kernel took 1428.5 seconds, 513 seconds more than the unfixed system,
      	all of which was spent in the system.  There were twice as many
      	voluntary context switches with the fix as without it.
      
      Case 2: With an itimer running at .01 second ticks and 4000 threads (the most
      	an unmodified kernel can handle), the fixed kernel ran the test in
      	eight percent of the time (5.8 seconds as opposed to 70 seconds) and
      	had better tick accuracy (.012 seconds per tick as opposed to .023
      	seconds per tick).
      
      Case 3: A 4000-thread test with an initial timer tick of .01 second and an
      	interval of 10,000 seconds (i.e. a timer that ticks only once) had
      	very nearly the same performance in both cases:  6.3 seconds elapsed
      	for the fixed kernel versus 5.5 seconds for the unfixed kernel.
      
      With fewer threads (eight in these tests), the Case 1 test ran in essentially
      the same time on both the modified and unmodified kernels (5.2 seconds versus
      5.8 seconds).  The Case 2 test ran in about the same time as well, 5.9 seconds
      versus 5.4 seconds but again with much better tick accuracy, .013 seconds per
      tick versus .025 seconds per tick for the unmodified kernel.
      
      Since the fix affected the rlimit code, I also tested soft and hard CPU limits.
      
      Case 4: With a hard CPU limit of 20 seconds and eight threads (and an itimer
      	running), the modified kernel was very slightly favored in that while
      	it killed the process in 19.997 seconds of CPU time (5.002 seconds of
      	wall time), only .003 seconds of that was system time, the rest was
      	user time.  The unmodified kernel killed the process in 20.001 seconds
      	of CPU (5.014 seconds of wall time) of which .016 seconds was system
      	time.  Really, though, the results were too close to call.  The results
      	were essentially the same with no itimer running.
      
      Case 5: With a soft limit of 20 seconds and a hard limit of 2000 seconds
      	(where the hard limit would never be reached) and an itimer running,
      	the modified kernel exhibited worse tick accuracy than the unmodified
      	kernel: .050 seconds/tick versus .028 seconds/tick.  Otherwise,
      	performance was almost indistinguishable.  With no itimer running this
      	test exhibited virtually identical behavior and times in both cases.
      
      In times past I did some limited performance testing.  those results are below.
      
      On a four-cpu Opteron system without this fix, a sixteen-thread test executed
      in 3569.991 seconds, of which user was 3568.435s and system was 1.556s.  On
      the same system with the fix, user and elapsed time were about the same, but
      system time dropped to 0.007 seconds.  Performance with eight, four and one
      thread were comparable.  Interestingly, the timer ticks with the fix seemed
      more accurate:  The sixteen-thread test with the fix received 149543 ticks
      for 0.024 seconds per tick, while the same test without the fix received 58720
      for 0.061 seconds per tick.  Both cases were configured for an interval of
      0.01 seconds.  Again, the other tests were comparable.  Each thread in this
      test computed the primes up to 25,000,000.
      
      I also did a test with a large number of threads, 100,000 threads, which is
      impossible without the fix.  In this case each thread computed the primes only
      up to 10,000 (to make the runtime manageable).  System time dominated, at
      1546.968 seconds out of a total 2176.906 seconds (giving a user time of
      629.938s).  It received 147651 ticks for 0.015 seconds per tick, still quite
      accurate.  There is obviously no comparable test without the fix.
      Signed-off-by: NFrank Mayhar <fmayhar@google.com>
      Cc: Roland McGrath <roland@redhat.com>
      Cc: Alexey Dobriyan <adobriyan@gmail.com>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      f06febc9
  18. 11 9月, 2008 1 次提交