“0d63c27d9e879a0b54eb405636d60ab12040ca46”上不存在“README.md”
  1. 13 11月, 2020 1 次提交
  2. 30 10月, 2020 1 次提交
  3. 18 10月, 2020 1 次提交
    • J
      task_work: cleanup notification modes · 91989c70
      Jens Axboe 提交于
      A previous commit changed the notification mode from true/false to an
      int, allowing notify-no, notify-yes, or signal-notify. This was
      backwards compatible in the sense that any existing true/false user
      would translate to either 0 (on notification sent) or 1, the latter
      which mapped to TWA_RESUME. TWA_SIGNAL was assigned a value of 2.
      
      Clean this up properly, and define a proper enum for the notification
      mode. Now we have:
      
      - TWA_NONE. This is 0, same as before the original change, meaning no
        notification requested.
      - TWA_RESUME. This is 1, same as before the original change, meaning
        that we use TIF_NOTIFY_RESUME.
      - TWA_SIGNAL. This uses TIF_SIGPENDING/JOBCTL_TASK_WORK for the
        notification.
      
      Clean up all the callers, switching their 0/1/false/true to using the
      appropriate TWA_* mode for notifications.
      
      Fixes: e91b4816 ("task_work: teach task_work_add() to do signal_wake_up()")
      Reviewed-by: NThomas Gleixner <tglx@linutronix.de>
      Signed-off-by: NJens Axboe <axboe@kernel.dk>
      91989c70
  4. 14 10月, 2020 2 次提交
  5. 12 10月, 2020 1 次提交
    • T
      tomoyo: Loosen pathname/domainname validation. · a2075167
      Tetsuo Handa 提交于
      Since commit e2dc9bf3 ("umd: Transform fork_usermode_blob into
      fork_usermode_driver") started calling execve() on a program written in
      a local mount which is not connected to mount tree,
      tomoyo_realpath_from_path() started returning a pathname in
      "$fsname:/$pathname" format which violates TOMOYO's domainname rule that
      it must start with "<$namespace>" followed by zero or more repetitions of
      pathnames which start with '/'.
      
      Since $fsname must not contain '.' since commit 79c0b2df ("add
      filesystem subtype support"), tomoyo_correct_path() can recognize a token
      which appears '/' before '.' appears (e.g. proc:/self/exe ) as a pathname
      while rejecting a token which appears '.' before '/' appears (e.g.
      exec.realpath="/bin/bash" ) as a condition parameter.
      
      Therefore, accept domainnames which contain pathnames which do not start
      with '/' but contain '/' before '.' (e.g. <kernel> tmpfs:/bpfilter_umh ).
      Signed-off-by: NTetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
      a2075167
  6. 06 10月, 2020 1 次提交
  7. 05 10月, 2020 10 次提交
  8. 03 10月, 2020 2 次提交
  9. 25 9月, 2020 1 次提交
  10. 23 9月, 2020 1 次提交
  11. 17 9月, 2020 1 次提交
    • K
      ima: Fix NULL pointer dereference in ima_file_hash · aa662fc0
      KP Singh 提交于
      ima_file_hash can be called when there is no iint->ima_hash available
      even though the inode exists in the integrity cache. It is fairly
      common for a file to not have a hash. (e.g. an mknodat, prior to the
      file being closed).
      
      Another example where this can happen (suggested by Jann Horn):
      
      Process A does:
      
      	while(1) {
      		unlink("/tmp/imafoo");
      		fd = open("/tmp/imafoo", O_RDWR|O_CREAT|O_TRUNC, 0700);
      		if (fd == -1) {
      			perror("open");
      			continue;
      		}
      		write(fd, "A", 1);
      		close(fd);
      	}
      
      and Process B does:
      
      	while (1) {
      		int fd = open("/tmp/imafoo", O_RDONLY);
      		if (fd == -1)
      			continue;
          		char *mapping = mmap(NULL, 0x1000, PROT_READ|PROT_EXEC,
      			 	     MAP_PRIVATE, fd, 0);
      		if (mapping != MAP_FAILED)
      			munmap(mapping, 0x1000);
      		close(fd);
        	}
      
      Due to the race to get the iint->mutex between ima_file_hash and
      process_measurement iint->ima_hash could still be NULL.
      
      Fixes: 6beea7af ("ima: add the ability to query the cached hash of a given file")
      Signed-off-by: NKP Singh <kpsingh@google.com>
      Reviewed-by: NFlorent Revest <revest@chromium.org>
      Signed-off-by: NMimi Zohar <zohar@linux.ibm.com>
      aa662fc0
  12. 16 9月, 2020 6 次提交
  13. 15 9月, 2020 1 次提交
  14. 12 9月, 2020 3 次提交
  15. 11 9月, 2020 1 次提交
  16. 10 9月, 2020 2 次提交
  17. 09 9月, 2020 2 次提交
  18. 01 9月, 2020 3 次提交
    • D
      integrity: Use current_uid() in integrity_audit_message() · e44f1287
      Denis Efremov 提交于
      Modify integrity_audit_message() to use current_uid().
      Signed-off-by: NDenis Efremov <efremov@linux.com>
      Signed-off-by: NMimi Zohar <zohar@linux.ibm.com>
      e44f1287
    • T
      ima: Fail rule parsing when asymmetric key measurement isn't supportable · 48ce1ddc
      Tyler Hicks 提交于
      Measuring keys is currently only supported for asymmetric keys. In the
      future, this might change.
      
      For now, the "func=KEY_CHECK" and "keyrings=" options are only
      appropriate when CONFIG_IMA_MEASURE_ASYMMETRIC_KEYS is enabled. Make
      this clear at policy load so that IMA policy authors don't assume that
      these policy language constructs are supported.
      
      Fixes: 2b60c0ec ("IMA: Read keyrings= option from the IMA policy")
      Fixes: 5808611c ("IMA: Add KEY_CHECK func to measure keys")
      Suggested-by: NNayna Jain <nayna@linux.ibm.com>
      Signed-off-by: NTyler Hicks <tyhicks@linux.microsoft.com>
      Reviewed-by: NLakshmi Ramasubramanian <nramas@linux.microsoft.com>
      Reviewed-by: NNayna Jain <nayna@linux.ibm.com>
      Signed-off-by: NMimi Zohar <zohar@linux.ibm.com>
      48ce1ddc
    • T
      ima: Pre-parse the list of keyrings in a KEY_CHECK rule · 176377d9
      Tyler Hicks 提交于
      The ima_keyrings buffer was used as a work buffer for strsep()-based
      parsing of the "keyrings=" option of an IMA policy rule. This parsing
      was re-performed each time an asymmetric key was added to a kernel
      keyring for each loaded policy rule that contained a "keyrings=" option.
      
      An example rule specifying this option is:
      
       measure func=KEY_CHECK keyrings=a|b|c
      
      The rule says to measure asymmetric keys added to any of the kernel
      keyrings named "a", "b", or "c". The size of the buffer size was
      equal to the size of the largest "keyrings=" value seen in a previously
      loaded rule (5 + 1 for the NUL-terminator in the previous example) and
      the buffer was pre-allocated at the time of policy load.
      
      The pre-allocated buffer approach suffered from a couple bugs:
      
      1) There was no locking around the use of the buffer so concurrent key
         add operations, to two different keyrings, would result in the
         strsep() loop of ima_match_keyring() to modify the buffer at the same
         time. This resulted in unexpected results from ima_match_keyring()
         and, therefore, could cause unintended keys to be measured or keys to
         not be measured when IMA policy intended for them to be measured.
      
      2) If the kstrdup() that initialized entry->keyrings in ima_parse_rule()
         failed, the ima_keyrings buffer was freed and set to NULL even when a
         valid KEY_CHECK rule was previously loaded. The next KEY_CHECK event
         would trigger a call to strcpy() with a NULL destination pointer and
         crash the kernel.
      
      Remove the need for a pre-allocated global buffer by parsing the list of
      keyrings in a KEY_CHECK rule at the time of policy load. The
      ima_rule_entry will contain an array of string pointers which point to
      the name of each keyring specified in the rule. No string processing
      needs to happen at the time of asymmetric key add so iterating through
      the list and doing a string comparison is all that's required at the
      time of policy check.
      
      In the process of changing how the "keyrings=" policy option is handled,
      a couple additional bugs were fixed:
      
      1) The rule parser accepted rules containing invalid "keyrings=" values
         such as "a|b||c", "a|b|", or simply "|".
      
      2) The /sys/kernel/security/ima/policy file did not display the entire
         "keyrings=" value if the list of keyrings was longer than what could
         fit in the fixed size tbuf buffer in ima_policy_show().
      
      Fixes: 5c7bac9f ("IMA: pre-allocate buffer to hold keyrings string")
      Fixes: 2b60c0ec ("IMA: Read keyrings= option from the IMA policy")
      Signed-off-by: NTyler Hicks <tyhicks@linux.microsoft.com>
      Reviewed-by: NLakshmi Ramasubramanian <nramas@linux.microsoft.com>
      Reviewed-by: NNayna Jain <nayna@linux.ibm.com>
      Signed-off-by: NMimi Zohar <zohar@linux.ibm.com>
      176377d9
新手
引导
客服 返回
顶部