kernel.git/security/smack/smack.h, branch linux-4.16.y

Smack: Privilege check on key operations

2018-01-10T17:29:14Z

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: Jose Bollo Signed-off-by: Casey Schaufler

Smack: Use cap_capable in privilege check

2017-06-01T16:27:21Z

Use cap_capable() rather than capable() in the Smack privilege check as the former does not invoke other security module privilege check, while the later does. This becomes important when stacking. It may be a problem even with minor modules. Signed-off-by: Casey Schaufler

SMACK: Free the i_security blob in inode using RCU

2017-01-10T17:47:20Z

There is race condition issue while freeing the i_security blob in SMACK module. There is existing condition where i_security can be freed while inode_permission is called from path lookup on second CPU. There has been observed the page fault with such condition. VFS code and Selinux module takes care of this condition by freeing the inode and i_security field using RCU via call_rcu(). But in SMACK directly the i_secuirty blob is being freed. Use call_rcu() to fix this race condition issue. Signed-off-by: Himanshu Shukla Signed-off-by: Vishal Goel Signed-off-by: Casey Schaufler

Smack: Fix the issue of wrong SMACK label update in socket bind fail case

2017-01-10T17:47:20Z

Fix the issue of wrong SMACK label (SMACK64IPIN) update when a second bind call is made to same IP address & port, but with different SMACK label (SMACK64IPIN) by second instance of server. In this case server returns with "Bind:Address already in use" error but before returning, SMACK label is updated in SMACK port-label mapping list inside smack_socket_bind() hook To fix this issue a new check has been added in smk_ipv6_port_label() function before updating the existing port entry. It checks whether the socket for matching port entry is closed or not. If it is closed then it means port is not bound and it is safe to update the existing port entry else return if port is still getting used. For checking whether socket is closed or not, one more field "smk_can_reuse" has been added in the "smk_port_label" structure. This field will be set to '1' in "smack_sk_free_security()" function which is called to free the socket security blob when the socket is being closed. In this function, port entry is searched in the SMACK port-label mapping list for the closing socket. If entry is found then "smk_can_reuse" field is set to '1'.Initially "smk_can_reuse" field is set to '0' in smk_ipv6_port_label() function after creating a new entry in the list which indicates that socket is in use. Signed-off-by: Vishal Goel Signed-off-by: Himanshu Shukla Signed-off-by: Casey Schaufler

Smack: Fix the issue of permission denied error in ipv6 hook

2017-01-10T17:47:20Z

Permission denied error comes when 2 IPv6 servers are running and client tries to connect one of them. Scenario is that both servers are using same IP and port but different protocols(Udp and tcp). They are using different SMACK64IPIN labels.Tcp server is using "test" and udp server is using "test-in". When we try to run tcp client with SMACK64IPOUT label as "test", then connection denied error comes. It should not happen since both tcp server and client labels are same.This happens because there is no check for protocol in smk_ipv6_port_label() function while searching for the earlier port entry. It checks whether there is an existing port entry on the basis of port only. So it updates the earlier port entry in the list. Due to which smack label gets changed for earlier entry in the "smk_ipv6_port_list" list and permission denied error comes. Now a check is added for socket type also.Now if 2 processes use same port but different protocols (tcp or udp), then 2 different port entries will be added in the list. Similarly while checking smack access in smk_ipv6_port_check() function, port entry is searched on the basis of both port and protocol. Signed-off-by: Vishal Goel Signed-off-by: Himanshu Shukla Signed-off-by: Casey Schaufler

Smack: Remove unnecessary smack_known_invalid

2016-11-15T17:34:39Z

The invalid Smack label ("") and the Huh ("?") Smack label serve the same purpose and having both is unnecessary. While pulling out the invalid label it became clear that the use of smack_from_secid() was inconsistent, so that is repaired. The setting of inode labels to the invalid label could never happen in a functional system, has never been observed in the wild and is not what you'd really want for a failure behavior in any case. That is removed. Signed-off-by: Casey Schaufler

Smack: Signal delivery as an append operation

2016-09-08T20:22:56Z

Under a strict subject/object security policy delivering a signal or delivering network IPC could be considered either a write or an append operation. The original choice to make both write operations leads to an issue where IPC delivery is desired under policy, but delivery of signals is not. This patch provides the option of making signal delivery an append operation, allowing Smack rules that deny signal delivery while allowing IPC. This was requested for Tizen. Signed-off-by: Casey Schaufler

Smack: Add support for unprivileged mounts from user namespaces

2016-06-24T15:40:42Z

Security labels from unprivileged mounts cannot be trusted. Ideally for these mounts we would assign the objects in the filesystem the same label as the inode for the backing device passed to mount. Unfortunately it's currently impossible to determine which inode this is from the LSM mount hooks, so we settle for the label of the process doing the mount. This label is assigned to s_root, and also to smk_default to ensure that new inodes receive this label. The transmute property is also set on s_root to make this behavior more explicit, even though it is technically not necessary. If a filesystem has existing security labels, access to inodes is permitted if the label is the same as smk_root, otherwise access is denied. The SMACK64EXEC xattr is completely ignored. Explicit setting of security labels continues to require CAP_MAC_ADMIN in init_user_ns. Altogether, this ensures that filesystem objects are not accessible to subjects which cannot already access the backing store, that MAC is not violated for any objects in the fileystem which are already labeled, and that a user cannot use an unprivileged mount to gain elevated MAC privileges. sysfs, tmpfs, and ramfs are already mountable from user namespaces and support security labels. We can't rule out the possibility that these filesystems may already be used in mounts from user namespaces with security lables set from the init namespace, so failing to trust lables in these filesystems may introduce regressions. It is safe to trust labels from these filesystems, since the unprivileged user does not control the backing store and thus cannot supply security labels, so an explicit exception is made to trust labels from these filesystems. Signed-off-by: Seth Forshee Acked-by: Casey Schaufler Signed-off-by: Eric W. Biederman

Smack: limited capability for changing process label

2015-10-19T19:06:47Z

This feature introduces new kernel interface: - /relabel-self - for setting transition labels list This list is used to control smack label transition mechanism. List is set by, and per process. Process can transit to new label only if label is on the list. Only process with CAP_MAC_ADMIN capability can add labels to this list. With this list, process can change it's label without CAP_MAC_ADMIN but only once. After label changing, list is unset. Changes in v2: * use list_for_each_entry instead of _rcu during label write * added missing description in security/Smack.txt Changes in v3: * squashed into one commit Changes in v4: * switch from global list to per-task list * since the per-task list is accessed only by the task itself there is no need to use synchronization mechanisms on it Changes in v5: * change smackfs interface of relabel-self to the one used for onlycap multiple labels are accepted, separated by space, which replace the previous list upon write Signed-off-by: Zbigniew Jasinski Signed-off-by: Rafal Krypa Acked-by: Casey Schaufler

Smack: IPv6 host labeling

2015-07-28T13:35:21Z

IPv6 appears to be (finally) coming of age with the influx of autonomous devices. In support of this, add the ability to associate a Smack label with IPv6 addresses. This patch also cleans up some of the conditional compilation associated with the introduction of secmark processing. It's now more obvious which bit of code goes with which feature. Signed-off-by: Casey Schaufler