17 Aug, 2022
2 commits
-
[ Upstream commit 15ec76fb29be31df2bccb30fc09875274cba2776 ]
Just like next_entry(), boundary check is necessary to prevent memory
out-of-bound access.Signed-off-by: Xiu Jianfeng
Signed-off-by: Paul Moore
Signed-off-by: Sasha Levin -
[ Upstream commit 73de1befcc53a7c68b0c5e76b9b5ac41c517760f ]
In this function, it directly returns the result of __security_read_policy
without freeing the allocated memory in *data, cause memory leak issue,
so free the memory if __security_read_policy failed.Signed-off-by: Xiu Jianfeng
[PM: subject line tweak]
Signed-off-by: Paul Moore
Signed-off-by: Sasha Levin
29 Jul, 2022
1 commit
-
commit 543ce63b664e2c2f9533d089a4664b559c3e6b5b upstream.
The lockdown LSM is primarily used in conjunction with UEFI Secure Boot.
This LSM may also be used on machines without UEFI. It can also be
enabled when UEFI Secure Boot is disabled. One of lockdown's features
is to prevent kexec from loading untrusted kernels. Lockdown can be
enabled through a bootparam or after the kernel has booted through
securityfs.If IMA appraisal is used with the "ima_appraise=log" boot param,
lockdown can be defeated with kexec on any machine when Secure Boot is
disabled or unavailable. IMA prevents setting "ima_appraise=log" from
the boot param when Secure Boot is enabled, but this does not cover
cases where lockdown is used without Secure Boot.To defeat lockdown, boot without Secure Boot and add ima_appraise=log to
the kernel command line; then:$ echo "integrity" > /sys/kernel/security/lockdown
$ echo "appraise func=KEXEC_KERNEL_CHECK appraise_type=imasig" > \
/sys/kernel/security/ima/policy
$ kexec -ls unsigned-kernelAdd a call to verify ima appraisal is set to "enforce" whenever lockdown
is enabled. This fixes CVE-2022-21505.Cc: stable@vger.kernel.org
Fixes: 29d3c1c8dfe7 ("kexec: Allow kexec_file() with appropriate IMA policy when locked down")
Signed-off-by: Eric Snowberg
Acked-by: Mimi Zohar
Reviewed-by: John Haxby
Signed-off-by: Linus Torvalds
Signed-off-by: Greg Kroah-Hartman
23 Jul, 2022
1 commit
-
commit f43b9876e857c739d407bc56df288b0ebe1a9164 upstream.
Do fine-grained Kconfig for all the various retbleed parts.
NOTE: if your compiler doesn't support return thunks this will
silently 'upgrade' your mitigation to IBPB, you might not like this.Signed-off-by: Peter Zijlstra (Intel)
Signed-off-by: Borislav Petkov
[cascardo: there is no CONFIG_OBJTOOL]
[cascardo: objtool calling and option parsing has changed]
Signed-off-by: Thadeu Lima de Souza Cascardo
Signed-off-by: Greg Kroah-Hartman
22 Jul, 2022
4 commits
-
[ Upstream commit 067d2521874135267e681c19d42761c601d503d6 ]
On failure to allocate the SHA1 tfm, IMA fails to initialize and exits
without freeing the ima_algo_array. Add the missing kfree() for
ima_algo_array to avoid the potential memory leak.Signed-off-by: Jianglei Nie
Fixes: 6d94809af6b0 ("ima: Allocate and initialize tfm for each PCR bank")
Signed-off-by: Mimi Zohar
Signed-off-by: Sasha Levin -
[ Upstream commit af16df54b89dee72df253abc5e7b5e8a6d16c11c ]
Currently, an unsigned kernel could be kexec'ed when IMA arch specific
policy is configured unless lockdown is enabled. Enforce kernel
signature verification check in the kexec_file_load syscall when IMA
arch specific policy is configured.Fixes: 99d5cadfde2b ("kexec_file: split KEXEC_VERIFY_SIG into KEXEC_SIG and KEXEC_SIG_FORCE")
Reported-and-suggested-by: Mimi Zohar
Signed-off-by: Coiby Xu
Signed-off-by: Mimi Zohar
Signed-off-by: Sasha Levin -
[ Upstream commit d2ee2cfc4aa85ff6a2a3b198a3a524ec54e3d999 ]
When the ima-modsig is enabled, the rc passed to evm_verifyxattr() may be
negative, which may cause the integer overflow problem.Fixes: 39b07096364a ("ima: Implement support for module-style appended signatures")
Signed-off-by: Huaxin Lu
Signed-off-by: Mimi Zohar
Signed-off-by: Sasha Levin -
commit 51dd64bb99e4478fc5280171acd8e1b529eadaf7 upstream.
This reverts commit ccf11dbaa07b328fa469415c362d33459c140a37.
Commit ccf11dbaa07b ("evm: Fix memleak in init_desc") said there is
memleak in init_desc. That may be incorrect, as we can see, tmp_tfm is
saved in one of the two global variables hmac_tfm or evm_tfm[hash_algo],
then if init_desc is called next time, there is no need to alloc tfm
again, so in the error path of kmalloc desc or crypto_shash_init(desc),
It is not a problem without freeing tmp_tfm.And also that commit did not reset the global variable to NULL after
freeing tmp_tfm and this makes *tfm a dangling pointer which may cause a
UAF issue.Reported-by: Guozihua (Scott)
Signed-off-by: Xiu Jianfeng
Signed-off-by: Mimi Zohar
Signed-off-by: Greg Kroah-Hartman
02 Jul, 2022
3 commits
-
commit bd303368b776eead1c29e6cdda82bde7128b82a7 upstream.
In previous patches we added new and modified existing helpers to handle
idmapped mounts of filesystems mounted with an idmapping. In this final
patch we convert all relevant places in the vfs to actually pass the
filesystem's idmapping into these helpers.With this the vfs is in shape to handle idmapped mounts of filesystems
mounted with an idmapping. Note that this is just the generic
infrastructure. Actually adding support for idmapped mounts to a
filesystem mountable with an idmapping is follow-up work.In this patch we extend the definition of an idmapped mount from a mount
that that has the initial idmapping attached to it to a mount that has
an idmapping attached to it which is not the same as the idmapping the
filesystem was mounted with.As before we do not allow the initial idmapping to be attached to a
mount. In addition this patch prevents that the idmapping the filesystem
was mounted with can be attached to a mount created based on this
filesystem.This has multiple reasons and advantages. First, attaching the initial
idmapping or the filesystem's idmapping doesn't make much sense as in
both cases the values of the i_{g,u}id and other places where k{g,u}ids
are used do not change. Second, a user that really wants to do this for
whatever reason can just create a separate dedicated identical idmapping
to attach to the mount. Third, we can continue to use the initial
idmapping as an indicator that a mount is not idmapped allowing us to
continue to keep passing the initial idmapping into the mapping helpers
to tell them that something isn't an idmapped mount even if the
filesystem is mounted with an idmapping.Link: https://lore.kernel.org/r/20211123114227.3124056-11-brauner@kernel.org (v1)
Link: https://lore.kernel.org/r/20211130121032.3753852-11-brauner@kernel.org (v2)
Link: https://lore.kernel.org/r/20211203111707.3901969-11-brauner@kernel.org
Cc: Seth Forshee
Cc: Amir Goldstein
Cc: Christoph Hellwig
Cc: Al Viro
CC: linux-fsdevel@vger.kernel.org
Reviewed-by: Seth Forshee
Signed-off-by: Christian Brauner
Signed-off-by: Christian Brauner (Microsoft)
Signed-off-by: Greg Kroah-Hartman -
commit 4472071331549e911a5abad41aea6e3be855a1a4 upstream.
In a few places the vfs needs to interact with bare k{g,u}ids directly
instead of struct inode. These are just a few. In previous patches we
introduced low-level mapping helpers that are able to support
filesystems mounted an idmapping. This patch simply converts the places
to use these new helpers.Link: https://lore.kernel.org/r/20211123114227.3124056-7-brauner@kernel.org (v1)
Link: https://lore.kernel.org/r/20211130121032.3753852-7-brauner@kernel.org (v2)
Link: https://lore.kernel.org/r/20211203111707.3901969-7-brauner@kernel.org
Cc: Seth Forshee
Cc: Amir Goldstein
Cc: Christoph Hellwig
Cc: Al Viro
CC: linux-fsdevel@vger.kernel.org
Reviewed-by: Seth Forshee
Signed-off-by: Christian Brauner
Signed-off-by: Christian Brauner (Microsoft)
Signed-off-by: Greg Kroah-Hartman -
commit a793d79ea3e041081cd7cbd8ee43d0b5e4914a2b upstream.
The low-level mapping helpers were so far crammed into fs.h. They are
out of place there. The fs.h header should just contain the higher-level
mapping helpers that interact directly with vfs objects such as struct
super_block or struct inode and not the bare mapping helpers. Similarly,
only vfs and specific fs code shall interact with low-level mapping
helpers. And so they won't be made accessible automatically through
regular {g,u}id helpers.Link: https://lore.kernel.org/r/20211123114227.3124056-3-brauner@kernel.org (v1)
Link: https://lore.kernel.org/r/20211130121032.3753852-3-brauner@kernel.org (v2)
Link: https://lore.kernel.org/r/20211203111707.3901969-3-brauner@kernel.org
Cc: Seth Forshee
Cc: Christoph Hellwig
Cc: Al Viro
CC: linux-fsdevel@vger.kernel.org
Reviewed-by: Amir Goldstein
Reviewed-by: Seth Forshee
Signed-off-by: Christian Brauner
Signed-off-by: Christian Brauner (Microsoft)
Signed-off-by: Greg Kroah-Hartman
15 Jun, 2022
1 commit
-
commit dda5384313a40ecbaafd8a9a80f47483255e4c4d upstream.
When creating (sealing) a new trusted key, migratable
trusted keys have the FIXED_TPM and FIXED_PARENT attributes
set, and non-migratable keys don't. This is backwards, and
also causes creation to fail when creating a migratable key
under a migratable parent. (The TPM thinks you are trying to
seal a non-migratable blob under a migratable parent.)The following simple patch fixes the logic, and has been
tested for all four combinations of migratable and non-migratable
trusted keys and parent storage keys. With this logic, you will
get a proper failure if you try to create a non-migratable
trusted key under a migratable parent storage key, and all other
combinations work correctly.Cc: stable@vger.kernel.org # v5.13+
Fixes: e5fb5d2c5a03 ("security: keys: trusted: Make sealed key properly interoperable")
Signed-off-by: David Safford
Reviewed-by: Ahmad Fatoum
Reviewed-by: Jarkko Sakkinen
Signed-off-by: Jarkko Sakkinen
Signed-off-by: Greg Kroah-Hartman
09 Jun, 2022
11 commits
-
commit 891163adf180bc369b2f11c9dfce6d2758d2a5bd upstream.
The original 'ima' measurement list template contains a hash, defined
as 20 bytes, and a null terminated pathname, limited to 255
characters. Other measurement list templates permit both larger hashes
and longer pathnames. When the "ima" template is configured as the
default, a new measurement list template (ima_template=) must be
specified before specifying a larger hash algorithm (ima_hash=) on the
boot command line.To avoid this boot command line ordering issue, remove the legacy "ima"
template configuration option, allowing it to still be specified on the
boot command line.The root cause of this issue is that during the processing of ima_hash,
we would try to check whether the hash algorithm is compatible with the
template. If the template is not set at the moment we do the check, we
check the algorithm against the configured default template. If the
default template is "ima", then we reject any hash algorithm other than
sha1 and md5.For example, if the compiled default template is "ima", and the default
algorithm is sha1 (which is the current default). In the cmdline, we put
in "ima_hash=sha256 ima_template=ima-ng". The expected behavior would be
that ima starts with ima-ng as the template and sha256 as the hash
algorithm. However, during the processing of "ima_hash=",
"ima_template=" has not been processed yet, and hash_setup would check
the configured hash algorithm against the compiled default: ima, and
reject sha256. So at the end, the hash algorithm that is actually used
will be sha1.With template "ima" removed from the configured default, we ensure that
the default tempalte would at least be "ima-ng" which allows for
basically any hash algorithm.This change would not break the algorithm compatibility checks for IMA.
Fixes: 4286587dccd43 ("ima: add Kconfig default measurement list template")
Signed-off-by: GUO Zihua
Cc:
Signed-off-by: Mimi Zohar
Signed-off-by: Greg Kroah-Hartman -
commit 8ba0005ff418ec356e176b26eaa04a6ac755d05b upstream.
The original behavior was to check if the full set of requested accesses
was allowed by at least a rule of every relevant layer. This didn't
take into account requests for multiple accesses and same-layer rules
allowing the union of these accesses in a complementary way. As a
result, multiple accesses requested on a file hierarchy matching rules
that, together, allowed these accesses, but without a unique rule
allowing all of them, was illegitimately denied. This case should be
rare in practice and it can only be triggered by the path_rename or
file_open hook implementations.For instance, if, for the same layer, a rule allows execution
beneath /a/b and another rule allows read beneath /a, requesting access
to read and execute at the same time for /a/b should be allowed for this
layer.This was an inconsistency because the union of same-layer rule accesses
was already allowed if requested once at a time anyway.This fix changes the way allowed accesses are gathered over a path walk.
To take into account all these rule accesses, we store in a matrix all
layer granting the set of requested accesses, according to the handled
accesses. To avoid heap allocation, we use an array on the stack which
is 2*13 bytes. A following commit bringing the LANDLOCK_ACCESS_FS_REFER
access right will increase this size to reach 112 bytes (2*14*4) in case
of link or rename actions.Add a new layout1.layer_rule_unions test to check that accesses from
different rules pertaining to the same layer are ORed in a file
hierarchy. Also test that it is not the case for rules from different
layers.Reviewed-by: Paul Moore
Link: https://lore.kernel.org/r/20220506161102.525323-5-mic@digikod.net
Cc: stable@vger.kernel.org
Signed-off-by: Mickaël Salaün
Signed-off-by: Greg Kroah-Hartman -
commit 2cd7cd6eed88b8383cfddce589afe9c0ae1d19b4 upstream.
This refactoring will be useful in a following commit.
Reviewed-by: Paul Moore
Link: https://lore.kernel.org/r/20220506161102.525323-4-mic@digikod.net
Cc: stable@vger.kernel.org
Signed-off-by: Mickaël Salaün
Signed-off-by: Greg Kroah-Hartman -
commit 75c542d6c6cc48720376862d5496d51509160dfd upstream.
The maximum number of nested Landlock domains is currently 64. Because
of the following fix and to help reduce the stack size, let's reduce it
to 16. This seems large enough for a lot of use cases (e.g. sandboxed
init service, spawning a sandboxed SSH service, in nested sandboxed
containers). Reducing the number of nested domains may also help to
discover misuse of Landlock (e.g. creating a domain per rule).Add and use a dedicated layer_mask_t typedef to fit with the number of
layers. This might be useful when changing it and to keep it consistent
with the maximum number of layers.Reviewed-by: Paul Moore
Link: https://lore.kernel.org/r/20220506161102.525323-3-mic@digikod.net
Cc: stable@vger.kernel.org
Signed-off-by: Mickaël Salaün
Signed-off-by: Greg Kroah-Hartman -
commit 5f2ff33e10843ef51275c8611bdb7b49537aba5d upstream.
Create and use the access_mask_t typedef to enforce a consistent access
mask size and uniformly use a 16-bits type. This will helps transition
to a 32-bits value one day.Add a build check to make sure all (filesystem) access rights fit in.
This will be extended with a following commit.Reviewed-by: Paul Moore
Link: https://lore.kernel.org/r/20220506161102.525323-2-mic@digikod.net
Cc: stable@vger.kernel.org
Signed-off-by: Mickaël Salaün
Signed-off-by: Greg Kroah-Hartman -
commit eba39ca4b155c54adf471a69e91799cc1727873f upstream.
According to the Landlock goal to be a security feature available to
unprivileges processes, it makes more sense to first check for
no_new_privs before checking anything else (i.e. syscall arguments).Merge inval_fd_enforce and unpriv_enforce_without_no_new_privs tests
into the new restrict_self_checks_ordering. This is similar to the
previous commit checking other syscalls.Link: https://lore.kernel.org/r/20220506160820.524344-10-mic@digikod.net
Cc: stable@vger.kernel.org
Signed-off-by: Mickaël Salaün
Signed-off-by: Greg Kroah-Hartman -
commit 589172e5636c4d16c40b90e87543d43defe2d968 upstream.
This makes more sense to first check the ruleset FD and then the rule
attribute. It will be useful to factor out code for other rule types.Add inval_add_rule_arguments tests, extension of empty_path_beneath_attr
tests, to also check error ordering for landlock_add_rule(2).Link: https://lore.kernel.org/r/20220506160820.524344-9-mic@digikod.net
Cc: stable@vger.kernel.org
Signed-off-by: Mickaël Salaün
Signed-off-by: Greg Kroah-Hartman -
commit a13e248ff90e81e9322406c0e618cf2168702f4e upstream.
It is not mandatory to pass a file descriptor obtained with the O_PATH
flag. Also, replace rule's accesses with ruleset's accesses.Link: https://lore.kernel.org/r/20220506160820.524344-2-mic@digikod.net
Cc: stable@vger.kernel.org
Signed-off-by: Mickaël Salaün
Signed-off-by: Greg Kroah-Hartman -
commit 06a1c40a09a8dded4bf0e7e3ccbda6bddcccd7c8 upstream.
Let's follow a consistent and documented coding style. Everything may
not be to our liking but it is better than tacit knowledge. Moreover,
this will help maintain style consistency between different developers.This contains only whitespace changes.
Automatically formatted with:
clang-format-14 -i security/landlock/*.[ch] include/uapi/linux/landlock.hLink: https://lore.kernel.org/r/20220506160513.523257-3-mic@digikod.net
Cc: stable@vger.kernel.org
Signed-off-by: Mickaël Salaün
Signed-off-by: Greg Kroah-Hartman -
commit 6cc2df8e3a3967e7c13a424f87f6efb1d4a62d80 upstream.
In preparation to a following commit, add clang-format on and
clang-format off stanzas around constant definitions. This enables to
keep aligned values, which is much more readable than packed
definitions.Link: https://lore.kernel.org/r/20220506160513.523257-2-mic@digikod.net
Cc: stable@vger.kernel.org
Signed-off-by: Mickaël Salaün
Signed-off-by: Greg Kroah-Hartman -
commit 155ca952c7ca19aa32ecfb7373a32bbc2e1ec6eb upstream.
On Apple T2 Macs, when Linux attempts to read the db and dbx efi variables
at early boot to load UEFI Secure Boot certificates, a page fault occurs
in Apple firmware code and EFI runtime services are disabled with the
following logs:[Firmware Bug]: Page fault caused by firmware at PA: 0xffffb1edc0068000
WARNING: CPU: 3 PID: 104 at arch/x86/platform/efi/quirks.c:735 efi_crash_gracefully_on_page_fault+0x50/0xf0
(Removed some logs from here)
Call Trace:
page_fault_oops+0x4f/0x2c0
? search_bpf_extables+0x6b/0x80
? search_module_extables+0x50/0x80
? search_exception_tables+0x5b/0x60
kernelmode_fixup_or_oops+0x9e/0x110
__bad_area_nosemaphore+0x155/0x190
bad_area_nosemaphore+0x16/0x20
do_kern_addr_fault+0x8c/0xa0
exc_page_fault+0xd8/0x180
asm_exc_page_fault+0x1e/0x30
(Removed some logs from here)
? __efi_call+0x28/0x30
? switch_mm+0x20/0x30
? efi_call_rts+0x19a/0x8e0
? process_one_work+0x222/0x3f0
? worker_thread+0x4a/0x3d0
? kthread+0x17a/0x1a0
? process_one_work+0x3f0/0x3f0
? set_kthread_struct+0x40/0x40
? ret_from_fork+0x22/0x30
---[ end trace 1f82023595a5927f ]---
efi: Froze efi_rts_wq and disabled EFI Runtime Services
integrity: Couldn't get size: 0x8000000000000015
integrity: MODSIGN: Couldn't get UEFI db list
efi: EFI Runtime Services are disabled!
integrity: Couldn't get size: 0x8000000000000015
integrity: Couldn't get UEFI dbx list
integrity: Couldn't get size: 0x8000000000000015
integrity: Couldn't get mokx list
integrity: Couldn't get size: 0x80000000So we avoid reading these UEFI variables and thus prevent the crash.
Cc: stable@vger.kernel.org
Signed-off-by: Aditya Garg
Reviewed-by: Mimi Zohar
Signed-off-by: Mimi Zohar
Signed-off-by: Greg Kroah-Hartman
25 May, 2022
2 commits
-
commit eadb2f47a3ced5c64b23b90fd2a3463f63726066 upstream.
KGDB and KDB allow read and write access to kernel memory, and thus
should be restricted during lockdown. An attacker with access to a
serial port (for example, via a hypervisor console, which some cloud
vendors provide over the network) could trigger the debugger so it is
important that the debugger respect the lockdown mode when/if it is
triggered.Fix this by integrating lockdown into kdb's existing permissions
mechanism. Unfortunately kgdb does not have any permissions mechanism
(although it certainly could be added later) so, for now, kgdb is simply
and brutally disabled by immediately exiting the gdb stub without taking
any action.For lockdowns established early in the boot (e.g. the normal case) then
this should be fine but on systems where kgdb has set breakpoints before
the lockdown is enacted than "bad things" will happen.CVE: CVE-2022-21499
Co-developed-by: Stephen Brennan
Signed-off-by: Stephen Brennan
Reviewed-by: Douglas Anderson
Signed-off-by: Daniel Thompson
Signed-off-by: Linus Torvalds
Signed-off-by: Greg Kroah-Hartman -
commit 6254bd3db316c9ccb3b05caa8b438be63245466f upstream.
The code attempts to free the 'new' pointer using kmem_cache_free(),
which is wrong because this function isn't responsible of freeing it.
Instead, the function should free new->htable and clear the contents of
*new (to prevent double-free).Cc: stable@vger.kernel.org
Fixes: c7c556f1e81b ("selinux: refactor changing booleans")
Reported-by: Wander Lairson Costa
Signed-off-by: Ondrej Mosnacek
Signed-off-by: Paul Moore
Signed-off-by: Greg Kroah-Hartman
08 Apr, 2022
13 commits
-
[ Upstream commit a5cd1ab7ab679d252a6d2f483eee7d45ebf2040c ]
Remove inappropriate use of ntohs() and assign the
port value directly.Reported-by: kernel test robot
Signed-off-by: Casey Schaufler
Signed-off-by: Sasha Levin -
[ Upstream commit 65881e1db4e948614d9eb195b8e1197339822949 ]
These ioctls are equivalent to fcntl(fd, F_SETFD, flags), which SELinux
always allows too. Furthermore, a failed FIOCLEX could result in a file
descriptor being leaked to a process that should not have access to it.As this patch removes access controls, a policy capability needs to be
enabled in policy to always allow these ioctls.Based-on-patch-by: Demi Marie Obenour
Signed-off-by: Richard Haines
[PM: subject line tweak]
Signed-off-by: Paul Moore
Signed-off-by: Sasha Levin -
[ Upstream commit b97df7c098c531010e445da88d02b7bf7bf59ef6 ]
security_sid_to_context() expects a pointer to an u32 as the address
where to store the length of the computed context.Reported by sparse:
security/selinux/xfrm.c:359:39: warning: incorrect type in arg 4
(different signedness)
security/selinux/xfrm.c:359:39: expected unsigned int
[usertype] *scontext_len
security/selinux/xfrm.c:359:39: got int *Signed-off-by: Christian Göttsche
[PM: wrapped commit description]
Signed-off-by: Paul Moore
Signed-off-by: Sasha Levin -
[ Upstream commit ecff30575b5ad0eda149aadad247b7f75411fd47 ]
The usual LSM hook "bail on fail" scheme doesn't work for cases where
a security module may return an error code indicating that it does not
recognize an input. In this particular case Smack sees a mount option
that it recognizes, and returns 0. A call to a BPF hook follows, which
returns -ENOPARAM, which confuses the caller because Smack has processed
its data.The SELinux hook incorrectly returns 1 on success. There was a time
when this was correct, however the current expectation is that it
return 0 on success. This is repaired.Reported-by: syzbot+d1e3b1d92d25abf97943@syzkaller.appspotmail.com
Signed-off-by: Casey Schaufler
Acked-by: James Morris
Signed-off-by: Paul Moore
Signed-off-by: Sasha Levin -
[ Upstream commit 39844b7e3084baecef52d1498b5fa81afa2cefa9 ]
__setup() handlers should return 1 if the parameter is handled.
Returning 0 causes the entire string to be added to init's
environment strings (limited to 32 strings), unnecessarily polluting it.Using the documented strings "TOMOYO_loader=string1" and
"TOMOYO_trigger=string2" causes an Unknown parameter message:
Unknown kernel command line parameters
"BOOT_IMAGE=/boot/bzImage-517rc5 TOMOYO_loader=string1 \
TOMOYO_trigger=string2", will be passed to user space.and these strings are added to init's environment string space:
Run /sbin/init as init process
with arguments:
/sbin/init
with environment:
HOME=/
TERM=linux
BOOT_IMAGE=/boot/bzImage-517rc5
TOMOYO_loader=string1
TOMOYO_trigger=string2With this change, these __setup handlers act as expected,
and init's environment is not polluted with these strings.Fixes: 0e4ae0e0dec63 ("TOMOYO: Make several options configurable.")
Signed-off-by: Randy Dunlap
Reported-by: Igor Zhbanov
Link: https://lore.kernel.org/r/64644a2f-4a20-bab3-1e15-3b2cdd0defe3@omprussia.ru
Cc: James Morris
Cc: Kentaro Takeda
Cc: tomoyo-dev-en@lists.osdn.me
Cc: "Serge E. Hallyn"
Signed-off-by: Tetsuo Handa
Signed-off-by: Sasha Levin -
[ Upstream commit c5d1ed846e15090bc90dfdaafc07eac066e070bb ]
If one loads and unloads the trusted module, trusted_key_exit can be
NULL. Call it through static_call_cond() to avoid a kernel trap.Fixes: 5d0682be3189 ("KEYS: trusted: Add generic trusted keys framework")
Signed-off-by: Dave Kleikamp
Cc: Sumit Garg
Cc: James Bottomley
Cc: Jarkko Sakkinen
Cc: Mimi Zohar
Cc: David Howells
Cc: James Morris
Cc: "Serge E. Hallyn"
Cc: linux-integrity@vger.kernel.org
Cc: keyrings@vger.kernel.org
Cc: linux-security-module@vger.kernel.org
Reviewed-by: Jarkko Sakkinen
Signed-off-by: Jarkko Sakkinen
Signed-off-by: Sasha Levin -
[ Upstream commit 969a26446bcd142faedfe8c6f41cd7668596c1fa ]
Before this commit the kernel could end up with no trusted key sources
even though both of the currently supported backends (TPM and TEE) were
compiled as modules. This manifested in the trusted key type not being
registered at all.When checking if a CONFIG_… preprocessor variable is defined we only
test for the builtin (=y) case and not the module (=m) case. By using
the IS_REACHABLE() macro we do test for both cases.Fixes: 5d0682be3189 ("KEYS: trusted: Add generic trusted keys framework")
Reviewed-by: Jarkko Sakkinen
Reviewed-by: Ahmad Fatoum
Reviewed-by: Sumit Garg
Signed-off-by: Andreas Rammhold
Tested-by: Ahmad Fatoum
Signed-off-by: Ahmad Fatoum
Signed-off-by: Jarkko Sakkinen
Signed-off-by: Sasha Levin -
[ Upstream commit f2544f5e6c691679d56bb38637d2f347075b36fa ]
__setup() handlers should return 1 if the parameter is handled.
Returning 0 causes the entire string to be added to init's
environment strings (limited to 32 strings), unnecessarily polluting it.Using the documented string "evm=fix" causes an Unknown parameter message:
Unknown kernel command line parameters
"BOOT_IMAGE=/boot/bzImage-517rc5 evm=fix", will be passed to user space.and that string is added to init's environment string space:
Run /sbin/init as init process
with arguments:
/sbin/init
with environment:
HOME=/
TERM=linux
BOOT_IMAGE=/boot/bzImage-517rc5
evm=fixWith this change, using "evm=fix" acts as expected and an invalid
option ("evm=evm") causes a warning to be printed:
evm: invalid "evm" mode
but init's environment is not polluted with this string, as expected.Fixes: 7102ebcd65c1 ("evm: permit only valid security.evm xattrs to be updated")
Signed-off-by: Randy Dunlap
Reported-by: Igor Zhbanov
Link: lore.kernel.org/r/64644a2f-4a20-bab3-1e15-3b2cdd0defe3@omprussia.ru
Signed-off-by: Mimi Zohar
Signed-off-by: Sasha Levin -
[ Upstream commit b8b87fd954b4b1bdd2d739c8f50bf685351a1a94 ]
selinux_sb_mnt_opts_compat() is called under the sb_lock spinlock and
shouldn't be performing any memory allocations. Fix this by parsing the
sids at the same time we're chopping up the security mount options
string and then using the pre-parsed sids when doing the comparison.Fixes: cc274ae7763d ("selinux: fix sleeping function called from invalid context")
Fixes: 69c4a42d72eb ("lsm,selinux: add new hook to compare new mount to an existing mount")
Signed-off-by: Scott Mayhew
Signed-off-by: Paul Moore
Signed-off-by: Sasha Levin -
[ Upstream commit bcb62828e3e8c813b6613db6eb7fd9657db248fc ]
sel_make_avc_files() might fail and return a negative errno value on
memory allocation failures. Re-add the check of the return value,
dropped in 66f8e2f03c02 ("selinux: sidtab reverse lookup hash table").Reported by clang-analyzer:
security/selinux/selinuxfs.c:2129:2: warning: Value stored to
'ret' is never read [deadcode.DeadStores]
ret = sel_make_avc_files(dentry);
^ ~~~~~~~~~~~~~~~~~~~~~~~~~~Fixes: 66f8e2f03c02 ("selinux: sidtab reverse lookup hash table")
Signed-off-by: Christian Göttsche
Reviewed-by: Nick Desaulniers
[PM: description line wrapping, added proper commit ref]
Signed-off-by: Paul Moore
Signed-off-by: Sasha Levin -
[ Upstream commit 0266c25e7c2821181b610595df42cbca6bc93cb8 ]
LSM blob has been involved for superblock's security struct. So fix the
remaining direct access to sb->s_security by using the LSM blob
mechanism.Fixes: 08abe46b2cfc ("selinux: fall back to SECURITY_FS_USE_GENFS if no xattr support")
Fixes: 69c4a42d72eb ("lsm,selinux: add new hook to compare new mount to an existing mount")
Signed-off-by: GONG, Ruiqi
Reviewed-by: Casey Schaufler
Signed-off-by: Paul Moore
Signed-off-by: Sasha Levin -
commit aea0b9f2486da8497f35c7114b764bf55e17c7ea upstream.
Make the name of the anon inode fd "[landlock-ruleset]" instead of
"landlock-ruleset". This is minor but most anon inode fds already
carry square brackets around their name:[eventfd]
[eventpoll]
[fanotify]
[fscontext]
[io_uring]
[pidfd]
[signalfd]
[timerfd]
[userfaultfd]For the sake of consistency lets do the same for the landlock-ruleset anon
inode fd that comes with landlock. We did the same in
1cdc415f1083 ("uapi, fsopen: use square brackets around "fscontext" [ver #2]")
for the new mount api.Cc: linux-security-module@vger.kernel.org
Signed-off-by: Christian Brauner
Link: https://lore.kernel.org/r/20211011133704.1704369-1-brauner@kernel.org
Cc: stable@vger.kernel.org
Signed-off-by: Mickaël Salaün
Signed-off-by: Greg Kroah-Hartman -
commit c51abd96837f600d8fd940b6ab8e2da578575504 upstream.
In many cases, keyctl_pkey_params_get_2() is validating the user buffer
lengths against the wrong algorithm properties. Fix it to check against
the correct properties.Probably this wasn't noticed before because for all asymmetric keys of
the "public_key" subtype, max_data_size == max_sig_size == max_enc_size
== max_dec_size. However, this isn't necessarily true for the
"asym_tpm" subtype (it should be, but it's not strictly validated). Of
course, future key types could have different values as well.Fixes: 00d60fd3b932 ("KEYS: Provide keyctls to drive the new key type ops for asymmetric keys [ver #2]")
Cc: # v4.20+
Signed-off-by: Eric Biggers
Reviewed-by: Jarkko Sakkinen
Signed-off-by: Jarkko Sakkinen
Signed-off-by: Greg Kroah-Hartman
02 Mar, 2022
1 commit
-
commit ce2fc710c9d2b25afc710f49bb2065b4439a62bc upstream.
mutex_is_locked() tests whether the mutex is locked *by any task*, while
here we want to test if it is held *by the current task*. To avoid
false/missed WARNINGs, use lockdep_assert_is_held() and
lockdep_assert_is_not_held() instead, which do the right thing (though
they are a no-op if CONFIG_LOCKDEP=n).Cc: stable@vger.kernel.org
Fixes: 2554a48f4437 ("selinux: measure state and policy capabilities")
Signed-off-by: Ondrej Mosnacek
Signed-off-by: Paul Moore
Signed-off-by: Greg Kroah-Hartman
16 Feb, 2022
1 commit
-
commit 89677197ae709eb1ab3646952c44f6a171c9e74c upstream.
Before printing a policy rule scan for inactive LSM labels in the policy
rule. Inactive LSM labels are identified by args_p != NULL and
rule == NULL.Fixes: 483ec26eed42 ("ima: ima/lsm policy rule loading logic bug fixes")
Signed-off-by: Stefan Berger
Cc: # v5.6+
Acked-by: Christian Brauner
[zohar@linux.ibm.com: Updated "Fixes" tag]
Signed-off-by: Mimi Zohar
Signed-off-by: Greg Kroah-Hartman
