Skip to content

L
linux
Switch branch/tag
  1. 27 Jun, 2016 19 commits
  3. 15 Jun, 2016 1 commit
  5. 09 Jun, 2016 2 commits
    • Paul Moore's avatar
      netlabel: handle sparse category maps in netlbl_catmap_getlong() · 50b8629a
      Paul Moore authored 
      In cases where the category bitmap is sparse enough that gaps exist
between netlbl_lsm_catmap structs, callers to netlbl_catmap_getlong()
could find themselves prematurely ending their search through the
category bitmap.  Further, the methods used to calculate the 'idx'
and 'off' values were incorrect for bitmaps this large.  This patch
changes the netlbl_catmap_getlong() behavior so that it always skips
over gaps and calculates the index and offset values correctly.
Signed-off-by: default avatarPaul Moore <paul@paul-moore.com>
      50b8629a
    • Paul Moore's avatar
      selinux: import NetLabel category bitmaps correctly · 8bebe88c
      Paul Moore authored 
      The existing ebitmap_netlbl_import() code didn't correctly handle the
case where the ebitmap_node was not aligned/sized to a power of two,
this patch fixes this (on x86_64 ebitmap_node contains six bitmaps
making a range of 0..383).
Signed-off-by: default avatarPaul Moore <paul@paul-moore.com>
      8bebe88c
  7. 07 Jun, 2016 1 commit
  9. 06 Jun, 2016 1 commit
  11. 31 May, 2016 1 commit
    • Stephen Smalley's avatar
      selinux: Only apply bounds checking to source types · 7ea59202
      Stephen Smalley authored 
      The current bounds checking of both source and target types
requires allowing any domain that has access to the child
domain to also have the same permissions to the parent, which
is undesirable.  Drop the target bounds checking.

KaiGai Kohei originally removed all use of target bounds in
commit 7d52a155 ("selinux: remove dead code in
type_attribute_bounds_av()") but this was reverted in
commit 2ae3ba39 ("selinux: libsepol: remove dead code in
check_avtab_hierarchy_callback()") because it would have
required explicitly allowing the parent any permissions
to the child that the child is allowed to itself.

This change in contrast retains the logic for the case where both
source and target types are bounded, thereby allowing access
if the parent of the source is allowed the corresponding
permissions to the parent of the target.  Further, this change
reworks the logic such that we only perform a single computation
for each case and there is no ambiguity as to how to resolve
a bounds violation.

Under the new logic, if the source type and target types are both
bounded, then the parent of the source type must be allowed the same
permissions to the parent of the target type.  If only the source
type is bounded, then the parent of the source type must be allowed
the same permissions to the target type.

Examples of the new logic and comparisons with the old logic:
1. If we have:
	typebounds A B;
then:
	allow B self:process <permissions>;
will satisfy the bounds constraint iff:
	allow A self:process <permissions>;
is also allowed in policy.

Under the old logic, the allow rule on B satisfies the
bounds constraint if any of the following three are allowed:
	allow A B:process <permissions>; or
	allow B A:process <permissions>; or
	allow A self:process <permissions>;
However, either of the first two ultimately require the third to
satisfy the bounds constraint under the old logic, and therefore
this degenerates to the same result (but is more efficient - we only
need to perform one compute_av call).

2. If we have:
	typebounds A B;
	typebounds A_exec B_exec;
then:
	allow B B_exec:file <permissions>;
will satisfy the bounds constraint iff:
	allow A A_exec:file <permissions>;
is also allowed in policy.

This is essentially the same as #1; it is merely included as
an example of dealing with object types related to a bounded domain
in a manner that satisfies the bounds relationship.  Note that
this approach is preferable to leaving B_exec unbounded and having:
	allow A B_exec:file <permissions>;
in policy because that would allow B's entrypoints to be used to
enter A.  Similarly for _tmp or other related types.

3. If we have:
	typebounds A B;
and an unbounded type T, then:
	allow B T:file <permissions>;
will satisfy the bounds constraint iff:
	allow A T:file <permissions>;
is allowed in policy.

The old logic would have been identical for this example.

4. If we have:
	typebounds A B;
and an unbounded domain D, then:
	allow D B:unix_stream_socket <permissions>;
is not subject to any bounds constraints under the new logic
because D is not bounded.  This is desirable so that we can
allow a domain to e.g. connectto a child domain without having
to allow it to do the same to its parent.

The old logic would have required:
	allow D A:unix_stream_socket <permissions>;
to also be allowed in policy.
Signed-off-by: default avatarStephen Smalley <sds@tycho.nsa.gov>
[PM: re-wrapped description to appease checkpatch.pl]
Signed-off-by: default avatarPaul Moore <paul@paul-moore.com>
      7ea59202
  13. 17 May, 2016 1 commit
  15. 05 May, 2016 2 commits
  17. 04 May, 2016 3 commits
    • Sasha Levin's avatar
      Yama: use atomic allocations when reporting · 74f430cd
      Sasha Levin authored 
      Access reporting often happens from atomic contexes. Avoid
lockups when allocating memory for command lines.

Fixes: 8a56038c ("Yama: consolidate error reporting")
Signed-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
      74f430cd
    • Mickaël Salaün's avatar
      seccomp: Fix comment typo · 470bf1f2
      Mickaël Salaün authored 
      Drop accidentally repeated word in comment.
Signed-off-by: default avatarMickaël Salaün <mic@digikod.net>
Cc: Kees Cook <keescook@chromium.org>
Cc: Andy Lutomirski <luto@amacapital.net>
Cc: Will Drewry <wad@chromium.org>
      470bf1f2
    • David Howells's avatar
      Merge branch 'keys-trust' into keys-next · d55201ce
      David Howells authored 
      Here's a set of patches that changes how certificates/keys are determined
to be trusted.  That's currently a two-step process:

 (1) Up until recently, when an X.509 certificate was parsed - no matter
     the source - it was judged against the keys in .system_keyring,
     assuming those keys to be trusted if they have KEY_FLAG_TRUSTED set
     upon them.

     This has just been changed such that any key in the .ima_mok keyring,
     if configured, may also be used to judge the trustworthiness of a new
     certificate, whether or not the .ima_mok keyring is meant to be
     consulted for whatever process is being undertaken.

     If a certificate is determined to be trustworthy, KEY_FLAG_TRUSTED
     will be set upon a key it is loaded into (if it is loaded into one),
     no matter what the key is going to be loaded for.

 (2) If an X.509 certificate is loaded into a key, then that key - if
     KEY_FLAG_TRUSTED gets set upon it - can be linked into any keyring
     with KEY_FLAG_TRUSTED_ONLY set upon it.  This was meant to be the
     system keyring only, but has been extended to various IMA keyrings.
     A user can at will link any key marked KEY_FLAG_TRUSTED into any
     keyring marked KEY_FLAG_TRUSTED_ONLY if the relevant permissions masks
     permit it.

These patches change that:

 (1) Trust becomes a matter of consulting the ring of trusted keys supplied
     when the trust is evaluated only.

 (2) Every keyring can be supplied with its own manager function to
     restrict what may be added to that keyring.  This is called whenever a
     key is to be linked into the keyring to guard against a key being
     created in one keyring and then linked across.

     This function is supplied with the keyring and the key type and
     payload[*] of the key being linked in for use in its evaluation.  It
     is permitted to use other data also, such as the contents of other
     keyrings such as the system keyrings.

     [*] The type and payload are supplied instead of a key because as an
         optimisation this function may be called whilst creating a key and
         so may reject the proposed key between preparse and allocation.

 (3) A default manager function is provided that permits keys to be
     restricted to only asymmetric keys that are vouched for by the
     contents of the system keyring.

     A second manager function is provided that just rejects with EPERM.

 (4) A key allocation flag, KEY_ALLOC_BYPASS_RESTRICTION, is made available
     so that the kernel can initialise keyrings with keys that form the
     root of the trust relationship.

 (5) KEY_FLAG_TRUSTED and KEY_FLAG_TRUSTED_ONLY are removed, along with
     key_preparsed_payload::trusted.

This change also makes it possible in future for userspace to create a private
set of trusted keys and then to have it sealed by setting a manager function
where the private set is wholly independent of the kernel's trust
relationships.

Further changes in the set involve extracting certain IMA special keyrings
and making them generally global:

 (*) .system_keyring is renamed to .builtin_trusted_keys and remains read
     only.  It carries only keys built in to the kernel.  It may be where
     UEFI keys should be loaded - though that could better be the new
     secondary keyring (see below) or a separate UEFI keyring.

 (*) An optional secondary system keyring (called .secondary_trusted_keys)
     is added to replace the IMA MOK keyring.

     (*) Keys can be added to the secondary keyring by root if the keys can
         be vouched for by either ring of system keys.

 (*) Module signing and kexec only use .builtin_trusted_keys and do not use
     the new secondary keyring.

 (*) Config option SYSTEM_TRUSTED_KEYS now depends on ASYMMETRIC_KEY_TYPE as
     that's the only type currently permitted on the system keyrings.

 (*) A new config option, IMA_KEYRINGS_PERMIT_SIGNED_BY_BUILTIN_OR_SECONDARY,
     is provided to allow keys to be added to IMA keyrings, subject to the
     restriction that such keys are validly signed by a key already in the
     system keyrings.

     If this option is enabled, but secondary keyrings aren't, additions to
     the IMA keyrings will be restricted to signatures verifiable by keys in
     the builtin system keyring only.
Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      d55201ce
  19. 01 May, 2016 3 commits
    • Mimi Zohar's avatar
      ima: add support for creating files using the mknodat syscall · 05d1a717
      Mimi Zohar authored 
      Commit 3034a146 "ima: pass 'opened' flag to identify newly created files"
stopped identifying empty files as new files.  However new empty files
can be created using the mknodat syscall.  On systems with IMA-appraisal
enabled, these empty files are not labeled with security.ima extended
attributes properly, preventing them from subsequently being opened in
order to write the file data contents.  This patch defines a new hook
named ima_post_path_mknod() to mark these empty files, created using
mknodat, as new in order to allow the file data contents to be written.

In addition, files with security.ima xattrs containing a file signature
are considered "immutable" and can not be modified.  The file contents
need to be written, before signing the file.  This patch relaxes this
requirement for new files, allowing the file signature to be written
before the file contents.

Changelog:
- defer identifying files with signatures stored as security.ima
  (based on Dmitry Rozhkov's comments)
- removing tests (eg. dentry, dentry->d_inode, inode->i_size == 0)
  (based on Al's review)
Signed-off-by: default avatarMimi Zohar <zohar@linux.vnet.ibm.com>
Cc: Al Viro <<viro@zeniv.linux.org.uk>
Tested-by: default avatarDmitry Rozhkov <dmitry.rozhkov@linux.intel.com>
      05d1a717
    • Mimi Zohar's avatar
      ima: fix ima_inode_post_setattr · 42a4c603
      Mimi Zohar authored 
      Changing file metadata (eg. uid, guid) could result in having to
re-appraise a file's integrity, but does not change the "new file"
status nor the security.ima xattr.  The IMA_PERMIT_DIRECTIO and
IMA_DIGSIG_REQUIRED flags are policy rule specific.  This patch
only resets these flags, not the IMA_NEW_FILE or IMA_DIGSIG flags.

With this patch, changing the file timestamp will not remove the
file signature on new files.
Reported-by: default avatarDmitry Rozhkov <dmitry.rozhkov@linux.intel.com>
Signed-off-by: default avatarMimi Zohar <zohar@linux.vnet.ibm.com>
Tested-by: default avatarDmitry Rozhkov <dmitry.rozhkov@linux.intel.com>
      42a4c603
    • Dmitry Kasatkin's avatar
      vfs: forbid write access when reading a file into memory · 39d637af
      Dmitry Kasatkin authored 
      This patch is based on top of the "vfs: support for a common kernel file
loader" patch set.  In general when the kernel is reading a file into
memory it does not want anything else writing to it.

The kernel currently only forbids write access to a file being executed.
This patch extends this locking to files being read by the kernel.

Changelog:
- moved function to kernel_read_file() - Mimi
- updated patch description - Mimi
Signed-off-by: default avatarDmitry Kasatkin <dmitry.kasatkin@huawei.com>
Cc: Al Viro <viro@ZenIV.linux.org.uk>
Signed-off-by: default avatarMimi Zohar <zohar@linux.vnet.ibm.com>
Reviewed-by: default avatarLuis R. Rodriguez <mcgrof@kernel.org>
Acked-by: default avatarKees Cook <keescook@chromium.org>
      39d637af
  21. 27 Apr, 2016 1 commit
  23. 26 Apr, 2016 2 commits
  25. 21 Apr, 2016 3 commits
GitLab Nexedi Edition | About GitLab | About Nexedi | 沪ICP备2021021310号-2 | 沪ICP备2021021310号-7