- 08 Aug, 2014 1 commit
-
-
Paul Moore authored
This patch removes the unused return code variable in the netport, netnode, and netif initialization functions. Reported-by: fengguang.wu@intel.com Signed-off-by:
Paul Moore <pmoore@redhat.com>
-
- 01 Aug, 2014 3 commits
-
-
Paul Moore authored
Historically the NetLabel LSM secattr catmap functions and data structures have had very long names which makes a mess of the NetLabel code and anyone who uses NetLabel. This patch renames the catmap functions and structures from "*_secattr_catmap_*" to just "*_catmap_*" which improves things greatly. There are no substantial code or logic changes in this patch. Signed-off-by:
Paul Moore <pmoore@redhat.com> Tested-by:
Casey Schaufler <casey@schaufler-ca.com>
-
Paul Moore authored
The NetLabel secattr catmap functions, and the SELinux import/export glue routines, were broken in many horrible ways and the SELinux glue code fiddled with the NetLabel catmap structures in ways that we probably shouldn't allow. At some point this "worked", but that was likely due to a bit of dumb luck and sub-par testing (both inflicted by yours truly). This patch corrects these problems by basically gutting the code in favor of something less obtuse and restoring the NetLabel abstractions in the SELinux catmap glue code. Everything is working now, and if it decides to break itself in the future this code will be much easier to debug than the code it replaces. One noteworthy side effect of the changes is that it is no longer necessary to allocate a NetLabel catmap before calling one of the NetLabel APIs to set a bit in the catmap. NetLabel will automatically allocate the catmap nodes when needed, resulting in less allocations when the lowest bit is greater than 255 and less code in the LSMs. Cc: stable@vger.kernel.org Reported-by:
Christian Evans <frodox@zoho.com> Signed-off-by:
Paul Moore <pmoore@redhat.com> Tested-by:
Casey Schaufler <casey@schaufler-ca.com>
-
Paul Moore authored
The NetLabel category (catmap) functions have a problem in that they assume categories will be set in an increasing manner, e.g. the next category set will always be larger than the last. Unfortunately, this is not a valid assumption and could result in problems when attempting to set categories less than the startbit in the lowest catmap node. In some cases kernel panics and other nasties can result. This patch corrects the problem by checking for this and allocating a new catmap node instance and placing it at the front of the list. Cc: stable@vger.kernel.org Reported-by:
Christian Evans <frodox@zoho.com> Signed-off-by:
Paul Moore <pmoore@redhat.com> Tested-by:
Casey Schaufler <casey@schaufler-ca.com>
-
- 28 Jul, 2014 2 commits
-
-
Paul Moore authored
This reverts commit 4da6daf4 . Unfortunately, the commit in question caused problems with Bluetooth devices, specifically it caused them to get caught in the newly created BUG_ON() check. The AF_ALG problem still exists, but will be addressed in a future patch. Cc: stable@vger.kernel.org Signed-off-by:
Paul Moore <pmoore@redhat.com>
-
Mimi Zohar authored
Commit fc7c70e0 "KEYS: struct key_preparsed_payload should have two payload pointers" erroneously modified encrypted-keys. This patch reverts the change to that file. Signed-off-by:
Mimi Zohar <zohar@linux.vnet.ibm.com> Signed-off-by:
David Howells <dhowells@redhat.com>
-
- 25 Jul, 2014 2 commits
-
-
Mimi Zohar authored
The "security: introduce kernel_fw_from_file hook" patch defined a new security hook to evaluate any loaded firmware that wasn't built into the kernel. This patch defines ima_fw_from_file(), which is called from the new security hook, to measure and/or appraise the loaded firmware's integrity. Signed-off-by:
Mimi Zohar <zohar@linux.vnet.ibm.com> Signed-off-by:
Kees Cook <keescook@chromium.org>
-
Kees Cook authored
In order to validate the contents of firmware being loaded, there must be a hook to evaluate any loaded firmware that wasn't built into the kernel itself. Without this, there is a risk that a root user could load malicious firmware designed to mount an attack against kernel memory (e.g. via DMA). Signed-off-by:
Kees Cook <keescook@chromium.org> Reviewed-by:
Takashi Iwai <tiwai@suse.de>
-
- 24 Jul, 2014 2 commits
-
-
Eric Paris authored
This is effectively a revert of 7b9a7ec5 plus fixing it a different way... We found, when trying to run an application from an application which had dropped privs that the kernel does security checks on undefined capability bits. This was ESPECIALLY difficult to debug as those undefined bits are hidden from /proc/$PID/status. Consider a root application which drops all capabilities from ALL 4 capability sets. We assume, since the application is going to set eff/perm/inh from an array that it will clear not only the defined caps less than CAP_LAST_CAP, but also the higher 28ish bits which are undefined future capabilities. The BSET gets cleared differently. Instead it is cleared one bit at a time. The problem here is that in security/commoncap.c::cap_task_prctl() we actually check the validity of a capability being read. So any task which attempts to 'read all things set in bset' followed by 'unset all things set in bset' will not even attempt to unset the undefined bits higher than CAP_LAST_CAP. So the 'parent' will look something like: CapInh: 0000000000000000 CapPrm: 0000000000000000 CapEff: 0000000000000000 CapBnd: ffffffc000000000 All of this 'should' be fine. Given that these are undefined bits that aren't supposed to have anything to do with permissions. But they do... So lets now consider a task which cleared the eff/perm/inh completely and cleared all of the valid caps in the bset (but not the invalid caps it couldn't read out of the kernel). We know that this is exactly what the libcap-ng library does and what the go capabilities library does. They both leave you in that above situation if you try to clear all of you capapabilities from all 4 sets. If that root task calls execve() the child task will pick up all caps not blocked by the bset. The bset however does not block bits higher than CAP_LAST_CAP. So now the child task has bits in eff which are not in the parent. These are 'meaningless' undefined bits, but still bits which the parent doesn't have. The problem is now in cred_cap_issubset() (or any operation which does a subset test) as the child, while a subset for valid cap bits, is not a subset for invalid cap bits! So now we set durring commit creds that the child is not dumpable. Given it is 'more priv' than its parent. It also means the parent cannot ptrace the child and other stupidity. The solution here: 1) stop hiding capability bits in status This makes debugging easier! 2) stop giving any task undefined capability bits. it's simple, it you don't put those invalid bits in CAP_FULL_SET you won't get them in init and you won't get them in any other task either. This fixes the cap_issubset() tests and resulting fallout (which made the init task in a docker container untraceable among other things) 3) mask out undefined bits when sys_capset() is called as it might use ~0, ~0 to denote 'all capabilities' for backward/forward compatibility. This lets 'capsh --caps="all=eip" -- -c /bin/bash' run. 4) mask out undefined bit when we read a file capability off of disk as again likely all bits are set in the xattr for forward/backward compatibility. This lets 'setcap all+pe /bin/bash; /bin/bash' run Signed-off-by:
Eric Paris <eparis@redhat.com> Reviewed-by:
Kees Cook <keescook@chromium.org> Cc: Andrew Vagin <avagin@openvz.org> Cc: Andrew G. Morgan <morgan@kernel.org> Cc: Serge E. Hallyn <serge.hallyn@canonical.com> Cc: Kees Cook <keescook@chromium.org> Cc: Steve Grubb <sgrubb@redhat.com> Cc: Dan Walsh <dwalsh@redhat.com> Cc: stable@vger.kernel.org Signed-off-by:
James Morris <james.l.morris@oracle.com>
-
Tetsuo Handa authored
In function cap_task_prctl(), we would allocate a credential unconditionally and then check if we support the requested function. If not we would release this credential with abort_creds() by using RCU method. But on some archs such as powerpc, the sys_prctl is heavily used to get/set the floating point exception mode. So the unnecessary allocating/releasing of credential not only introduce runtime overhead but also do cause OOM due to the RCU implementation. This patch removes abort_creds() from cap_task_prctl() by calling prepare_creds() only when we need to modify it. Reported-by:
Kevin Hao <haokexin@gmail.com> Signed-off-by:
Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> Reviewed-by:
Paul Moore <paul@paul-moore.com> Acked-by:
Serge E. Hallyn <serge.hallyn@ubuntu.com> Reviewed-by:
Kees Cook <keescook@chromium.org> Signed-off-by:
James Morris <james.l.morris@oracle.com>
-
- 22 Jul, 2014 7 commits
-
-
David Howells authored
Provide key preparsing for the request_key_auth key type so that we can make preparsing mandatory. This does nothing as this type can only be set up internally to the kernel. Signed-off-by:
David Howells <dhowells@redhat.com> Acked-by:
Steve Dickson <steved@redhat.com> Acked-by:
Jeff Layton <jlayton@primarydata.com>
-
David Howells authored
Provide key preparsing in the keyring so that we can make preparsing mandatory. For keyrings, however, only an empty payload is permitted. Signed-off-by:
David Howells <dhowells@redhat.com> Acked-by:
Steve Dickson <steved@redhat.com> Acked-by:
Jeff Layton <jlayton@primarydata.com>
-
David Howells authored
Make use of key preparsing in the big key type so that quota size determination can take place prior to keyring locking when a key is being added. Signed-off-by:
David Howells <dhowells@redhat.com> Acked-by:
Steve Dickson <steved@redhat.com>
-
David Howells authored
Make use of key preparsing in user-defined and logon keys so that quota size determination can take place prior to keyring locking when a key is being added. Also the idmapper key types need to change to match as they use the user-defined key type routines. Signed-off-by:
David Howells <dhowells@redhat.com> Acked-by:
Steve Dickson <steved@redhat.com> Acked-by:
Jeff Layton <jlayton@primarydata.com>
-
David Howells authored
Call the ->free_preparse() key type op even after ->preparse() returns an error as it does cleaning up type stuff. Signed-off-by:
David Howells <dhowells@redhat.com> Acked-by:
Steve Dickson <steved@redhat.com> Acked-by:
Jeff Layton <jlayton@primarydata.com> Reviewed-by:
Sage Weil <sage@redhat.com>
-
David Howells authored
Allow a key type's preparsing routine to set the expiry time for a key. Signed-off-by:
David Howells <dhowells@redhat.com> Acked-by:
Steve Dickson <steved@redhat.com> Acked-by:
Jeff Layton <jlayton@primarydata.com> Reviewed-by:
Sage Weil <sage@redhat.com>
-
David Howells authored
struct key_preparsed_payload should have two payload pointers to correspond with those in struct key. Signed-off-by:
David Howells <dhowells@redhat.com> Acked-by:
Steve Dickson <steved@redhat.com> Acked-by:
Jeff Layton <jlayton@primarydata.com> Reviewed-by:
Sage Weil <sage@redhat.com>
-
- 18 Jul, 2014 2 commits
-
-
Kees Cook authored
Since seccomp transitions between threads requires updates to the no_new_privs flag to be atomic, the flag must be part of an atomic flag set. This moves the nnp flag into a separate task field, and introduces accessors. Signed-off-by:
Kees Cook <keescook@chromium.org> Reviewed-by:
Oleg Nesterov <oleg@redhat.com> Reviewed-by:
Andy Lutomirski <luto@amacapital.net>
-
David Howells authored
Provide a generic instantiation function for key types that use the preparse hook. This makes it easier to prereserve key quota before keyrings get locked to retain the new key. Signed-off-by:
David Howells <dhowells@redhat.com> Acked-by:
Steve Dickson <steved@redhat.com> Acked-by:
Jeff Layton <jlayton@primarydata.com> Reviewed-by:
Sage Weil <sage@redhat.com>
-
- 17 Jul, 2014 9 commits
-
-
David Howells authored
Special kernel keys, such as those used to hold DNS results for AFS, CIFS and NFS and those used to hold idmapper results for NFS, used to be 'invalidateable' with key_revoke(). However, since the default permissions for keys were reduced: Commit: 96b5c8fe KEYS: Reduce initial permissions on keys it has become impossible to do this. Add a key flag (KEY_FLAG_ROOT_CAN_INVAL) that will permit a key to be invalidated by root. This should not be used for system keyrings as the garbage collector will try and remove any invalidate key. For system keyrings, KEY_FLAG_ROOT_CAN_CLEAR can be used instead. After this, from userspace, keyctl_invalidate() and "keyctl invalidate" can be used by any possessor of CAP_SYS_ADMIN (typically root) to invalidate DNS and idmapper keys. Invalidated keys are immediately garbage collected and will be immediately rerequested if needed again. Signed-off-by:
David Howells <dhowells@redhat.com> Tested-by:
Steve Dickson <steved@redhat.com>
-
Mimi Zohar authored
Require all keys added to the IMA keyring be signed by an existing trusted key on the system trusted keyring. Changelog v6: - remove ifdef CONFIG_IMA_TRUSTED_KEYRING in C code - Dmitry - update Kconfig dependency and help - select KEYS_DEBUG_PROC_KEYS - Dmitry Changelog v5: - Move integrity_init_keyring() to init_ima() - Dmitry - reset keyring[id] on failure - Dmitry Changelog v1: - don't link IMA trusted keyring to user keyring Changelog: - define stub integrity_init_keyring() function (reported-by Fengguang Wu) - differentiate between regular and trusted keyring names. - replace printk with pr_info (D. Kasatkin) - only make the IMA keyring a trusted keyring (reported-by D. Kastatkin) - define stub integrity_init_keyring() definition based on CONFIG_INTEGRITY_SIGNATURE, not CONFIG_INTEGRITY_ASYMMETRIC_KEYS. (reported-by Jim Davis) Signed-off-by:
Mimi Zohar <zohar@linux.vnet.ibm.com> Signed-off-by:
Dmitry Kasatkin <d.kasatkin@samsung.com> Acked-by:
David Howells <dhowells@redhat.com>
-
Mimi Zohar authored
Dot prefixed keyring names are supposed to be reserved for the kernel, but add_key() calls key_get_type_from_user(), which incorrectly verifies the 'type' field, not the 'description' field. This patch verifies the 'description' field isn't dot prefixed, when creating a new keyring, and removes the dot prefix test in key_get_type_from_user(). Changelog v6: - whitespace and other cleanup Changelog v5: - Only prevent userspace from creating a dot prefixed keyring, not regular keys - Dmitry Reported-by:
Dmitry Kasatkin <d.kasatkin@samsung.com> Signed-off-by:
Mimi Zohar <zohar@linux.vnet.ibm.com> Acked-by:
David Howells <dhowells@redhat.com>
-
Dmitry Kasatkin authored
The asynchronous hash API allows initiating a hash calculation and then performing other tasks, while waiting for the hash calculation to complete. This patch introduces usage of double buffering for simultaneous hashing and reading of the next chunk of data from storage. Changes in v3: - better comments Signed-off-by:
Dmitry Kasatkin <d.kasatkin@samsung.com> Signed-off-by:
Mimi Zohar <zohar@linux.vnet.ibm.com>
-
Dmitry Kasatkin authored
Use of multiple-page collect buffers reduces: 1) the number of block IO requests 2) the number of asynchronous hash update requests Second is important for HW accelerated hashing, because significant amount of time is spent for preparation of hash update operation, which includes configuring acceleration HW, DMA engine, etc... Thus, HW accelerators are more efficient when working on large chunks of data. This patch introduces usage of multi-page collect buffers. Buffer size can be specified using 'ahash_bufsize' module parameter. Default buffer size is 4096 bytes. Changes in v3: - kernel parameter replaced with module parameter Signed-off-by:
Dmitry Kasatkin <d.kasatkin@samsung.com> Signed-off-by:
Mimi Zohar <zohar@linux.vnet.ibm.com>
-
Dmitry Kasatkin authored
Async hash API allows the use of HW acceleration for hash calculation. It may give significant performance gain and/or reduce power consumption, which might be very beneficial for battery powered devices. This patch introduces hash calculation using ahash API. ahash performance depends on the data size and the particular HW. Depending on the specific system, shash performance may be better. This patch defines 'ahash_minsize' module parameter, which is used to define the minimal file size to use with ahash. If this minimum file size is not set or the file is smaller than defined by the parameter, shash will be used. Changes in v3: - kernel parameter replaced with module parameter - pr_crit replaced with pr_crit_ratelimited - more comment changes - Mimi Changes in v2: - ima_ahash_size became as ima_ahash - ahash pre-allocation moved out from __init code to be able to use ahash crypto modules. Ahash allocated once on the first use. - hash calculation falls back to shash if ahash allocation/calculation fails - complex initialization separated from variable declaration - improved comments Signed-off-by:
Dmitry Kasatkin <d.kasatkin@samsung.com> Signed-off-by:
Mimi Zohar <zohar@linux.vnet.ibm.com>
-
Richard Guy Briggs authored
Replace spaces in op keyword labels in log output since userspace audit tools can't parse orphaned keywords. Reported-by:
Steve Grubb <sgrubb@redhat.com> Signed-off-by:
Richard Guy Briggs <rgb@redhat.com> Signed-off-by:
Mimi Zohar <zohar@linux.vnet.ibm.com>
-
Dmitry Kasatkin authored
process_measurement() always calls ima_template_desc_current(), including when an IMA policy has not been defined. This patch delays template descriptor lookup until action is determined. Signed-off-by:
Dmitry Kasatkin <d.kasatkin@samsung.com> Signed-off-by:
Mimi Zohar <zohar@linux.vnet.ibm.com>
-
Dmitry Kasatkin authored
Before 2.6.39 inode->i_readcount was maintained by IMA. It was not atomic and protected using spinlock. For 2.6.39, i_readcount was converted to atomic and maintaining was moved VFS layer. Spinlock for some unclear reason was replaced by i_mutex. After analyzing the code, we came to conclusion that i_mutex locking is unnecessary, especially when an IMA policy has not been defined. This patch removes i_mutex locking from ima_rdwr_violation_check(). Signed-off-by:
Dmitry Kasatkin <d.kasatkin@samsung.com> Signed-off-by:
Mimi Zohar <zohar@linux.vnet.ibm.com>
-
- 16 Jul, 2014 1 commit
-
-
NeilBrown authored
The current "wait_on_bit" interface requires an 'action' function to be provided which does the actual waiting. There are over 20 such functions, many of them identical. Most cases can be satisfied by one of just two functions, one which uses io_schedule() and one which just uses schedule(). So: Rename wait_on_bit and wait_on_bit_lock to wait_on_bit_action and wait_on_bit_lock_action to make it explicit that they need an action function. Introduce new wait_on_bit{,_lock} and wait_on_bit{,_lock}_io which are *not* given an action function but implicitly use a standard one. The decision to error-out if a signal is pending is now made based on the 'mode' argument rather than being encoded in the action function. All instances of the old wait_on_bit and wait_on_bit_lock which can use the new version have been changed accordingly and their action functions have been discarded. wait_on_bit{_lock} does not return any spec...
-
- 15 Jul, 2014 1 commit
-
-
Tejun Heo authored
Currently, cgroup_subsys->base_cftypes is used for both the unified default hierarchy and legacy ones and subsystems can mark each file with either CFTYPE_ONLY_ON_DFL or CFTYPE_INSANE if it has to appear only on one of them. This is quite hairy and error-prone. Also, we may end up exposing interface files to the default hierarchy without thinking it through. cgroup_subsys will grow two separate cftype arrays and apply each only on the hierarchies of the matching type. This will allow organizing cftypes in a lot clearer way and encourage subsystems to scrutinize the interface which is being exposed in the new default hierarchy. In preparation, this patch renames cgroup_subsys->base_cftypes to cgroup_subsys->legacy_cftypes. This patch is pure rename. Signed-off-by:
Tejun Heo <tj@kernel.org> Acked-by:
Neil Horman <nhorman@tuxdriver.com> Acked-by:
Li Zefan <lizefan@huawei.com> Cc: Johannes Weiner <hannes@cmpxchg.org> Cc: Michal Hocko <mhocko@suse.cz> Cc: Vivek Goyal <vgoyal@redhat.com> Cc: Peter Zijlstra <a.p.zijlstra@chello.nl> Cc: Paul Mackerras <paulus@samba.org> Cc: Ingo Molnar <mingo@redhat.com> Cc: Arnaldo Carvalho de Melo <acme@kernel.org> Cc: Aristeu Rozanski <aris@redhat.com> Cc: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
-
- 10 Jul, 2014 1 commit
-
-
Paul Moore authored
The sock_graft() hook has special handling for AF_INET, AF_INET, and AF_UNIX sockets as those address families have special hooks which label the sock before it is attached its associated socket. Unfortunately, the sock_graft() hook was missing a default approach to labeling sockets which meant that any other address family which made use of connections or the accept() syscall would find the returned socket to be in an "unlabeled" state. This was recently demonstrated by the kcrypto/AF_ALG subsystem and the newly released cryptsetup package (cryptsetup v1.6.5 and later). This patch preserves the special handling in selinux_sock_graft(), but adds a default behavior - setting the sock's label equal to the associated socket - which resolves the problem with AF_ALG and presumably any other address family which makes use of accept(). Cc: stable@vger.kernel.org Signed-off-by:
Paul Moore <pmoore@redhat.com> Tested-by:
Milan Broz <gmazyland@gmail.com>
-
- 26 Jun, 2014 1 commit
-
-
Paul Moore authored
When flushing the AVC, such as during a policy load, the various network caches are also flushed, with each making a call to synchronize_net() which has shown to be expensive in some cases. This patch consolidates the network cache flushes into a single AVC callback which only calls synchronize_net() once for each AVC cache flush. Reported-by:
Jaejyn Shin <flagon22bass@gmail.com> Signed-off-by:
Paul Moore <pmoore@redhat.com>
-
- 23 Jun, 2014 1 commit
-
-
Waiman Long authored
With the introduction of fair queued rwlock, recursive read_lock() may hang the offending process if there is a write_lock() somewhere in between. With recursive read_lock checking enabled, the following error was reported: ============================================= [ INFO: possible recursive locking detected ] 3.16.0-rc1 #2 Tainted: G E --------------------------------------------- load_policy/708 is trying to acquire lock: (policy_rwlock){.+.+..}, at: [<ffffffff8125b32a>] security_genfs_sid+0x3a/0x170 but task is already holding lock: (policy_rwlock){.+.+..}, at: [<ffffffff8125b48c>] security_fs_use+0x2c/0x110 other info that might help us debug this: Possible unsafe locking scenario: CPU0 ---- lock(policy_rwlock); lock(policy_rwlock); This patch fixes the occurrence of recursive read_lock() of policy_rwlock by adding a helper function __security_genfs_sid() which requires caller to take the lock before calling it. The security_fs_use() was then modified to call the new helper function. Signed-off-by:
Waiman Long <Waiman.Long@hp.com> Acked-by:
Stephen Smalley <sds@tycho.nsa.gov> Signed-off-by:
Paul Moore <pmoore@redhat.com>
-
- 19 Jun, 2014 2 commits
-
-
Namhyung Kim authored
The cond_read_node() should free the given node on error path as it's not linked to p->cond_list yet. This is done via cond_node_destroy() but it's not called when next_entry() fails before the expr loop. Signed-off-by:
Namhyung Kim <namhyung@kernel.org> Signed-off-by:
Paul Moore <pmoore@redhat.com>
-
Namhyung Kim authored
The node->cur_state and len can be read in a single call of next_entry(). And setting len before reading is a dead write so can be eliminated. Signed-off-by:
Namhyung Kim <namhyung@kernel.org> (Minor tweak to the length parameter in the call to next_entry()) Signed-off-by:
Paul Moore <pmoore@redhat.com>
-
- 18 Jun, 2014 2 commits
-
-
Gideon Israel Dsouza authored
To increase compiler portability there is <linux/compiler.h> which provides convenience macros for various gcc constructs. Eg: __packed for __attribute__((packed)). This patch is part of a large task I've taken to clean the gcc specific attributes and use the the macros instead. Signed-off-by:
Gideon Israel Dsouza <gidisrael@gmail.com> Signed-off-by:
Paul Moore <pmoore@redhat.com>
-
Namhyung Kim authored
There're some code duplication for reading a string value during policydb_read(). Add str_read() helper to fix it. Signed-off-by:
Namhyung Kim <namhyung@kernel.org> Signed-off-by:
Paul Moore <pmoore@redhat.com>
-
- 17 Jun, 2014 1 commit
-
-
Himangi Saraogi authored
ARRAY_SIZE is more concise to use when the size of an array is divided by the size of its type or the size of its first element. The Coccinelle semantic patch that makes this change is as follows: // <smpl> @@ type T; T[] E; @@ - (sizeof(E)/sizeof(E[...])) + ARRAY_SIZE(E) // </smpl> Signed-off-by:
Himangi Saraogi <himangi774@gmail.com> Signed-off-by:
Paul Moore <pmoore@redhat.com>
-
- 12 Jun, 2014 2 commits
-
-
Dmitry Kasatkin authored
Commit 8aac6270 "move exit_task_namespaces() outside of exit_notify" introduced the kernel opps since the kernel v3.10, which happens when Apparmor and IMA-appraisal are enabled at the same time. ---------------------------------------------------------------------- [ 106.750167] BUG: unable to handle kernel NULL pointer dereference at 0000000000000018 [ 106.750221] IP: [<ffffffff811ec7da>] our_mnt+0x1a/0x30 [ 106.750241] PGD 0 [ 106.750254] Oops: 0000 [#1] SMP [ 106.750272] Modules linked in: cuse parport_pc ppdev bnep rfcomm bluetooth rpcsec_gss_krb5 nfsd auth_rpcgss nfs_acl nfs lockd sunrpc fscache dm_crypt intel_rapl x86_pkg_temp_thermal intel_powerclamp kvm_intel snd_hda_codec_hdmi kvm crct10dif_pclmul crc32_pclmul ghash_clmulni_intel aesni_intel aes_x86_64 glue_helper lrw gf128mul ablk_helper cryptd snd_hda_codec_realtek dcdbas snd_hda_intel snd_hda_codec snd_hwdep snd_pcm snd_page_alloc snd_seq_midi snd_seq_midi_event snd_rawmidi psmouse snd_seq microcode serio_raw snd_timer snd_seq_device snd soundcore video lpc_ich coretemp mac_hid lp parport mei_me mei nbd hid_generic e1000e usbhid ahci ptp hid libahci pps_core [ 106.750658] CPU: 6 PID: 1394 Comm: mysqld Not tainted 3.13.0-rc7-kds+ #15 [ 106.750673] Hardware name: Dell Inc. OptiPlex 9010/0M9KCM, BIOS A08 09/19/2012 [ 106.750689] task: ffff8800de804920 ti: ffff880400fca000 task.ti: ffff880400fca000 [ 106.750704] RIP: 0010:[<ffffffff811ec7da>] [<ffffffff811ec7da>] our_mnt+0x1a/0x30 [ 106.750725] RSP: 0018:ffff880400fcba60 EFLAGS: 00010286 [ 106.750738] RAX: 0000000000000000 RBX: 0000000000000100 RCX: ffff8800d51523e7 [ 106.750764] RDX: ffffffffffffffea RSI: ffff880400fcba34 RDI: ffff880402d20020 [ 106.750791] RBP: ffff880400fcbae0 R08: 0000000000000000 R09: 0000000000000001 [ 106.750817] R10: 0000000000000000 R11: 0000000000000001 R12: ffff8800d5152300 [ 106.750844] R13: ffff8803eb8df510 R14: ffff880400fcbb28 R15: ffff8800d51523e7 [ 106.750871] FS: 0000000000000000(0000) GS:ffff88040d200000(0000) knlGS:0000000000000000 [ 106.750910] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 106.750935] CR2: 0000000000000018 CR3: 0000000001c0e000 CR4: 00000000001407e0 [ 106.750962] Stack: [ 106.750981] ffffffff813434eb ffff880400fcbb20 ffff880400fcbb18 0000000000000000 [ 106.751037] ffff8800de804920 ffffffff8101b9b9 0001800000000000 0000000000000100 [ 106.751093] 0000010000000000 0000000000000002 000000000000000e ffff8803eb8df500 [ 106.751149] Call Trace: [ 106.751172] [<ffffffff813434eb>] ? aa_path_name+0x2ab/0x430 [ 106.751199] [<ffffffff8101b9b9>] ? sched_clock+0x9/0x10 [ 106.751225] [<ffffffff8134a68d>] aa_path_perm+0x7d/0x170 [ 106.751250] [<ffffffff8101b945>] ? native_sched_clock+0x15/0x80 [ 106.751276] [<ffffffff8134aa73>] aa_file_perm+0x33/0x40 [ 106.751301] [<ffffffff81348c5e>] common_file_perm+0x8e/0xb0 [ 106.751327] [<ffffffff81348d78>] apparmor_file_permission+0x18/0x20 [ 106.751355] [<ffffffff8130c853>] security_file_permission+0x23/0xa0 [ 106.751382] [<ffffffff811c77a2>] rw_verify_area+0x52/0xe0 [ 106.751407] [<ffffffff811c789d>] vfs_read+0x6d/0x170 [ 106.751432] [<ffffffff811cda31>] kernel_read+0x41/0x60 [ 106.751457] [<ffffffff8134fd45>] ima_calc_file_hash+0x225/0x280 [ 106.751483] [<ffffffff8134fb52>] ? ima_calc_file_hash+0x32/0x280 [ 106.751509] [<ffffffff8135022d>] ima_collect_measurement+0x9d/0x160 [ 106.751536] [<ffffffff810b552d>] ? trace_hardirqs_on+0xd/0x10 [ 106.751562] [<ffffffff8134f07c>] ? ima_file_free+0x6c/0xd0 [ 106.751587] [<ffffffff81352824>] ima_update_xattr+0x34/0x60 [ 106.751612] [<ffffffff8134f0d0>] ima_file_free+0xc0/0xd0 [ 106.751637] [<ffffffff811c9635>] __fput+0xd5/0x300 [ 106.751662] [<ffffffff811c98ae>] ____fput+0xe/0x10 [ 106.751687] [<ffffffff81086774>] task_work_run+0xc4/0xe0 [ 106.751712] [<ffffffff81066fad>] do_exit+0x2bd/0xa90 [ 106.751738] [<ffffffff8173c958>] ? retint_swapgs+0x13/0x1b [ 106.751763] [<ffffffff8106780c>] do_group_exit+0x4c/0xc0 [ 106.751788] [<ffffffff81067894>] SyS_exit_group+0x14/0x20 [ 106.751814] [<ffffffff8174522d>] system_call_fastpath+0x1a/0x1f [ 106.751839] Code: c3 0f 1f 44 00 00 55 48 89 e5 e8 22 fe ff ff 5d c3 0f 1f 44 00 00 55 65 48 8b 04 25 c0 c9 00 00 48 8b 80 28 06 00 00 48 89 e5 5d <48> 8b 40 18 48 39 87 c0 00 00 00 0f 94 c0 c3 0f 1f 80 00 00 00 [ 106.752185] RIP [<ffffffff811ec7da>] our_mnt+0x1a/0x30 [ 106.752214] RSP <ffff880400fcba60> [ 106.752236] CR2: 0000000000000018 [ 106.752258] ---[ end trace 3c520748b4732721 ]--- ---------------------------------------------------------------------- The reason for the oops is that IMA-appraisal uses "kernel_read()" when file is closed. kernel_read() honors LSM security hook which calls Apparmor handler, which uses current->nsproxy->mnt_ns. The 'guilty' commit changed the order of cleanup code so that nsproxy->mnt_ns was not already available for Apparmor. Discussion about the issue with Al Viro and Eric W. Biederman suggested that kernel_read() is too high-level for IMA. Another issue, except security checking, that was identified is mandatory locking. kernel_read honors it as well and it might prevent IMA from calculating necessary hash. It was suggested to use simplified version of the function without security and locking checks. This patch introduces special version ima_kernel_read(), which skips security and mandatory locking checking. It prevents the kernel oops to happen. Signed-off-by:
Dmitry Kasatkin <d.kasatkin@samsung.com> Suggested-by:
Eric W. Biederman <ebiederm@xmission.com> Signed-off-by:
Mimi Zohar <zohar@linux.vnet.ibm.com> Cc: <stable@vger.kernel.org>
-
Mimi Zohar authored
Calculating the 'security.evm' HMAC value requires access to the EVM encrypted key. Only the kernel should have access to it. This patch prevents userspace tools(eg. setfattr, cp --preserve=xattr) from setting/modifying the 'security.evm' HMAC value directly. Signed-off-by:
Mimi Zohar <zohar@linux.vnet.ibm.com> Cc: <stable@vger.kernel.org>
-