linux.git/security/selinux/ss, branch master

Merge branch 'printk-cleanups'

2016-10-10T16:29:50+00:00

Merge my system logging cleanups, triggered by the broken '\n' patches. The line continuation handling has been broken basically forever, and the code to handle the system log records was both confusing and dubious. And it would do entirely the wrong thing unless you always had a terminating newline, partly because it couldn't actually see whether a message was marked KERN_CONT or not (but partly because the LOG_CONT handling in the recording code was rather confusing too). This re-introduces a real semantically meaningful KERN_CONT, and fixes the few places I noticed where it was missing. There are probably more missing cases, since KERN_CONT hasn't actually had any semantic meaning for at least four years (other than the checkpatch meaning of "no log level necessary, this is a continuation line"). This also allows the combination of KERN_CONT and a log level. In that case the log level will be ignored if the merging with a previous line is successful, but if a new record is needed, that new record will now get the right log level. That also means that you can at least in theory combine KERN_CONT with the "pr_info()" style helpers, although any use of pr_fmt() prefixing would make that just result in a mess, of course (the prefix would end up in the middle of a continuing line). * printk-cleanups: printk: make reading the kernel log flush pending lines printk: re-organize log_output() to be more legible printk: split out core logging code into helper function printk: reinstate KERN_CONT for printing continuation lines

printk: reinstate KERN_CONT for printing continuation lines

2016-10-09T19:23:38+00:00

Long long ago the kernel log buffer was a buffered stream of bytes, very much like stdio in user space. It supported log levels by scanning the stream and noticing the log level markers at the beginning of each line, but if you wanted to print a partial line in multiple chunks, you just did multiple printk() calls, and it just automatically worked. Except when it didn't, and you had very confusing output when different lines got all mixed up with each other. Then you got fragment lines mixing with each other, or with non-fragment lines, because it was traditionally impossible to tell whether a printk() call was a continuation or not. To at least help clarify the issue of continuation lines, we added a KERN_CONT marker back in 2007 to mark continuation lines: 474925277671 ("printk: add KERN_CONT annotation"). That continuation marker was initially an empty string, and didn't actuall make any semantic difference. But it at least made it possible to annotate the source code, and have check-patch notice that a printk() didn't need or want a log level marker, because it was a continuation of a previous line. To avoid the ambiguity between a continuation line that had that KERN_CONT marker, and a printk with no level information at all, we then in 2009 made KERN_CONT be a real log level marker which meant that we could now reliably tell the difference between the two cases. 5fd29d6ccbc9 ("printk: clean up handling of log-levels and newlines") and we could take advantage of that to make sure we didn't mix up continuation lines with lines that just didn't have any loglevel at all. Then, in 2012, the kernel log buffer was changed to be a "record" based log, where each line was a record that has a loglevel and a timestamp. You can see the beginning of that conversion in commits e11fea92e13f ("kmsg: export printk records to the /dev/kmsg interface") 7ff9554bb578 ("printk: convert byte-buffer to variable-length record buffer") with a number of follow-up commits to fix some painful fallout from that conversion. Over all, it took a couple of months to sort out most of it. But the upside was that you could have concurrent readers (and writers) of the kernel log and not have lines with mixed output in them. And one particular pain-point for the record-based kernel logging was exactly the fragmentary lines that are generated in smaller chunks. In order to still log them as one recrod, the continuation lines need to be attached to the previous record properly. However the explicit continuation record marker that is actually useful for this exact case was actually removed in aroundm the same time by commit 61e99ab8e35a ("printk: remove the now unnecessary "C" annotation for KERN_CONT") due to the incorrect belief that KERN_CONT wasn't meaningful. The ambiguity between "is this a continuation line" or "is this a plain printk with no log level information" was reintroduced, and in fact became an even bigger pain point because there was now the whole record-level merging of kernel messages going on. This patch reinstates the KERN_CONT as a real non-empty string marker, so that the ambiguity is fixed once again. But it's not a plain revert of that original removal: in the four years since we made KERN_CONT an empty string again, not only has the format of the log level markers changed, we've also had some usage changes in this area. For example, some ACPI code seems to use KERN_CONT _together_ with a log level, and now uses both the KERN_CONT marker and (for example) a KERN_INFO marker to show that it's an informational continuation of a line. Which is actually not a bad idea - if the continuation line cannot be attached to its predecessor, without the log level information we don't know what log level to assign to it (and we traditionally just assigned it the default loglevel). So having both a log level and the KERN_CONT marker is not necessarily a bad idea, but it does mean that we need to actually iterate over potentially multiple markers, rather than just a single one. Also, since KERN_CONT was still conceptually needed, and encouraged, but didn't actually _do_ anything, we've also had the reverse problem: rather than having too many annotations it has too few, and there is bit rot with code that no longer marks the continuation lines with the KERN_CONT marker. So this patch not only re-instates the non-empty KERN_CONT marker, it also fixes up the cases of bit-rot I noticed in my own logs. There are probably other cases where KERN_CONT will be needed to be added, either because it is new code that never dealt with the need for KERN_CONT, or old code that has bitrotted without anybody noticing. That said, we should strive to avoid the need for KERN_CONT. It does result in real problems for logging, and should generally not be seen as a good feature. If we some day can get rid of the feature entirely, because nobody does any fragmented printk calls, that would be lovely. But until that point, let's at mark the code that relies on the hacky multi-fragment kernel printk's. Not only does it avoid the ambiguity, it also annotates code as "maybe this would be good to fix some day". (That said, particularly during single-threaded bootup, the downsides of KERN_CONT are very limited. Things get much hairier when you have multiple threads going on and user level reading and writing logs too). Signed-off-by: Linus Torvalds

selinux: fix error return code in policydb_read()

2016-09-13T21:14:43+00:00

Fix to return error code -EINVAL from the error handling case instead of 0 (rc is overwrite to 0 when policyvers >= POLICYDB_VERSION_ROLETRANS), as done elsewhere in this function. Signed-off-by: Wei Yongjun [PM: normalize "selinux" in patch subject, description line wrap] Signed-off-by: Paul Moore

selinux: fix overflow and 0 length allocations

2016-08-30T19:45:50+00:00

Throughout the SELinux LSM, values taken from sepolicy are used in places where length == 0 or length == matter, find and fix these. Signed-off-by: William Roberts Signed-off-by: Paul Moore

selinux: initialize structures

2016-08-29T23:22:10+00:00

libsepol pointed out an issue where its possible to have an unitialized jmp and invalid dereference, fix this. While we're here, zero allocate all the *_val_to_struct structures. Signed-off-by: William Roberts Signed-off-by: Paul Moore

selinux: detect invalid ebitmap

2016-08-29T23:19:50+00:00

When count is 0 and the highbit is not zero, the ebitmap is not valid and the internal node is not allocated. This causes issues when routines, like mls_context_isvalid() attempt to use the ebitmap_for_each_bit() and ebitmap_node_get_bit() as they assume a highbit > 0 will have a node allocated. Signed-off-by: William Roberts Signed-off-by: Paul Moore

selinux: import NetLabel category bitmaps correctly

2016-06-09T14:40:37+00:00

The existing ebitmap_netlbl_import() code didn't correctly handle the case where the ebitmap_node was not aligned/sized to a power of two, this patch fixes this (on x86_64 ebitmap_node contains six bitmaps making a range of 0..383). Signed-off-by: Paul Moore

selinux: Only apply bounds checking to source types

2016-05-31T16:01:59+00:00

The current bounds checking of both source and target types requires allowing any domain that has access to the child domain to also have the same permissions to the parent, which is undesirable. Drop the target bounds checking. KaiGai Kohei originally removed all use of target bounds in commit 7d52a155e38d ("selinux: remove dead code in type_attribute_bounds_av()") but this was reverted in commit 2ae3ba39389b ("selinux: libsepol: remove dead code in check_avtab_hierarchy_callback()") because it would have required explicitly allowing the parent any permissions to the child that the child is allowed to itself. This change in contrast retains the logic for the case where both source and target types are bounded, thereby allowing access if the parent of the source is allowed the corresponding permissions to the parent of the target. Further, this change reworks the logic such that we only perform a single computation for each case and there is no ambiguity as to how to resolve a bounds violation. Under the new logic, if the source type and target types are both bounded, then the parent of the source type must be allowed the same permissions to the parent of the target type. If only the source type is bounded, then the parent of the source type must be allowed the same permissions to the target type. Examples of the new logic and comparisons with the old logic: 1. If we have: typebounds A B; then: allow B self:process ; will satisfy the bounds constraint iff: allow A self:process ; is also allowed in policy. Under the old logic, the allow rule on B satisfies the bounds constraint if any of the following three are allowed: allow A B:process ; or allow B A:process ; or allow A self:process ; However, either of the first two ultimately require the third to satisfy the bounds constraint under the old logic, and therefore this degenerates to the same result (but is more efficient - we only need to perform one compute_av call). 2. If we have: typebounds A B; typebounds A_exec B_exec; then: allow B B_exec:file ; will satisfy the bounds constraint iff: allow A A_exec:file ; is also allowed in policy. This is essentially the same as #1; it is merely included as an example of dealing with object types related to a bounded domain in a manner that satisfies the bounds relationship. Note that this approach is preferable to leaving B_exec unbounded and having: allow A B_exec:file ; in policy because that would allow B's entrypoints to be used to enter A. Similarly for _tmp or other related types. 3. If we have: typebounds A B; and an unbounded type T, then: allow B T:file ; will satisfy the bounds constraint iff: allow A T:file ; is allowed in policy. The old logic would have been identical for this example. 4. If we have: typebounds A B; and an unbounded domain D, then: allow D B:unix_stream_socket ; is not subject to any bounds constraints under the new logic because D is not bounded. This is desirable so that we can allow a domain to e.g. connectto a child domain without having to allow it to do the same to its parent. The old logic would have required: allow D A:unix_stream_socket ; to also be allowed in policy. Signed-off-by: Stephen Smalley [PM: re-wrapped description to appease checkpatch.pl] Signed-off-by: Paul Moore

selinux: Change bool variable name to index.

2016-04-14T15:24:50+00:00

security_get_bool_value(int bool) argument "bool" conflicts with in-kernel macros such as BUILD_BUG(). This patch changes this to index which isn't a type. Cc: Paul Moore Cc: Stephen Smalley Cc: Eric Paris Cc: James Morris Cc: "Serge E. Hallyn" Cc: Rasmus Villemoes Cc: Andrew Perepechko Cc: Jeff Vander Stoep Cc: selinux@tycho.nsa.gov Cc: Eric Paris Cc: Paul Moore Cc: David Howells Signed-off-by: Prarit Bhargava Acked-by: David Howells [PM: wrapped description for checkpatch.pl, use "selinux:..." as subj] Signed-off-by: Paul Moore

Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security

2016-01-18T03:13:15+00:00

Pull security subsystem updates from James Morris: - EVM gains support for loading an x509 cert from the kernel (EVM_LOAD_X509), into the EVM trusted kernel keyring. - Smack implements 'file receive' process-based permission checking for sockets, rather than just depending on inode checks. - Misc enhancments for TPM & TPM2. - Cleanups and bugfixes for SELinux, Keys, and IMA. * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security: (41 commits) selinux: Inode label revalidation performance fix KEYS: refcount bug fix ima: ima_write_policy() limit locking IMA: policy can be updated zero times selinux: rate-limit netlink message warnings in selinux_nlmsg_perm() selinux: export validatetrans decisions gfs2: Invalid security labels of inodes when they go invalid selinux: Revalidate invalid inode security labels security: Add hook to invalidate inode security labels selinux: Add accessor functions for inode->i_security security: Make inode argument of inode_getsecid non-const security: Make inode argument of inode_getsecurity non-const selinux: Remove unused variable in selinux_inode_init_security keys, trusted: seal with a TPM2 authorization policy keys, trusted: select hash algorithm for TPM2 chips keys, trusted: fix: *do not* allow duplicate key options tpm_ibmvtpm: properly handle interrupted packet receptions tpm_tis: Tighten IRQ auto-probing tpm_tis: Refactor the interrupt setup tpm_tis: Get rid of the duplicate IRQ probing code ...