Skip to content
Snippets Groups Projects
Select Git revision
16 results
Search by author
  • Any Author
0 authors
  1. Aug 20, 2024
  3. May 09, 2024
  5. May 02, 2024
  7. Apr 26, 2024
  9. Dec 08, 2023
  11. Sep 23, 2023
  13. Aug 18, 2023
  15. Apr 28, 2023
    • Randy Dunlap's avatar
      lsm: move hook comments docs to security/security.c · 6d2ed653
      Randy Dunlap authored 
      
Fix one kernel-doc warning, but invesigating that led to other
kernel-doc movement (lsm_hooks.h to security.c) that needs to be
fixed also.

include/linux/lsm_hooks.h:1: warning: no structured comments found

Fixes: e261301c ("lsm: move the remaining LSM hook comments to security/security.c")
Fixes: 1cd2aca6 ("lsm: move the io_uring hook comments to security/security.c")
Fixes: 452b670c ("lsm: move the perf hook comments to security/security.c")
Fixes: 55e85320 ("lsm: move the bpf hook comments to security/security.c")
Fixes: b14faf9c ("lsm: move the audit hook comments to security/security.c")
Fixes: 1427ddbe ("lsm: move the binder hook comments to security/security.c")
Fixes: 43fad282 ("lsm: move the sysv hook comments to security/security.c")
Fixes: ecc419a4 ("lsm: move the key hook comments to security/security.c")
Fixes: 742b9945 ("lsm: move the xfrm hook comments to security/security.c")
Fixes: ac318aed ("lsm: move the Infiniband hook comments to security/security.c")
Fixes: 4a49f592 ("lsm: move the SCTP hook comments to security/security.c")
Fixes: 6b6bbe8c ("lsm: move the socket hook comments to security/security.c")
Fixes: 2c2442fd ("lsm: move the AF_UNIX hook comments to security/security.c")
Fixes: 2bcf51bf ("lsm: move the netlink hook comments to security/security.c")
Fixes: 130c53bf ("lsm: move the task hook comments to security/security.c")
Fixes: a0fd6480 ("lsm: move the file hook comments to security/security.c")
Fixes: 9348944b ("lsm: move the kernfs hook comments to security/security.c")
Fixes: 916e3258 ("lsm: move the inode hook comments to security/security.c")
Fixes: 08526a90 ("lsm: move the filesystem hook comments to security/security.c")
Fixes: 36819f18 ("lsm: move the fs_context hook comments to security/security.c")
Fixes: 1661372c ("lsm: move the program execution hook comments to security/security.c")
Signed-off-by: default avatarRandy Dunlap <rdunlap@infradead.org>
Cc: Paul Moore <paul@paul-moore.com>
Cc: James Morris <jmorris@namei.org>
Cc: "Serge E. Hallyn" <serge@hallyn.com>
Cc: linux-security-module@vger.kernel.org
Cc: Jonathan Corbet <corbet@lwn.net>
Cc: linux-doc@vger.kernel.org
Cc: KP Singh <kpsingh@kernel.org>
Cc: bpf@vger.kernel.org
Signed-off-by: default avatarPaul Moore <paul@paul-moore.com>
      6d2ed653
  17. Jan 13, 2023
  19. Oct 19, 2022
    • Nikolaus Voss's avatar
      KEYS: encrypted: fix key instantiation with user-provided data · 5adedd42
      Nikolaus Voss authored 
      Commit cd3bc044 ("KEYS: encrypted: Instantiate key with
user-provided decrypted data") added key instantiation with user
provided decrypted data.  The user data is hex-ascii-encoded but was
just memcpy'ed to the binary buffer. Fix this to use hex2bin instead.

Old keys created from user provided decrypted data saved with "keyctl
pipe" are still valid, however if the key is recreated from decrypted
data the old key must be converted to the correct format. This can be
done with a small shell script, e.g.:

BROKENKEY=abcdefABCDEF1234567890aaaaaaaaaa
NEWKEY=$(echo -ne $BROKENKEY | xxd -p -c32)
keyctl add user masterkey "$(cat masterkey.bin)" @u
keyctl add encrypted testkey "new user:masterkey 32 $NEWKEY" @u

However, NEWKEY is still broken: If for BROKENKEY 32 bytes were
specified, a brute force attacker knowing the key properties would only
need to try at most 2^(16*8) keys, as if the key was only 16 bytes long.

The security issue is a result of the combination of limiting the input
range to hex-ascii and using memcpy() instead of hex2bin(). It could
have been fixed either by allowing binary input or using hex2bin() (and
doubling the ascii input key length). This patch implements the latter.

The corresponding test for the Linux Test Project ltp has also been
fixed (see link below).

Fixes: cd3bc044 ("KEYS: encrypted: Instantiate key with user-provided decrypted data")
Cc: stable@kernel.org
Link: https://lore.kernel.org/ltp/20221006081709.92303897@mail.steuer-voss.de/


Reviewed-by: default avatarMimi Zohar <zohar@linux.ibm.com>
Signed-off-by: default avatarNikolaus Voss <nikolaus.voss@haag-streit.com>
Signed-off-by: default avatarMimi Zohar <zohar@linux.ibm.com>
      5adedd42
  21. Sep 29, 2022
  23. Jul 13, 2022
  25. Jul 07, 2022
  27. May 23, 2022
  29. May 05, 2022
    • Mimi Zohar's avatar
      ima: support fs-verity file digest based version 3 signatures · 398c42e2
      Mimi Zohar authored 
      
IMA may verify a file's integrity against a "good" value stored in the
'security.ima' xattr or as an appended signature, based on policy.  When
the "good value" is stored in the xattr, the xattr may contain a file
hash or signature.  In either case, the "good" value is preceded by a
header.  The first byte of the xattr header indicates the type of data
- hash, signature - stored in the xattr.  To support storing fs-verity
signatures in the 'security.ima' xattr requires further differentiating
the fs-verity signature from the existing IMA signature.

In addition the signatures stored in 'security.ima' xattr, need to be
disambiguated.  Instead of directly signing the fs-verity digest, a new
signature format version 3 is defined as the hash of the ima_file_id
structure, which identifies the type of signature and the digest.

The IMA policy defines "which" files are to be measured, verified, and/or
audited.  For those files being verified, the policy rules indicate "how"
the file should be verified.  For example to require a file be signed,
the appraise policy rule must include the 'appraise_type' option.

	appraise_type:= [imasig] | [imasig|modsig] | [sigv3]
           where 'imasig' is the original or signature format v2 (default),
           where 'modsig' is an appended signature,
           where 'sigv3' is the signature format v3.

The policy rule must also indicate the type of digest, if not the IMA
default, by first specifying the digest type:

	digest_type:= [verity]

The following policy rule requires fsverity signatures.  The rule may be
constrained, for example based on a fsuuid or LSM label.

      appraise func=BPRM_CHECK digest_type=verity appraise_type=sigv3

Acked-by: default avatarStefan Berger <stefanb@linux.ibm.com>
Signed-off-by: default avatarMimi Zohar <zohar@linux.ibm.com>
      398c42e2
    • Mimi Zohar's avatar
      ima: permit fsverity's file digests in the IMA measurement list · 54f03916
      Mimi Zohar authored 
      
Permit fsverity's file digest (a hash of struct fsverity_descriptor) to
be included in the IMA measurement list, based on the new measurement
policy rule 'digest_type=verity' option.

To differentiate between a regular IMA file hash from an fsverity's
file digest, use the new d-ngv2 format field included in the ima-ngv2
template.

The following policy rule requires fsverity file digests and specifies
the new 'ima-ngv2' template, which contains the new 'd-ngv2' field.  The
policy rule may be constrained, for example based on a fsuuid or LSM
label.

measure func=FILE_CHECK digest_type=verity template=ima-ngv2

Acked-by: default avatarStefan Berger <stefanb@linux.ibm.com>
Signed-off-by: default avatarMimi Zohar <zohar@linux.ibm.com>
      54f03916
    • Mimi Zohar's avatar
      ima: define a new template field named 'd-ngv2' and templates · 989dc725
      Mimi Zohar authored 
      
In preparation to differentiate between unsigned regular IMA file
hashes and fs-verity's file digests in the IMA measurement list,
define a new template field named 'd-ngv2'.

Also define two new templates named 'ima-ngv2' and 'ima-sigv2', which
include the new 'd-ngv2' field.

Signed-off-by: default avatarMimi Zohar <zohar@linux.ibm.com>
      989dc725
  31. May 01, 2022
  33. Apr 25, 2022
  35. Apr 13, 2022
  37. Feb 28, 2022
    • Wan Jiabing's avatar
      docs: fix 'make htmldocs' warning in SCTP.rst · 70868c6b
      Wan Jiabing authored 
      
Fix following 'make htmldocs' warnings:
./Documentation/security/SCTP.rst:123: WARNING: Title underline too short.
security_sctp_assoc_established()
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
./Documentation/security/SCTP.rst:123: WARNING: Title underline too short.
security_sctp_assoc_established()
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
./Documentation/security/SCTP.rst:273: WARNING: Title underline too short.
security_sctp_assoc_established()
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
./Documentation/security/SCTP.rst:273: WARNING: Title underline too short.
security_sctp_assoc_established()
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Fixes: 5e50f5d4 ("security: add sctp_assoc_established hook")
Signed-off-by: default avatarWan Jiabing <wanjiabing@vivo.com>
Reviewed-by: default avatarXin Long <lucien.xin@gmail.com>
Signed-off-by: default avatarPaul Moore <paul@paul-moore.com>
      70868c6b
  39. Feb 22, 2022
    • Yael Tzur's avatar
      KEYS: encrypted: Instantiate key with user-provided decrypted data · cd3bc044
      Yael Tzur authored 
      
For availability and performance reasons master keys often need to be
released outside of a Key Management Service (KMS) to clients. It
would be beneficial to provide a mechanism where the
wrapping/unwrapping of data encryption keys (DEKs) is not dependent
on a remote call at runtime yet security is not (or only minimally)
compromised. Master keys could be securely stored in the Kernel and
be used to wrap/unwrap keys from Userspace.

The encrypted.c class supports instantiation of encrypted keys with
either an already-encrypted key material, or by generating new key
material based on random numbers. This patch defines a new datablob
format: [<format>] <master-key name> <decrypted data length>
<decrypted data> that allows to inject and encrypt user-provided
decrypted data. The decrypted data must be hex-ascii encoded.

Signed-off-by: default avatarYael Tzur <yaelt@google.com>
Reviewed-by: default avatarMimi Zohar <zohar@linux.ibm.com>
Reviewed-by: default avatarSumit Garg <sumit.garg@linaro.org>
Reviewed-by: default avatarJarkko Sakkinen <jarkko@kernel.org>
Signed-off-by: default avatarMimi Zohar <zohar@linux.ibm.com>
      cd3bc044
  41. Feb 15, 2022
  43. Dec 10, 2021
  45. Nov 14, 2021
    • Paul Moore's avatar
      net,lsm,selinux: revert the security_sctp_assoc_established() hook · 1aa3b220
      Paul Moore authored 
      
This patch reverts two prior patches, e7310c94
("security: implement sctp_assoc_established hook in selinux") and
7c2ef024 ("security: add sctp_assoc_established hook"), which
create the security_sctp_assoc_established() LSM hook and provide a
SELinux implementation.  Unfortunately these two patches were merged
without proper review (the Reviewed-by and Tested-by tags from
Richard Haines were for previous revisions of these patches that
were significantly different) and there are outstanding objections
from the SELinux maintainers regarding these patches.

Work is currently ongoing to correct the problems identified in the
reverted patches, as well as others that have come up during review,
but it is unclear at this point in time when that work will be ready
for inclusion in the mainline kernel.  In the interest of not keeping
objectionable code in the kernel for multiple weeks, and potentially
a kernel release, we are reverting the two problematic patches.

Signed-off-by: default avatarPaul Moore <paul@paul-moore.com>
Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      1aa3b220
  47. Nov 12, 2021
    • Paul Moore's avatar
      net,lsm,selinux: revert the security_sctp_assoc_established() hook · 32a370ab
      Paul Moore authored 
      
This patch reverts two prior patches, e7310c94
("security: implement sctp_assoc_established hook in selinux") and
7c2ef024 ("security: add sctp_assoc_established hook"), which
create the security_sctp_assoc_established() LSM hook and provide a
SELinux implementation.  Unfortunately these two patches were merged
without proper review (the Reviewed-by and Tested-by tags from
Richard Haines were for previous revisions of these patches that
were significantly different) and there are outstanding objections
from the SELinux maintainers regarding these patches.

Work is currently ongoing to correct the problems identified in the
reverted patches, as well as others that have come up during review,
but it is unclear at this point in time when that work will be ready
for inclusion in the mainline kernel.  In the interest of not keeping
objectionable code in the kernel for multiple weeks, and potentially
a kernel release, we are reverting the two problematic patches.

Signed-off-by: default avatarPaul Moore <paul@paul-moore.com>
      32a370ab
  49. Nov 03, 2021
  51. Jun 17, 2021
  53. Jun 08, 2021