BMC/Intel-BMC/linux.git/security/selinux/ss, branch dev

selinux: don't waste ebitmap space when importing NetLabel categories

2015-07-09T18:20:36+00:00

At present we don't create efficient ebitmaps when importing NetLabel category bitmaps. This can present a problem when comparing ebitmaps since ebitmap_cmp() is very strict about these things and considers these wasteful ebitmaps not equal when compared to their more efficient counterparts, even if their values are the same. This isn't likely to cause problems on 64-bit systems due to a bit of luck on how NetLabel/CIPSO works and the default ebitmap size, but it can be a problem on 32-bit systems. This patch fixes this problem by being a bit more intelligent when importing NetLabel category bitmaps by skipping over empty sections which should result in a nice, efficient ebitmap. Cc: stable@vger.kernel.org # 3.17 Signed-off-by: Paul Moore

selinux: increase avtab max buckets

2015-04-07T00:16:23+00:00

Now that we can safely increase the avtab max buckets without triggering high order allocations and have a hash function that will make better use of the larger number of buckets, increase the max buckets to 2^16. Original: 101421 entries and 2048/2048 buckets used, longest chain length 374 With new hash function: 101421 entries and 2048/2048 buckets used, longest chain length 81 With increased max buckets: 101421 entries and 31078/32768 buckets used, longest chain length 12 Signed-off-by: Stephen Smalley Signed-off-by: Paul Moore

selinux: Use a better hash function for avtab

2015-04-07T00:16:21+00:00

This function, based on murmurhash3, has much better distribution than the original. Using the current default of 2048 buckets, there are many fewer collisions: Before: 101421 entries and 2048/2048 buckets used, longest chain length 374 After: 101421 entries and 2048/2048 buckets used, longest chain length 81 The difference becomes much more significant when buckets are increased. A naive attempt to expand the current function to larger outputs doesn't yield any significant improvement; so this function is a prerequisite for increasing the bucket size. sds: Adapted from the original patches for libsepol to the kernel. Signed-off-by: John Brooks Signed-off-by: Stephen Smalley Signed-off-by: Paul Moore

selinux: convert avtab hash table to flex_array

2015-04-07T00:16:20+00:00

Previously we shrank the avtab max hash buckets to avoid high order memory allocations, but this causes avtab lookups to degenerate to very long linear searches for the Fedora policy. Convert to using a flex_array instead so that we can increase the buckets without such limitations. This change does not alter the max hash buckets; that is left to a separate follow-on change. Signed-off-by: Stephen Smalley Signed-off-by: Paul Moore

selinux: reconcile security_netlbl_secattr_to_sid() and mls_import_netlbl_cat()

2015-04-07T00:15:55+00:00

Move the NetLabel secattr MLS category import logic into mls_import_netlbl_cat() where it belongs, and use the mls_import_netlbl_cat() function in security_netlbl_secattr_to_sid(). Reported-by: Rickard Strandqvist Signed-off-by: Paul Moore

SELinux: fix error code in policydb_init()

2015-02-04T16:34:30+00:00

If hashtab_create() returns a NULL pointer then we should return -ENOMEM but instead the current code returns success. Signed-off-by: Dan Carpenter Acked-by: Serge Hallyn Acked-by: Stephen Smalley Signed-off-by: Paul Moore

selinux: normalize audit log formatting

2014-09-22T21:02:10+00:00

Restructure to keyword=value pairs without spaces. Drop superfluous words in text. Make invalid_context a keyword. Change result= keyword to seresult=. Signed-off-by: Richard Guy Briggs [Minor rewrite to the patch subject line] Signed-off-by: Paul Moore

netlabel: shorter names for the NetLabel catmap funcs/structs

2014-08-01T15:17:37+00:00

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 Tested-by: Casey Schaufler

netlabel: fix the horribly broken catmap functions

2014-08-01T15:17:17+00:00

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 Signed-off-by: Paul Moore Tested-by: Casey Schaufler

selinux: no recursive read_lock of policy_rwlock in security_genfs_sid()

2014-06-23T20:52:55+00:00

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: [] security_genfs_sid+0x3a/0x170 but task is already holding lock: (policy_rwlock){.+.+..}, at: [] 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 Acked-by: Stephen Smalley Signed-off-by: Paul Moore