- 28 2月, 2018 1 次提交
-
-
由 Kirill Tkhai 提交于
These pernet_operations only register and unregister nf hooks. So, they are able to be marked as async. Signed-off-by: NKirill Tkhai <ktkhai@virtuozzo.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
- 23 2月, 2018 1 次提交
-
-
由 Randy Dunlap 提交于
security/integrity/digsig.c has build errors on some $ARCH due to a missing header file, so add it. security/integrity/digsig.c:146:2: error: implicit declaration of function 'vfree' [-Werror=implicit-function-declaration] Reported-by: NMichael Ellerman <mpe@ellerman.id.au> Signed-off-by: NRandy Dunlap <rdunlap@infradead.org> Cc: Mimi Zohar <zohar@linux.vnet.ibm.com> Cc: linux-integrity@vger.kernel.org Link: http://kisskb.ellerman.id.au/kisskb/head/13396/Signed-off-by: NJames Morris <james.morris@microsoft.com>
-
- 22 2月, 2018 1 次提交
-
-
由 David Howells 提交于
kmalloc() can't always allocate large enough buffers for big_key to use for crypto (1MB + some metadata) so we cannot use that to allocate the buffer. Further, vmalloc'd pages can't be passed to sg_init_one() and the aead crypto accessors cannot be called progressively and must be passed all the data in one go (which means we can't pass the data in one block at a time). Fix this by allocating the buffer pages individually and passing them through a multientry scatterlist to the crypto layer. This has the bonus advantage that we don't have to allocate a contiguous series of pages. We then vmap() the page list and pass that through to the VFS read/write routines. This can trigger a warning: WARNING: CPU: 0 PID: 60912 at mm/page_alloc.c:3883 __alloc_pages_nodemask+0xb7c/0x15f8 ([<00000000002acbb6>] __alloc_pages_nodemask+0x1ee/0x15f8) [<00000000002dd356>] kmalloc_order+0x46/0x90 [<00000000002dd3e0>] kmalloc_order_trace+0x40/0x1f8 [<0000000000326a10>] __kmalloc+0x430/0x4c0 [<00000000004343e4>] big_key_preparse+0x7c/0x210 [<000000000042c040>] key_create_or_update+0x128/0x420 [<000000000042e52c>] SyS_add_key+0x124/0x220 [<00000000007bba2c>] system_call+0xc4/0x2b0 from the keyctl/padd/useradd test of the keyutils testsuite on s390x. Note that it might be better to shovel data through in page-sized lumps instead as there's no particular need to use a monolithic buffer unless the kernel itself wants to access the data. Fixes: 13100a72 ("Security: Keys: Big keys stored encrypted") Reported-by: NPaul Bunyan <pbunyan@redhat.com> Signed-off-by: NDavid Howells <dhowells@redhat.com> cc: Kirill Marinushkin <k.marinushkin@gmail.com>
-
- 13 2月, 2018 1 次提交
-
-
由 Denys Vlasenko 提交于
Changes since v1: Added changes in these files: drivers/infiniband/hw/usnic/usnic_transport.c drivers/staging/lustre/lnet/lnet/lib-socket.c drivers/target/iscsi/iscsi_target_login.c drivers/vhost/net.c fs/dlm/lowcomms.c fs/ocfs2/cluster/tcp.c security/tomoyo/network.c Before: All these functions either return a negative error indicator, or store length of sockaddr into "int *socklen" parameter and return zero on success. "int *socklen" parameter is awkward. For example, if caller does not care, it still needs to provide on-stack storage for the value it does not need. None of the many FOO_getname() functions of various protocols ever used old value of *socklen. They always just overwrite it. This change drops this parameter, and makes all these functions, on success, return length of sockaddr. It's always >= 0 and can be differentiated from an error. Tests in callers are changed from "if (err)" to "if (err < 0)", where needed. rpc_sockname() lost "int buflen" parameter, since its only use was to be passed to kernel_getsockname() as &buflen and subsequently not used in any way. Userspace API is not changed. text data bss dec hex filename 30108430 2633624 873672 33615726 200ef6e vmlinux.before.o 30108109 2633612 873672 33615393 200ee21 vmlinux.o Signed-off-by: NDenys Vlasenko <dvlasenk@redhat.com> CC: David S. Miller <davem@davemloft.net> CC: linux-kernel@vger.kernel.org CC: netdev@vger.kernel.org CC: linux-bluetooth@vger.kernel.org CC: linux-decnet-user@lists.sourceforge.net CC: linux-wireless@vger.kernel.org CC: linux-rdma@vger.kernel.org CC: linux-sctp@vger.kernel.org CC: linux-nfs@vger.kernel.org CC: linux-x25@vger.kernel.org Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
- 12 2月, 2018 1 次提交
-
-
由 Linus Torvalds 提交于
This is the mindless scripted replacement of kernel use of POLL* variables as described by Al, done by this script: for V in IN OUT PRI ERR RDNORM RDBAND WRNORM WRBAND HUP RDHUP NVAL MSG; do L=`git grep -l -w POLL$V | grep -v '^t' | grep -v /um/ | grep -v '^sa' | grep -v '/poll.h$'|grep -v '^D'` for f in $L; do sed -i "-es/^\([^\"]*\)\(\<POLL$V\>\)/\\1E\\2/" $f; done done with de-mangling cleanups yet to come. NOTE! On almost all architectures, the EPOLL* constants have the same values as the POLL* constants do. But they keyword here is "almost". For various bad reasons they aren't the same, and epoll() doesn't actually work quite correctly in some cases due to this on Sparc et al. The next patch from Al will sort out the final differences, and we should be all done. Scripted-by: NAl Viro <viro@zeniv.linux.org.uk> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
- 07 2月, 2018 1 次提交
-
-
由 Mike Rapoport 提交于
There are several functions that do find_task_by_vpid() followed by get_task_struct(). We can use a helper function instead. Link: http://lkml.kernel.org/r/1509602027-11337-1-git-send-email-rppt@linux.vnet.ibm.comSigned-off-by: NMike Rapoport <rppt@linux.vnet.ibm.com> Acked-by: NOleg Nesterov <oleg@redhat.com> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
- 02 2月, 2018 1 次提交
-
-
由 Mimi Zohar 提交于
Intermittently security.ima is not being written for new files. This patch re-initializes the new slab iint->atomic_flags field before freeing it. Fixes: commit 0d73a552 ("ima: re-introduce own integrity cache lock") Signed-off-by: NMimi Zohar <zohar@linux.vnet.ibm.com> Signed-off-by: NJames Morris <jmorris@namei.org>
-
- 01 2月, 2018 1 次提交
-
-
由 Goffredo Baroncelli 提交于
The function inode_cmp_iversion{+raw} is counter-intuitive, because it returns true when the counters are different and false when these are equal. Rename it to inode_eq_iversion{+raw}, which will returns true when the counters are equal and false otherwise. Signed-off-by: NGoffredo Baroncelli <kreijack@inwind.it> Signed-off-by: NJeff Layton <jlayton@redhat.com>
-
- 29 1月, 2018 1 次提交
-
-
由 Jeff Layton 提交于
Signed-off-by: NJeff Layton <jlayton@redhat.com>
-
- 19 1月, 2018 1 次提交
-
-
由 Mike Rapoport 提交于
The switch to uuid_t invereted the logic of verfication that &entry->fsuuid is zero during parsing of "fsuuid=" rule. Instead of making sure the &entry->fsuuid field is not attempted to be overwritten, we bail out for perfectly correct rule. Fixes: 787d8c53 ("ima/policy: switch to use uuid_t") Signed-off-by: NMike Rapoport <rppt@linux.vnet.ibm.com> Cc: stable@vger.kernel.org Signed-off-by: NMimi Zohar <zohar@linux.vnet.ibm.com>
-
- 16 1月, 2018 1 次提交
-
-
由 Kees Cook 提交于
This introduces CONFIG_HARDENED_USERCOPY_FALLBACK to control the behavior of hardened usercopy whitelist violations. By default, whitelist violations will continue to WARN() so that any bad or missing usercopy whitelists can be discovered without being too disruptive. If this config is disabled at build time or a system is booted with "slab_common.usercopy_fallback=0", usercopy whitelists will BUG() instead of WARN(). This is useful for admins that want to use usercopy whitelists immediately. Suggested-by: NMatthew Garrett <mjg59@google.com> Signed-off-by: NKees Cook <keescook@chromium.org>
-
- 14 1月, 2018 1 次提交
-
-
由 W. Trevor King 提交于
When the config option for PTI was added a reference to documentation was added as well. But the documentation did not exist at that point. The final documentation has a different file name. Fix it up to point to the proper file. Fixes: 385ce0ea ("x86/mm/pti: Add Kconfig") Signed-off-by: NW. Trevor King <wking@tremily.us> Signed-off-by: NThomas Gleixner <tglx@linutronix.de> Cc: Dave Hansen <dave.hansen@linux.intel.com> Cc: linux-mm@kvack.org Cc: linux-security-module@vger.kernel.org Cc: James Morris <james.l.morris@oracle.com> Cc: "Serge E. Hallyn" <serge@hallyn.com> Cc: stable@vger.kernel.org Link: https://lkml.kernel.org/r/3009cc8ccbddcd897ec1e0cb6dda524929de0d14.1515799398.git.wking@tremily.us
-
- 13 1月, 2018 2 次提交
-
-
由 Matthew Garrett 提交于
The intended behaviour in apparmor profile matching is to flag a conflict if two profiles match equally well. However, right now a conflict is generated if another profile has the same match length even if that profile doesn't actually match. Fix the logic so we only generate a conflict if the profiles match. Fixes: 844b8292 ("apparmor: ensure that undecidable profile attachments fail") Cc: Stable <stable@vger.kernel.org> Signed-off-by: NMatthew Garrett <mjg59@google.com> Signed-off-by: NJohn Johansen <john.johansen@canonical.com>
-
由 John Johansen 提交于
Given a label with a profile stack of A//&B or A//&C ... A ptrace rule should be able to specify a generic trace pattern with a rule like ptrace trace A//&**, however this is failing because while the correct label match routine is called, it is being done post label decomposition so it is always being done against a profile instead of the stacked label. To fix this refactor the cross check to pass the full peer label in to the label_match. Fixes: 290f458a ("apparmor: allow ptrace checks to be finer grained than just capability") Cc: Stable <stable@vger.kernel.org> Reported-by: NMatthew Garrett <mjg59@google.com> Tested-by: NMatthew Garrett <mjg59@google.com> Signed-off-by: NJohn Johansen <john.johansen@canonical.com>
-
- 11 1月, 2018 1 次提交
-
-
由 Casey Schaufler 提交于
Smack: Privilege check on key operations Operations on key objects are subjected to Smack policy even if the process is privileged. This is inconsistent with the general behavior of Smack and may cause issues with authentication by privileged daemons. This patch allows processes with CAP_MAC_OVERRIDE to access keys even if the Smack rules indicate otherwise. Reported-by: NJose Bollo <jobol@nonadev.net> Signed-off-by: NCasey Schaufler <casey@schaufler-ca.com>
-
- 08 1月, 2018 1 次提交
-
-
由 Jarkko Sakkinen 提交于
Device number (the character device index) is not a stable identifier for a TPM chip. That is the reason why every call site passes TPM_ANY_NUM to tpm_chip_find_get(). This commit changes the API in a way that instead a struct tpm_chip instance is given and NULL means the default chip. In addition, this commit refines the documentation to be up to date with the implementation. Suggested-by: Jason Gunthorpe <jgunthorpe@obsidianresearch.com> (@chip_num -> @chip part) Signed-off-by: NJarkko Sakkinen <jarkko.sakkinen@linux.intel.com> Reviewed-by: NJason Gunthorpe <jgg@ziepe.ca> Tested-by: NPrasannaKumar Muralidharan <prasannatsmkumar@gmail.com>
-
- 06 1月, 2018 1 次提交
-
-
由 John Johansen 提交于
When the mount code was refactored for Labels it was not correctly updated to check whether policy supported mediation of the mount class. This causes a regression when the kernel feature set is reported as supporting mount and policy is pinned to a feature set that does not support mount mediation. BugLink: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=882697#41 Fixes: 2ea3ffb7 ("apparmor: add mount mediation") Reported-by: NFabian Grünbichler <f.gruenbichler@proxmox.com> Cc: Stable <stable@vger.kernel.org> Signed-off-by: NJohn Johansen <john.johansen@canonical.com>
-
- 03 1月, 2018 1 次提交
-
-
由 Thomas Gleixner 提交于
This really want's to be enabled by default. Users who know what they are doing can disable it either in the config or on the kernel command line. Signed-off-by: NThomas Gleixner <tglx@linutronix.de> Cc: stable@vger.kernel.org
-
- 02 1月, 2018 1 次提交
-
-
由 Eric Biggers 提交于
If userspace attempted to set a "security.capability" xattr shorter than 4 bytes (e.g. 'setfattr -n security.capability -v x file'), then cap_convert_nscap() read past the end of the buffer containing the xattr value because it accessed the ->magic_etc field without verifying that the xattr value is long enough to contain that field. Fix it by validating the xattr value size first. This bug was found using syzkaller with KASAN. The KASAN report was as follows (cleaned up slightly): BUG: KASAN: slab-out-of-bounds in cap_convert_nscap+0x514/0x630 security/commoncap.c:498 Read of size 4 at addr ffff88002d8741c0 by task syz-executor1/2852 CPU: 0 PID: 2852 Comm: syz-executor1 Not tainted 4.15.0-rc6-00200-gcc0aac99d977 #253 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.11.0-20171110_100015-anatol 04/01/2014 Call Trace: __dump_stack lib/dump_stack.c:17 [inline] dump_stack+0xe3/0x195 lib/dump_stack.c:53 print_address_description+0x73/0x260 mm/kasan/report.c:252 kasan_report_error mm/kasan/report.c:351 [inline] kasan_report+0x235/0x350 mm/kasan/report.c:409 cap_convert_nscap+0x514/0x630 security/commoncap.c:498 setxattr+0x2bd/0x350 fs/xattr.c:446 path_setxattr+0x168/0x1b0 fs/xattr.c:472 SYSC_setxattr fs/xattr.c:487 [inline] SyS_setxattr+0x36/0x50 fs/xattr.c:483 entry_SYSCALL_64_fastpath+0x18/0x85 Fixes: 8db6c34f ("Introduce v3 namespaced file capabilities") Cc: <stable@vger.kernel.org> # v4.14+ Signed-off-by: NEric Biggers <ebiggers@google.com> Reviewed-by: NSerge Hallyn <serge@hallyn.com> Signed-off-by: NJames Morris <james.l.morris@oracle.com>
-
- 28 12月, 2017 1 次提交
-
-
由 Vasyl Gomonovych 提交于
This patch fixes the warning reported by smatch: security/smack/smack_lsm.c:2872 smack_socket_connect() warn: variable dereferenced before check 'sock->sk' (see line 2869) Signed-off-by: NVasyl Gomonovych <gomonovych@gmail.com> Signed-off-by: NCasey Schaufler <casey@schaufler-ca.com>
-
- 24 12月, 2017 1 次提交
-
-
由 Dave Hansen 提交于
Finally allow CONFIG_PAGE_TABLE_ISOLATION to be enabled. PARAVIRT generally requires that the kernel not manage its own page tables. It also means that the hypervisor and kernel must agree wholeheartedly about what format the page tables are in and what they contain. PAGE_TABLE_ISOLATION, unfortunately, changes the rules and they can not be used together. I've seen conflicting feedback from maintainers lately about whether they want the Kconfig magic to go first or last in a patch series. It's going last here because the partially-applied series leads to kernels that can not boot in a bunch of cases. I did a run through the entire series with CONFIG_PAGE_TABLE_ISOLATION=y to look for build errors, though. [ tglx: Removed SMP and !PARAVIRT dependencies as they not longer exist ] Signed-off-by: NDave Hansen <dave.hansen@linux.intel.com> Signed-off-by: NThomas Gleixner <tglx@linutronix.de> Cc: Andy Lutomirski <luto@kernel.org> Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com> Cc: Borislav Petkov <bp@alien8.de> Cc: Brian Gerst <brgerst@gmail.com> Cc: David Laight <David.Laight@aculab.com> Cc: Denys Vlasenko <dvlasenk@redhat.com> Cc: Eduardo Valentin <eduval@amazon.com> Cc: Greg KH <gregkh@linuxfoundation.org> Cc: H. Peter Anvin <hpa@zytor.com> Cc: Josh Poimboeuf <jpoimboe@redhat.com> Cc: Juergen Gross <jgross@suse.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Will Deacon <will.deacon@arm.com> Cc: aliguori@amazon.com Cc: daniel.gruss@iaik.tugraz.at Cc: hughd@google.com Cc: keescook@google.com Cc: linux-mm@kvack.org Signed-off-by: NIngo Molnar <mingo@kernel.org>
-
- 18 12月, 2017 7 次提交
-
-
由 Kees Cook 提交于
As done for /proc/kcore in commit df04abfd ("fs/proc/kcore.c: Add bounce buffer for ktext data") this adds a bounce buffer when reading memory via /dev/mem. This is needed to allow kernel text memory to be read out when built with CONFIG_HARDENED_USERCOPY (which refuses to read out kernel text) and without CONFIG_STRICT_DEVMEM (which would have refused to read any RAM contents at all). Since this build configuration isn't common (most systems with CONFIG_HARDENED_USERCOPY also have CONFIG_STRICT_DEVMEM), this also tries to inform Kconfig about the recommended settings. This patch is modified from Brad Spengler/PaX Team's changes to /dev/mem code in the last public patch of grsecurity/PaX based on my understanding of the code. Changes or omissions from the original code are mine and don't reflect the original grsecurity/PaX code. Reported-by: NMichael Holzheu <holzheu@linux.vnet.ibm.com> Fixes: f5509cc1 ("mm: Hardened usercopy") Signed-off-by: NKees Cook <keescook@chromium.org> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Sascha Hauer 提交于
i_version is only supported by a filesystem when the SB_I_VERSION flag is set. This patch tests for the SB_I_VERSION flag before using i_version. If we can't use i_version to detect a file change then we must assume the file has changed in the last_writer path and remeasure it. On filesystems without i_version support IMA used to measure a file only once and didn't detect any changes to a file. With this patch IMA now works properly on these filesystems. Signed-off-by: NSascha Hauer <s.hauer@pengutronix.de> Reviewed-by: NJeff Layton <jlayton@redhat.com> Signed-off-by: NMimi Zohar <zohar@linux.vnet.ibm.com>
-
由 Jeff Layton 提交于
The init_once routine memsets the whole object to 0, and then explicitly sets some of the fields to 0 again. Just remove the explicit initializations. Signed-off-by: NJeff Layton <jlayton@redhat.com> Signed-off-by: NMimi Zohar <zohar@linux.vnet.ibm.com>
-
由 Bruno E. O. Meneguele 提交于
Simple but useful message log to the user in case of module appraise is forced and fails due to the lack of file descriptor, that might be caused by kmod calls to compressed modules. Signed-off-by: NBruno E. O. Meneguele <brdeoliv@redhat.com> Signed-off-by: NMimi Zohar <zohar@linux.vnet.ibm.com>
-
由 Roberto Sassu 提交于
ima_rdwr_violation_check() retrieves the full path of a measured file by calling ima_d_path(). If process_measurement() calls this function, it reuses the pointer and passes it to the functions to measure/appraise/audit an accessed file. After commit bc15ed66 ("ima: fix ima_d_path() possible race with rename"), ima_d_path() first tries to retrieve the full path by calling d_absolute_path() and, if there is an error, copies the dentry name to the buffer passed as argument. However, ima_rdwr_violation_check() passes to ima_d_path() the pointer of a local variable. process_measurement() might be reusing the pointer to an area in the stack which may have been already overwritten after ima_rdwr_violation_check() returned. Correct this issue by passing to ima_rdwr_violation_check() the pointer of a buffer declared in process_measurement(). Fixes: bc15ed66 ("ima: fix ima_d_path() possible race with rename") Signed-off-by: NRoberto Sassu <roberto.sassu@huawei.com> Signed-off-by: NMimi Zohar <zohar@linux.vnet.ibm.com>
-
由 Joe Perches 提交于
Line continuations with excess spacing causes unexpected output. Based on commit 6f76b6fc ("CodingStyle: Document the exception of not splitting user-visible strings, for grepping") recommendation. Signed-off-by: NJoe Perches <joe@perches.com> Signed-off-by: NMimi Zohar <zohar@linux.vnet.ibm.com>
-
由 Mimi Zohar 提交于
The builtin ima_appraise_tcb policy, which is specified on the boot command line, can be replaced with a custom policy, normally early in the boot process. Custom policies can be more restrictive in some ways, like requiring file signatures, but can be less restrictive in other ways, like not appraising mutable files. With a less restrictive policy in place, files in the builtin policy might not be hashed and labeled with a security.ima hash. On reboot, files which should be labeled in the ima_appraise_tcb are not labeled, possibly preventing the system from booting properly. To resolve this problem, this patch extends the existing IMA policy actions "measure", "dont_measure", "appraise", "dont_appraise", and "audit" with "hash" and "dont_hash". The new "hash" action will write the file hash as security.ima, but without requiring the file to be appraised as well. For example, the builtin ima_appraise_tcb policy includes the rule, "appraise fowner=0". Adding the "hash fowner=0" rule to a custom policy, will cause the needed file hashes to be calculated and written as security.ima xattrs. Signed-off-by: NMimi Zohar <zohar@linux.vnet.ibm.com> Signed-off-by: NStefan Berger <stefanb@linux.vnet.ibm.com>
-
- 13 12月, 2017 1 次提交
-
-
由 Sascha Hauer 提交于
i_version is only supported by a filesystem when the SB_I_VERSION flag is set. This patch tests for the SB_I_VERSION flag before using i_version. If we can't use i_version to detect a file change then we must assume the file has changed in the last_writer path and remeasure it. On filesystems without i_version support IMA used to measure a file only once and didn't detect any changes to a file. With this patch IMA now works properly on these filesystems. Signed-off-by: NSascha Hauer <s.hauer@pengutronix.de> Reviewed-by: NJeff Layton <jlayton@redhat.com> Signed-off-by: NJeff Layton <jlayton@redhat.com>
-
- 12 12月, 2017 4 次提交
-
-
由 Dmitry Kasatkin 提交于
Before IMA appraisal was introduced, IMA was using own integrity cache lock along with i_mutex. process_measurement and ima_file_free took the iint->mutex first and then the i_mutex, while setxattr, chmod and chown took the locks in reverse order. To resolve the potential deadlock, i_mutex was moved to protect entire IMA functionality and the redundant iint->mutex was eliminated. Solution was based on the assumption that filesystem code does not take i_mutex further. But when file is opened with O_DIRECT flag, direct-io implementation takes i_mutex and produces deadlock. Furthermore, certain other filesystem operations, such as llseek, also take i_mutex. More recently some filesystems have replaced their filesystem specific lock with the global i_rwsem to read a file. As a result, when IMA attempts to calculate the file hash, reading the file attempts to take the i_rwsem again. To resolve O_DIRECT related deadlock problem, this patch re-introduces iint->mutex. But to eliminate the original chmod() related deadlock problem, this patch eliminates the requirement for chmod hooks to take the iint->mutex by introducing additional atomic iint->attr_flags to indicate calling of the hooks. The allowed locking order is to take the iint->mutex first and then the i_rwsem. Original flags were cleared in chmod(), setxattr() or removwxattr() hooks and tested when file was closed or opened again. New atomic flags are set or cleared in those hooks and tested to clear iint->flags on close or on open. Atomic flags are following: * IMA_CHANGE_ATTR - indicates that chATTR() was called (chmod, chown, chgrp) and file attributes have changed. On file open, it causes IMA to clear iint->flags to re-evaluate policy and perform IMA functions again. * IMA_CHANGE_XATTR - indicates that setxattr or removexattr was called and extended attributes have changed. On file open, it causes IMA to clear iint->flags IMA_DONE_MASK to re-appraise. * IMA_UPDATE_XATTR - indicates that security.ima needs to be updated. It is cleared if file policy changes and no update is needed. * IMA_DIGSIG - indicates that file security.ima has signature and file security.ima must not update to file has on file close. * IMA_MUST_MEASURE - indicates the file is in the measurement policy. Fixes: Commit 65523218 ("xfs: remove i_iolock and use i_rwsem in the VFS inode instead") Signed-off-by: NDmitry Kasatkin <dmitry.kasatkin@huawei.com> Signed-off-by: NMimi Zohar <zohar@linux.vnet.ibm.com>
-
由 Matthew Garrett 提交于
The EVM signature includes the inode number and (optionally) the filesystem UUID, making it impractical to ship EVM signatures in packages. This patch adds a new portable format intended to allow distributions to include EVM signatures. It is identical to the existing format but hardcodes the inode and generation numbers to 0 and does not include the filesystem UUID even if the kernel is configured to do so. Removing the inode means that the metadata and signature from one file could be copied to another file without invalidating it. This is avoided by ensuring that an IMA xattr is present during EVM validation. Portable signatures are intended to be immutable - ie, they will never be transformed into HMACs. Based on earlier work by Dmitry Kasatkin and Mikhail Kurinnoi. Signed-off-by: NMatthew Garrett <mjg59@google.com> Cc: Dmitry Kasatkin <dmitry.kasatkin@huawei.com> Cc: Mikhail Kurinnoi <viewizard@viewizard.com> Signed-off-by: NMimi Zohar <zohar@linux.vnet.ibm.com>
-
由 Matthew Garrett 提交于
When EVM is enabled it forbids modification of metadata protected by EVM unless there is already a valid EVM signature. If any modification is made, the kernel will then generate a new EVM HMAC. However, this does not map well on use cases which use only asymmetric EVM signatures, as in this scenario the kernel is unable to generate new signatures. This patch extends the /sys/kernel/security/evm interface to allow userland to request that modification of these xattrs be permitted. This is only permitted if no keys have already been loaded. In this configuration, modifying the metadata will invalidate the EVM appraisal on the file in question. This allows packaging systems to write out new files, set the relevant extended attributes and then move them into place. There's also some refactoring of the use of evm_initialized in order to avoid heading down codepaths that assume there's a key available. Signed-off-by: NMatthew Garrett <mjg59@google.com> Signed-off-by: NMimi Zohar <zohar@linux.vnet.ibm.com>
-
由 Mimi Zohar 提交于
Custom policies can require file signatures based on LSM labels. These files are normally created and only afterwards labeled, requiring them to be signed. Instead of requiring file signatures based on LSM labels, entire filesystems could require file signatures. In this case, we need the ability of writing new files without requiring file signatures. The definition of a "new" file was originally defined as any file with a length of zero. Subsequent patches redefined a "new" file to be based on the FILE_CREATE open flag. By combining the open flag with a file size of zero, this patch relaxes the file signature requirement. Fixes: 1ac202e9 ima: accept previously set IMA_NEW_FILE Signed-off-by: NMimi Zohar <zohar@linux.vnet.ibm.com>
-
- 08 12月, 2017 4 次提交
-
-
由 Eric Biggers 提交于
keyctl_restrict_keyring() allows through a NULL restriction when the "type" is non-NULL, which causes a NULL pointer dereference in asymmetric_lookup_restriction() when it calls strcmp() on the restriction string. But no key types actually use a "NULL restriction" to mean anything, so update keyctl_restrict_keyring() to reject it with EINVAL. Reported-by: Nsyzbot <syzkaller@googlegroups.com> Fixes: 97d3aa0f ("KEYS: Add a lookup_restriction function for the asymmetric key type") Cc: <stable@vger.kernel.org> # v4.12+ Signed-off-by: NEric Biggers <ebiggers@google.com> Signed-off-by: NDavid Howells <dhowells@redhat.com>
-
由 Colin Ian King 提交于
Variable key_ref is being assigned a value that is never read; key_ref is being re-assigned a few statements later. Hence this assignment is redundant and can be removed. Signed-off-by: NColin Ian King <colin.king@canonical.com> Signed-off-by: NDavid Howells <dhowells@redhat.com> Reviewed-by: NJames Morris <james.l.morris@oracle.com>
-
由 Eric Biggers 提交于
When the request_key() syscall is not passed a destination keyring, it links the requested key (if constructed) into the "default" request-key keyring. This should require Write permission to the keyring. However, there is actually no permission check. This can be abused to add keys to any keyring to which only Search permission is granted. This is because Search permission allows joining the keyring. keyctl_set_reqkey_keyring(KEY_REQKEY_DEFL_SESSION_KEYRING) then will set the default request-key keyring to the session keyring. Then, request_key() can be used to add keys to the keyring. Both negatively and positively instantiated keys can be added using this method. Adding negative keys is trivial. Adding a positive key is a bit trickier. It requires that either /sbin/request-key positively instantiates the key, or that another thread adds the key to the process keyring at just the right time, such that request_key() misses it initially but then finds it in construct_alloc_key(). Fix this bug by checking for Write permission to the keyring in construct_get_dest_keyring() when the default keyring is being used. We don't do the permission check for non-default keyrings because that was already done by the earlier call to lookup_user_key(). Also, request_key_and_link() is currently passed a 'struct key *' rather than a key_ref_t, so the "possessed" bit is unavailable. We also don't do the permission check for the "requestor keyring", to continue to support the use case described by commit 8bbf4976 ("KEYS: Alter use of key instantiation link-to-keyring argument") where /sbin/request-key recursively calls request_key() to add keys to the original requestor's destination keyring. (I don't know of any users who actually do that, though...) Fixes: 3e30148c ("[PATCH] Keys: Make request-key create an authorisation key") Cc: <stable@vger.kernel.org> # v2.6.13+ Signed-off-by: NEric Biggers <ebiggers@google.com> Signed-off-by: NDavid Howells <dhowells@redhat.com>
-
由 Eric Biggers 提交于
In request_key_and_link(), in the case where the dest_keyring was explicitly specified, there is no need to get another reference to dest_keyring before calling key_link(), then drop it afterwards. This is because by definition, we already have a reference to dest_keyring. This change is useful because we'll be making construct_get_dest_keyring() able to return an error code, and we don't want to have to handle that error here for no reason. Signed-off-by: NEric Biggers <ebiggers@google.com> Signed-off-by: NDavid Howells <dhowells@redhat.com>
-
- 06 12月, 2017 1 次提交
-
-
由 Paul Moore 提交于
We can't do anything reasonable in security_bounded_transition() if we don't have a policy loaded, and in fact we could run into problems with some of the code inside expecting a policy. Fix these problems like we do many others in security/selinux/ss/services.c by checking to see if the policy is loaded (ss_initialized) and returning quickly if it isn't. Reported-by: Nsyzbot <syzkaller-bugs@googlegroups.com> Signed-off-by: NPaul Moore <paul@paul-moore.com> Acked-by: NStephen Smalley <sds@tycho.nsa.gov> Reviewed-by: NJames Morris <james.l.morris@oracle.com>
-
- 05 12月, 2017 1 次提交
-
-
由 Paul E. McKenney 提交于
Now that the associative-array library properly heads dependency chains, the various smp_read_barrier_depends() calls in security/keys/keyring.c are no longer needed. This commit therefore removes them. Signed-off-by: NPaul E. McKenney <paulmck@linux.vnet.ibm.com> Cc: David Howells <dhowells@redhat.com> Cc: "Serge E. Hallyn" <serge@hallyn.com> Cc: <keyrings@vger.kernel.org> Cc: <linux-security-module@vger.kernel.org> Reviewed-by: NJames Morris <james.l.morris@oracle.com>
-
- 30 11月, 2017 1 次提交
-
-
由 David Miller 提交于
Only IPSEC routes have a non-NULL dst->child pointer. And IPSEC routes are identified by a non-NULL dst->xfrm pointer. Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-