summaryrefslogtreecommitdiff
path: root/security
AgeCommit message (Collapse)AuthorFilesLines
2012-05-22Merge branch 'next' of ↵Linus Torvalds50-1102/+1857
git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security Pull security subsystem updates from James Morris: "New notable features: - The seccomp work from Will Drewry - PR_{GET,SET}_NO_NEW_PRIVS from Andy Lutomirski - Longer security labels for Smack from Casey Schaufler - Additional ptrace restriction modes for Yama by Kees Cook" Fix up trivial context conflicts in arch/x86/Kconfig and include/linux/filter.h * 'next' of git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security: (65 commits) apparmor: fix long path failure due to disconnected path apparmor: fix profile lookup for unconfined ima: fix filename hint to reflect script interpreter name KEYS: Don't check for NULL key pointer in key_validate() Smack: allow for significantly longer Smack labels v4 gfp flags for security_inode_alloc()? Smack: recursive tramsmute Yama: replace capable() with ns_capable() TOMOYO: Accept manager programs which do not start with / . KEYS: Add invalidation support KEYS: Do LRU discard in full keyrings KEYS: Permit in-place link replacement in keyring list KEYS: Perform RCU synchronisation on keys prior to key destruction KEYS: Announce key type (un)registration KEYS: Reorganise keys Makefile KEYS: Move the key config into security/keys/Kconfig KEYS: Use the compat keyctl() syscall wrapper on Sparc64 for Sparc32 compat Yama: remove an unused variable samples/seccomp: fix dependencies on arch macros Yama: add additional ptrace scopes ...
2012-05-22Merge branch 'master' of git://git.infradead.org/users/eparis/selinux into nextJames Morris29-335/+415
Per pull request, for 3.5.
2012-05-18apparmor: fix long path failure due to disconnected pathJohn Johansen1-0/+2
BugLink: http://bugs.launchpad.net/bugs/955892 All failures from __d_path where being treated as disconnected paths, however __d_path can also fail when the generated pathname is too long. The initial ENAMETOOLONG error was being lost, and ENAMETOOLONG was only returned if the subsequent dentry_path call resulted in that error. Other wise if the path was split across a mount point such that the dentry_path fit within the buffer when the __d_path did not the failure was treated as a disconnected path. Signed-off-by: John Johansen <john.johansen@canonical.com>
2012-05-18apparmor: fix profile lookup for unconfinedJohn Johansen1-0/+4
BugLink: http://bugs.launchpad.net/bugs/978038 also affects apparmor portion of BugLink: http://bugs.launchpad.net/bugs/987371 The unconfined profile is not stored in the regular profile list, but change_profile and exec transitions may want access to it when setting up specialized transitions like switch to the unconfined profile of a new policy namespace. Signed-off-by: John Johansen <john.johansen@canonical.com>
2012-05-16ima: fix filename hint to reflect script interpreter nameMimi Zohar1-1/+3
When IMA was first upstreamed, the bprm filename and interp were always the same. Currently, the bprm->filename and bprm->interp are the same, except for when only bprm->interp contains the interpreter name. So instead of using the bprm->filename as the IMA filename hint in the measurement list, we could replace it with bprm->interp, but this feels too fragil. The following patch is not much better, but at least there is some indication that sometimes we're passing the filename and other times the interpreter name. Reported-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Mimi Zohar <zohar@linux.vnet.ibm.com> Signed-off-by: James Morris <james.l.morris@oracle.com>
2012-05-15Merge branch 'for-1205' of http://git.gitorious.org/smack-next/kernel into nextJames Morris4-539/+981
Pull request from Casey.
2012-05-15KEYS: Don't check for NULL key pointer in key_validate()David Howells1-24/+16
Don't bother checking for NULL key pointer in key_validate() as all of the places that call it will crash anyway if the relevant key pointer is NULL by the time they call key_validate(). Therefore, the checking must be done prior to calling here. Whilst we're at it, simplify the key_validate() function a bit and mark its argument const. Reported-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: David Howells <dhowells@redhat.com> cc: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: James Morris <james.l.morris@oracle.com>
2012-05-15Smack: allow for significantly longer Smack labels v4Casey Schaufler4-526/+941
V4 updated to current linux-security#next Targeted for git://gitorious.org/smack-next/kernel.git Modern application runtime environments like to use naming schemes that are structured and generated without human intervention. Even though the Smack limit of 23 characters for a label name is perfectly rational for human use there have been complaints that the limit is a problem in environments where names are composed from a set or sources, including vendor, author, distribution channel and application name. Names like softwarehouse-pgwodehouse-coolappstore-mellowmuskrats are becoming harder to avoid. This patch introduces long label support in Smack. Labels are now limited to 255 characters instead of the old 23. The primary reason for limiting the labels to 23 characters was so they could be directly contained in CIPSO category sets. This is still done were possible, but for labels that are too large a mapping is required. This is perfectly safe for communication that stays "on the box" and doesn't require much coordination between boxes beyond what would have been required to keep label names consistent. The bulk of this patch is in smackfs, adding and updating administrative interfaces. Because existing APIs can't be changed new ones that do much the same things as old ones have been introduced. The Smack specific CIPSO data representation has been removed and replaced with the data format used by netlabel. The CIPSO header is now computed when a label is imported rather than on use. This results in improved IP performance. The smack label is now allocated separately from the containing structure, allowing for larger strings. Four new /smack interfaces have been introduced as four of the old interfaces strictly required labels be specified in fixed length arrays. The access interface is supplemented with the check interface: access "Subject Object rwxat" access2 "Subject Object rwaxt" The load interface is supplemented with the rules interface: load "Subject Object rwxat" load2 "Subject Object rwaxt" The load-self interface is supplemented with the self-rules interface: load-self "Subject Object rwxat" load-self2 "Subject Object rwaxt" The cipso interface is supplemented with the wire interface: cipso "Subject lvl cnt c1 c2 ..." cipso2 "Subject lvl cnt c1 c2 ..." The old interfaces are maintained for compatibility. Signed-off-by: Casey Schaufler <casey@schaufler-ca.com>
2012-05-15gfp flags for security_inode_alloc()?Tetsuo Handa1-4/+4
Dave Chinner wrote: > Yes, because you have no idea what the calling context is except > for the fact that is from somewhere inside filesystem code and the > filesystem could be holding locks. Therefore, GFP_NOFS is really the > only really safe way to allocate memory here. I see. Thank you. I'm not sure, but can call trace happen where somewhere inside network filesystem or stackable filesystem code with locks held invokes operations that involves GFP_KENREL memory allocation outside that filesystem? ---------- [PATCH] SMACK: Fix incorrect GFP_KERNEL usage. new_inode_smack() which can be called from smack_inode_alloc_security() needs to use GFP_NOFS like SELinux's inode_alloc_security() does, for security_inode_alloc() is called from inode_init_always() and inode_init_always() is called from xfs_inode_alloc() which is using GFP_NOFS. smack_inode_init_security() needs to use GFP_NOFS like selinux_inode_init_security() does, for initxattrs() callback function (e.g. btrfs_initxattrs()) which is called from security_inode_init_security() is using GFP_NOFS. smack_audit_rule_match() needs to use GFP_ATOMIC, for security_audit_rule_match() can be called from audit_filter_user_rules() and audit_filter_user_rules() is called from audit_filter_user() with RCU read lock held. Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> Signed-off-by: Casey Schaufler <cschaufler@cschaufler-intel.(none)>
2012-05-15Smack: recursive tramsmuteCasey Schaufler2-9/+36
The transmuting directory feature of Smack requires that the transmuting attribute be explicitly set in all cases. It seems the users of this facility would expect that the transmuting attribute be inherited by subdirectories that are created in a transmuting directory. This does not seem to add any additional complexity to the understanding of how the system works. Signed-off-by: Casey Schaufler <casey@schaufler-ca.com>
2012-05-15Yama: replace capable() with ns_capable()Kees Cook1-2/+2
When checking capabilities, the question we want to be asking is "does current() have the capability in the child's namespace?" Signed-off-by: Kees Cook <keescook@chromium.org> Signed-off-by: James Morris <james.l.morris@oracle.com>
2012-05-15TOMOYO: Accept manager programs which do not start with / .Tetsuo Handa2-21/+6
The pathname of /usr/sbin/tomoyo-editpolicy seen from Ubuntu 12.04 Live CD is squashfs:/usr/sbin/tomoyo-editpolicy rather than /usr/sbin/tomoyo-editpolicy . Therefore, we need to accept manager programs which do not start with / . Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> Signed-off-by: James Morris <james.l.morris@oracle.com>
2012-05-11KEYS: Add invalidation supportDavid Howells8-28/+110
Add support for invalidating a key - which renders it immediately invisible to further searches and causes the garbage collector to immediately wake up, remove it from keyrings and then destroy it when it's no longer referenced. It's better not to do this with keyctl_revoke() as that marks the key to start returning -EKEYREVOKED to searches when what is actually desired is to have the key refetched. To invalidate a key the caller must be granted SEARCH permission by the key. This may be too strict. It may be better to also permit invalidation if the caller has any of READ, WRITE or SETATTR permission. The primary use for this is to evict keys that are cached in special keyrings, such as the DNS resolver or an ID mapper. Signed-off-by: David Howells <dhowells@redhat.com>
2012-05-11KEYS: Do LRU discard in full keyringsDavid Howells2-7/+42
Do an LRU discard in keyrings that are full rather than returning ENFILE. To perform this, a time_t is added to the key struct and updated by the creation of a link to a key and by a key being found as the result of a search. At the completion of a successful search, the keyrings in the path between the root of the search and the first found link to it also have their last-used times updated. Note that discarding a link to a key from a keyring does not necessarily destroy the key as there may be references held by other places. An alternate discard method that might suffice is to perform FIFO discard from the keyring, using the spare 2-byte hole in the keylist header as the index of the next link to be discarded. This is useful when using a keyring as a cache for DNS results or foreign filesystem IDs. This can be tested by the following. As root do: echo 1000 >/proc/sys/kernel/keys/root_maxkeys kr=`keyctl newring foo @s` for ((i=0; i<2000; i++)); do keyctl add user a$i a $kr; done Without this patch ENFILE should be reported when the keyring fills up. With this patch, the keyring discards keys in an LRU fashion. Note that the stored LRU time has a granularity of 1s. After doing this, /proc/key-users can be observed and should show that most of the 2000 keys have been discarded: [root@andromeda ~]# cat /proc/key-users 0: 517 516/516 513/1000 5249/20000 The "513/1000" here is the number of quota-accounted keys present for this user out of the maximum permitted. In /proc/keys, the keyring shows the number of keys it has and the number of slots it has allocated: [root@andromeda ~]# grep foo /proc/keys 200c64c4 I--Q-- 1 perm 3b3f0000 0 0 keyring foo: 509/509 The maximum is (PAGE_SIZE - header) / key pointer size. That's typically 509 on a 64-bit system and 1020 on a 32-bit system. Signed-off-by: David Howells <dhowells@redhat.com>
2012-05-11KEYS: Permit in-place link replacement in keyring listDavid Howells2-40/+57
Make use of the previous patch that makes the garbage collector perform RCU synchronisation before destroying defunct keys. Key pointers can now be replaced in-place without creating a new keyring payload and replacing the whole thing as the discarded keys will not be destroyed until all currently held RCU read locks are released. If the keyring payload space needs to be expanded or contracted, then a replacement will still need allocating, and the original will still have to be freed by RCU. Signed-off-by: David Howells <dhowells@redhat.com>
2012-05-11KEYS: Perform RCU synchronisation on keys prior to key destructionDavid Howells1-29/+44
Make the keys garbage collector invoke synchronize_rcu() prior to destroying keys with a zero usage count. This means that a key can be examined under the RCU read lock in the safe knowledge that it won't get deallocated until after the lock is released - even if its usage count becomes zero whilst we're looking at it. This is useful in keyring search vs key link. Consider a keyring containing a link to a key. That link can be replaced in-place in the keyring without requiring an RCU copy-and-replace on the keyring contents without breaking a search underway on that keyring when the displaced key is released, provided the key is actually destroyed only after the RCU read lock held by the search algorithm is released. This permits __key_link() to replace a key without having to reallocate the key payload. A key gets replaced if a new key being linked into a keyring has the same type and description. Signed-off-by: David Howells <dhowells@redhat.com> Acked-by: Jeff Layton <jlayton@redhat.com>
2012-05-11KEYS: Announce key type (un)registrationDavid Howells1-0/+3
Announce the (un)registration of a key type in the core key code rather than in the callers. Signed-off-by: David Howells <dhowells@redhat.com> Acked-by: Mimi Zohar <zohar@us.ibm.com>
2012-05-11KEYS: Reorganise keys MakefileDavid Howells1-3/+9
Reorganise the keys directory Makefile to put all the core bits together and the type-specific bits after. Signed-off-by: David Howells <dhowells@redhat.com> Acked-by: Mimi Zohar <zohar@us.ibm.com>
2012-05-11KEYS: Move the key config into security/keys/KconfigDavid Howells2-67/+72
Move the key config into security/keys/Kconfig as there are going to be a lot of key-related options. Signed-off-by: David Howells <dhowells@redhat.com> Acked-by: Mimi Zohar <zohar@us.ibm.com>
2012-05-08netfilter: remove ip_queue supportPablo Neira Ayuso1-13/+0
This patch removes ip_queue support which was marked as obsolete years ago. The nfnetlink_queue modules provides more advanced user-space packet queueing mechanism. This patch also removes capability code included in SELinux that refers to ip_queue. Otherwise, we break compilation. Several warning has been sent regarding this to the mailing list in the past month without anyone rising the hand to stop this with some strong argument. Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
2012-05-04Merge tag 'v3.4-rc5' into nextJames Morris3-29/+54
Linux 3.4-rc5 Merge to pull in prerequisite change for Smack: 86812bb0de1a3758dc6c7aa01a763158a7c0638a Requested by Casey.
2012-04-23Yama: remove an unused variableDan Carpenter1-1/+0
GCC complains that we don't use "one" any more after 389da25f93 "Yama: add additional ptrace scopes". security/yama/yama_lsm.c:322:12: warning: ?one? defined but not used [-Wunused-variable] Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Acked-by: Kees Cook <keescook@chromium.org> Signed-off-by: James Morris <james.l.morris@oracle.com>
2012-04-19Yama: add additional ptrace scopesKees Cook1-11/+51
This expands the available Yama ptrace restrictions to include two more modes. Mode 2 requires CAP_SYS_PTRACE for PTRACE_ATTACH, and mode 3 completely disables PTRACE_ATTACH (and locks the sysctl). Signed-off-by: Kees Cook <keescook@chromium.org> Signed-off-by: James Morris <james.l.morris@oracle.com>
2012-04-19security: fix compile error in commoncap.cJonghwan Choi1-0/+1
Add missing "personality.h" security/commoncap.c: In function 'cap_bprm_set_creds': security/commoncap.c:510: error: 'PER_CLEAR_ON_SETID' undeclared (first use in this function) security/commoncap.c:510: error: (Each undeclared identifier is reported only once security/commoncap.c:510: error: for each function it appears in.) Signed-off-by: Jonghwan Choi <jhbird.choi@samsung.com> Acked-by: Serge Hallyn <serge.hallyn@canonical.com> Signed-off-by: James Morris <james.l.morris@oracle.com>
2012-04-18fcaps: clear the same personality flags as suid when fcaps are usedEric Paris1-0/+5
If a process increases permissions using fcaps all of the dangerous personality flags which are cleared for suid apps should also be cleared. Thus programs given priviledge with fcaps will continue to have address space randomization enabled even if the parent tried to disable it to make it easier to attack. Signed-off-by: Eric Paris <eparis@redhat.com> Reviewed-by: Serge Hallyn <serge.hallyn@canonical.com> Signed-off-by: James Morris <james.l.morris@oracle.com>
2012-04-18Smack: move label list initializationCasey Schaufler2-25/+33
A kernel with Smack enabled will fail if tmpfs has xattr support. Move the initialization of predefined Smack label list entries to the LSM initialization from the smackfs setup. This became an issue when tmpfs acquired xattr support, but was never correct. Signed-off-by: Casey Schaufler <casey@schaufler-ca.com> Signed-off-by: James Morris <james.l.morris@oracle.com>
2012-04-14Fix execve behavior apparmor for PR_{GET,SET}_NO_NEW_PRIVSJohn Johansen1-4/+35
Add support for AppArmor to explicitly fail requested domain transitions if NO_NEW_PRIVS is set and the task is not unconfined. Transitions from unconfined are still allowed because this always results in a reduction of privileges. Acked-by: Eric Paris <eparis@redhat.com> Signed-off-by: Will Drewry <wad@chromium.org> Signed-off-by: John Johansen <john.johansen@canonical.com> Signed-off-by: Andy Lutomirski <luto@amacapital.net> v18: new acked-by, new description Signed-off-by: James Morris <james.l.morris@oracle.com>
2012-04-14Add PR_{GET,SET}_NO_NEW_PRIVS to prevent execve from granting privsAndy Lutomirski3-3/+18
With this change, calling prctl(PR_SET_NO_NEW_PRIVS, 1, 0, 0, 0) disables privilege granting operations at execve-time. For example, a process will not be able to execute a setuid binary to change their uid or gid if this bit is set. The same is true for file capabilities. Additionally, LSM_UNSAFE_NO_NEW_PRIVS is defined to ensure that LSMs respect the requested behavior. To determine if the NO_NEW_PRIVS bit is set, a task may call prctl(PR_GET_NO_NEW_PRIVS, 0, 0, 0, 0); It returns 1 if set and 0 if it is not set. If any of the arguments are non-zero, it will return -1 and set errno to -EINVAL. (PR_SET_NO_NEW_PRIVS behaves similarly.) This functionality is desired for the proposed seccomp filter patch series. By using PR_SET_NO_NEW_PRIVS, it allows a task to modify the system call behavior for itself and its child tasks without being able to impact the behavior of a more privileged task. Another potential use is making certain privileged operations unprivileged. For example, chroot may be considered "safe" if it cannot affect privileged tasks. Note, this patch causes execve to fail when PR_SET_NO_NEW_PRIVS is set and AppArmor is in use. It is fixed in a subsequent patch. Signed-off-by: Andy Lutomirski <luto@amacapital.net> Signed-off-by: Will Drewry <wad@chromium.org> Acked-by: Eric Paris <eparis@redhat.com> Acked-by: Kees Cook <keescook@chromium.org> v18: updated change desc v17: using new define values as per 3.4 Signed-off-by: James Morris <james.l.morris@oracle.com>
2012-04-11Smack: build when CONFIG_AUDIT not definedKees Cook1-4/+15
This fixes builds where CONFIG_AUDIT is not defined and CONFIG_SECURITY_SMACK=y. This got introduced by the stack-usage reducation commit 48c62af68a40 ("LSM: shrink the common_audit_data data union"). Signed-off-by: Kees Cook <keescook@chromium.org> Acked-by: Eric Paris <eparis@redhat.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2012-04-09SELinux: remove unused common_audit_data in flush_unauthorized_filesEric Paris1-4/+0
We don't need this variable and it just eats stack space. Remove it. Signed-off-by: Eric Paris <eparis@redhat.com>
2012-04-09SELinux: avc: remove the useless fields in avc_add_callbackWanlong Gao6-47/+15
avc_add_callback now just used for registering reset functions in initcalls, and the callback functions just did reset operations. So, reducing the arguments to only one event is enough now. Signed-off-by: Wanlong Gao <gaowanlong@cn.fujitsu.com> Signed-off-by: Eric Paris <eparis@redhat.com>
2012-04-09SELinux: replace weak GFP_ATOMIC to GFP_KERNEL in avc_add_callbackWanlong Gao1-2/+2
avc_add_callback now only called from initcalls, so replace the weak GFP_ATOMIC to GFP_KERNEL, and mark this function __init to make a warning when not been called from initcalls. Signed-off-by: Wanlong Gao <gaowanlong@cn.fujitsu.com> Signed-off-by: Eric Paris <eparis@redhat.com>
2012-04-09SELinux: unify the selinux_audit_data and selinux_late_audit_dataEric Paris3-91/+16
We no longer need the distinction. We only need data after we decide to do an audit. So turn the "late" audit data into just "data" and remove what we currently have as "data". Signed-off-by: Eric Paris <eparis@redhat.com>
2012-04-09SELinux: remove auditdeny from selinux_audit_dataEric Paris1-8/+1
It's just takin' up space. Signed-off-by: Eric Paris <eparis@redhat.com>
2012-04-09LSM: do not initialize common_audit_data to 0Eric Paris11-44/+44
It isn't needed. If you don't set the type of the data associated with that type it is a pretty obvious programming bug. So why waste the cycles? Signed-off-by: Eric Paris <eparis@redhat.com>
2012-04-09LSM: BUILD_BUG_ON if the common_audit_data union ever growsEric Paris1-0/+7
We did a lot of work to shrink the common_audit_data. Add a BUILD_BUG_ON so future programers (let's be honest, probably me) won't do something foolish like make it large again! Signed-off-by: Eric Paris <eparis@redhat.com>
2012-04-09LSM: remove the task field from common_audit_dataEric Paris2-7/+2
There are no legitimate users. Always use current and get back some stack space for the common_audit_data. Signed-off-by: Eric Paris <eparis@redhat.com>
2012-04-09apparmor: move task from common_audit_data to apparmor_audit_dataEric Paris3-3/+11
apparmor is the only LSM that uses the common_audit_data tsk field. Instead of making all LSMs pay for the stack space move the aa usage into the apparmor_audit_data. Signed-off-by: Eric Paris <eparis@redhat.com>
2012-04-09LSM: remove the COMMON_AUDIT_DATA_INIT type expansionEric Paris10-43/+43
Just open code it so grep on the source code works better. Signed-off-by: Eric Paris <eparis@redhat.com>
2012-04-09SELinux: move common_audit_data to a noinline slow path functionEric Paris1-11/+21
selinux_inode_has_perm is a hot path. Instead of declaring the common_audit_data on the stack move it to a noinline function only used in the rare case we need to send an audit message. Signed-off-by: Eric Paris <eparis@redhat.com>
2012-04-09SELinux: remove inode_has_perm_noadpEric Paris1-24/+4
Both callers could better be using file_has_perm() to get better audit results. Signed-off-by: Eric Paris <eparis@redhat.com>
2012-04-09SELinux: delay initialization of audit data in selinux_inode_permissionEric Paris3-70/+105
We pay a rather large overhead initializing the common_audit_data. Since we only need this information if we actually emit an audit message there is little need to set it up in the hot path. This patch splits the functionality of avc_has_perm() into avc_has_perm_noaudit(), avc_audit_required() and slow_avc_audit(). But we take care of setting up to audit between required() and the actual audit call. Thus saving measurable time in a hot path. Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov> Signed-off-by: Eric Paris <eparis@redhat.com>
2012-04-09SELinux: if sel_make_bools errors don't leave inconsistent stateEric Paris1-0/+1
We reset the bool names and values array to NULL, but do not reset the number of entries in these arrays to 0. If we error out and then get back into this function we will walk these NULL pointers based on the belief that they are non-zero length. Signed-off-by: Eric Paris <eparis@redhat.com> cc: stable@kernel.org
2012-04-09SELinux: remove needless sel_div functionEric Paris1-6/+1
I'm not really sure what the idea behind the sel_div function is, but it's useless. Since a and b are both unsigned, it's impossible for a % b < 0. That means that part of the function never does anything. Thus it's just a normal /. Just do that instead. I don't even understand what that operation was supposed to mean in the signed case however.... If it was signed: sel_div(-2, 4) == ((-2 / 4) - ((-2 % 4) < 0)) ((0) - ((-2) < 0)) ((0) - (1)) (-1) What actually happens: sel_div(-2, 4) == ((18446744073709551614 / 4) - ((18446744073709551614 % 4) < 0)) ((4611686018427387903) - ((2 < 0)) (4611686018427387903 - 0) ((unsigned int)4611686018427387903) (4294967295) Neither makes a whole ton of sense to me. So I'm getting rid of the function entirely. Signed-off-by: Eric Paris <eparis@redhat.com>
2012-04-09SELinux: possible NULL deref in context_struct_to_stringEric Paris1-3/+5
It's possible that the caller passed a NULL for scontext. However if this is a defered mapping we might still attempt to call *scontext=kstrdup(). This is bad. Instead just return the len. Signed-off-by: Eric Paris <eparis@redhat.com>
2012-04-09SELinux: audit failed attempts to set invalid labelsEric Paris1-2/+34
We know that some yum operation is causing CAP_MAC_ADMIN failures. This implies that an RPM is laying down (or attempting to lay down) a file with an invalid label. The problem is that we don't have any information to track down the cause. This patch will cause such a failure to report the failed label in an SELINUX_ERR audit message. This is similar to the SELINUX_ERR reports on invalid transitions and things like that. It should help run down problems on what is trying to set invalid labels in the future. Resulting records look something like: type=AVC msg=audit(1319659241.138:71): avc: denied { mac_admin } for pid=2594 comm="chcon" capability=33 scontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tclass=capability2 type=SELINUX_ERR msg=audit(1319659241.138:71): op=setxattr invalid_context=unconfined_u:object_r:hello:s0 type=SYSCALL msg=audit(1319659241.138:71): arch=c000003e syscall=188 success=no exit=-22 a0=a2c0e0 a1=390341b79b a2=a2d620 a3=1f items=1 ppid=2519 pid=2594 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0 ses=1 comm="chcon" exe="/usr/bin/chcon" subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 key=(null) type=CWD msg=audit(1319659241.138:71): cwd="/root" type=PATH msg=audit(1319659241.138:71): item=0 name="test" inode=785879 dev=fc:03 mode=0100644 ouid=0 ogid=0 rdev=00:00 obj=unconfined_u:object_r:admin_home_t:s0 Signed-off-by: Eric Paris <eparis@redhat.com>
2012-04-09SELinux: rename dentry_open to file_openEric Paris6-15/+15
dentry_open takes a file, rename it to file_open Signed-off-by: Eric Paris <eparis@redhat.com>
2012-04-09SELinux: check OPEN on truncate callsEric Paris1-1/+5
In RH BZ 578841 we realized that the SELinux sandbox program was allowed to truncate files outside of the sandbox. The reason is because sandbox confinement is determined almost entirely by the 'open' permission. The idea was that if the sandbox was unable to open() files it would be unable to do harm to those files. This turns out to be false in light of syscalls like truncate() and chmod() which don't require a previous open() call. I looked at the syscalls that did not have an associated 'open' check and found that truncate(), did not have a seperate permission and even if it did have a separate permission such a permission owuld be inadequate for use by sandbox (since it owuld have to be granted so liberally as to be useless). This patch checks the OPEN permission on truncate. I think a better solution for sandbox is a whole new permission, but at least this fixes what we have today. Signed-off-by: Eric Paris <eparis@redhat.com>
2012-04-09SELinux: add default_type statementsEric Paris4-6/+33
Because Fedora shipped userspace based on my development tree we now have policy version 27 in the wild defining only default user, role, and range. Thus to add default_type we need a policy.28. Signed-off-by: Eric Paris <eparis@redhat.com>
2012-04-09SELinux: allow default source/target selectors for user/role/rangeEric Paris6-8/+109
When new objects are created we have great and flexible rules to determine the type of the new object. We aren't quite as flexible or mature when it comes to determining the user, role, and range. This patch adds a new ability to specify the place a new objects user, role, and range should come from. For users and roles it can come from either the source or the target of the operation. aka for files the user can either come from the source (the running process and todays default) or it can come from the target (aka the parent directory of the new file) examples always are done with directory context: system_u:object_r:mnt_t:s0-s0:c0.c512 process context: unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 [no rule] unconfined_u:object_r:mnt_t:s0 test_none [default user source] unconfined_u:object_r:mnt_t:s0 test_user_source [default user target] system_u:object_r:mnt_t:s0 test_user_target [default role source] unconfined_u:unconfined_r:mnt_t:s0 test_role_source [default role target] unconfined_u:object_r:mnt_t:s0 test_role_target [default range source low] unconfined_u:object_r:mnt_t:s0 test_range_source_low [default range source high] unconfined_u:object_r:mnt_t:s0:c0.c1023 test_range_source_high [default range source low-high] unconfined_u:object_r:mnt_t:s0-s0:c0.c1023 test_range_source_low-high [default range target low] unconfined_u:object_r:mnt_t:s0 test_range_target_low [default range target high] unconfined_u:object_r:mnt_t:s0:c0.c512 test_range_target_high [default range target low-high] unconfined_u:object_r:mnt_t:s0-s0:c0.c512 test_range_target_low-high Signed-off-by: Eric Paris <eparis@redhat.com>