summaryrefslogtreecommitdiff
path: root/security/smack/smack.h
AgeCommit message (Collapse)AuthorFilesLines
2017-06-01Smack: Use cap_capable in privilege checkCasey Schaufler1-1/+1
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 <casey@schaufler-ca.com>
2017-01-10SMACK: Free the i_security blob in inode using RCUHimanshu Shukla1-0/+1
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 <himanshu.sh@samsung.com> Signed-off-by: Vishal Goel <vishal.goel@samsung.com> Signed-off-by: Casey Schaufler <casey@schaufler-ca.com>
2017-01-10Smack: Fix the issue of wrong SMACK label update in socket bind fail caseVishal Goel1-0/+1
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 <vishal.goel@samsung.com> Signed-off-by: Himanshu Shukla <himanshu.sh@samsung.com> Signed-off-by: Casey Schaufler <casey@schaufler-ca.com>
2017-01-10Smack: Fix the issue of permission denied error in ipv6 hookVishal Goel1-0/+1
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 <vishal.goel@samsung.com> Signed-off-by: Himanshu Shukla <Himanshu.sh@samsung.com> Signed-off-by: Casey Schaufler <casey@schaufler-ca.com>
2016-11-15Smack: Remove unnecessary smack_known_invalidCasey Schaufler1-1/+0
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 <casey@schaufler-ca.com>
2016-09-08Smack: Signal delivery as an append operationCasey Schaufler1-0/+10
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 <casey@schaufler-ca.com>
2016-06-24Smack: Add support for unprivileged mounts from user namespacesSeth Forshee1-1/+7
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 <seth.forshee@canonical.com> Acked-by: Casey Schaufler <casey@schaufler-ca.com> Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
2015-10-19Smack: limited capability for changing process labelZbigniew Jasinski1-1/+3
This feature introduces new kernel interface: - <smack_fs>/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 <z.jasinski@samsung.com> Signed-off-by: Rafal Krypa <r.krypa@samsung.com> Acked-by: Casey Schaufler <casey@schaufler-ca.com>
2015-07-28Smack: IPv6 host labelingCasey Schaufler1-9/+39
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 <casey@schaufler-ca.com>
2015-07-22smack: allow mount opts setting over filesystems with binary mount dataVivek Trivedi1-0/+18
Add support for setting smack mount labels(using smackfsdef, smackfsroot, smackfshat, smackfsfloor, smackfstransmute) for filesystems with binary mount data like NFS. To achieve this, implement sb_parse_opts_str and sb_set_mnt_opts security operations in smack LSM similar to SELinux. Signed-off-by: Vivek Trivedi <t.vivek@samsung.com> Signed-off-by: Amit Sahrawat <a.sahrawat@samsung.com> Acked-by: Casey Schaufler <casey@schaufler-ca.com>
2015-06-02Smack: allow multiple labels in onlycapRafal Krypa1-16/+9
Smack onlycap allows limiting of CAP_MAC_ADMIN and CAP_MAC_OVERRIDE to processes running with the configured label. But having single privileged label is not enough in some real use cases. On a complex system like Tizen, there maybe few programs that need to configure Smack policy in run-time and running them all with a single label is not always practical. This patch extends onlycap feature for multiple labels. They are configured in the same smackfs "onlycap" interface, separated by spaces. Signed-off-by: Rafal Krypa <r.krypa@samsung.com>
2015-05-12LSM: Switch to lists of hooksCasey Schaufler1-2/+0
Instead of using a vector of security operations with explicit, special case stacking of the capability and yama hooks use lists of hooks with capability and yama hooks included as appropriate. The security_operations structure is no longer required. Instead, there is a union of the function pointers that allows all the hooks lists to use a common mechanism for list management while retaining typing. Each module supplies an array describing the hooks it provides instead of a sparsely populated security_operations structure. The description includes the element that gets put on the hook list, avoiding the issues surrounding individual element allocation. The method for registering security modules is changed to reflect the information available. The method for removing a module, currently only used by SELinux, has also changed. It should be generic now, however if there are potential race conditions based on ordering of hook removal that needs to be addressed by the calling module. The security hooks are called from the lists and the first failure is returned. Signed-off-by: Casey Schaufler <casey@schaufler-ca.com> Acked-by: John Johansen <john.johansen@canonical.com> Acked-by: Kees Cook <keescook@chromium.org> Acked-by: Paul Moore <paul@paul-moore.com> Acked-by: Stephen Smalley <sds@tycho.nsa.gov> Acked-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> Signed-off-by: James Morris <james.l.morris@oracle.com>
2015-05-12LSM: Split security.hCasey Schaufler1-1/+1
The security.h header file serves two purposes, interfaces for users of the security modules and interfaces for security modules. Users of the security modules don't need to know about what's in the security_operations structure, so pull it out into it's own header, lsm_hooks.h Signed-off-by: Casey Schaufler <casey@schaufler-ca.com> Acked-by: John Johansen <john.johansen@canonical.com> Acked-by: Kees Cook <keescook@chromium.org> Acked-by: Paul Moore <paul@paul-moore.com> Acked-by: Stephen Smalley <sds@tycho.nsa.gov> Acked-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> Signed-off-by: James Morris <james.l.morris@oracle.com>
2015-03-23Smack: Allow an unconfined label in bringup modeCasey Schaufler1-0/+8
I have vehemently opposed adding a "permissive" mode to Smack for the simple reasons that it would be subject to massive abuse and that developers refuse to turn it off come product release. I still believe that this is true, and still refuse to add a general "permissive mode". So don't ask again. Bumjin Im suggested an approach that addresses most of the concerns, and I have implemented it here. I still believe that we'd be better off without this sort of thing, but it looks like this minimizes the abuse potential. Firstly, you have to configure Smack Bringup Mode. That allows for "release" software to be ammune from abuse. Second, only one label gets to be "permissive" at a time. You can use it for debugging, but that's about it. A label written to smackfs/unconfined is treated specially. If either the subject or object label of an access check matches the "unconfined" label, and the access would not have been allowed otherwise an audit record and a console message are generated. The audit record "request" string is marked with either "(US)" or "(UO)", to indicate that the request was granted because of an unconfined label. The fact that an inode was accessed by an unconfined label is remembered, and subsequent accesses to that "impure" object are noted in the log. The impurity is not stored in the filesystem, so a file mislabled as a side effect of using an unconfined label may still cause concern after a reboot. So, it's there, it's dangerous, but so many application developers seem incapable of living without it I have given in. I've tried to make it as safe as I can, but in the end it's still a chain saw. Signed-off-by: Casey Schaufler <casey@schaufler-ca.com>
2015-01-21smack: fix possible use after frees in task_security() callersAndrey Ryabinin1-0/+10
We hit use after free on dereferncing pointer to task_smack struct in smk_of_task() called from smack_task_to_inode(). task_security() macro uses task_cred_xxx() to get pointer to the task_smack. task_cred_xxx() could be used only for non-pointer members of task's credentials. It cannot be used for pointer members since what they point to may disapper after dropping RCU read lock. Mainly task_security() used this way: smk_of_task(task_security(p)) Intead of this introduce function smk_of_task_struct() which takes task_struct as argument and returns pointer to smk_known struct and do this under RCU read lock. Bogus task_security() macro is not used anymore, so remove it. KASan's report for this: AddressSanitizer: use after free in smack_task_to_inode+0x50/0x70 at addr c4635600 ============================================================================= BUG kmalloc-64 (Tainted: PO): kasan error ----------------------------------------------------------------------------- Disabling lock debugging due to kernel taint INFO: Allocated in new_task_smack+0x44/0xd8 age=39 cpu=0 pid=1866 kmem_cache_alloc_trace+0x88/0x1bc new_task_smack+0x44/0xd8 smack_cred_prepare+0x48/0x21c security_prepare_creds+0x44/0x4c prepare_creds+0xdc/0x110 smack_setprocattr+0x104/0x150 security_setprocattr+0x4c/0x54 proc_pid_attr_write+0x12c/0x194 vfs_write+0x1b0/0x370 SyS_write+0x5c/0x94 ret_fast_syscall+0x0/0x48 INFO: Freed in smack_cred_free+0xc4/0xd0 age=27 cpu=0 pid=1564 kfree+0x270/0x290 smack_cred_free+0xc4/0xd0 security_cred_free+0x34/0x3c put_cred_rcu+0x58/0xcc rcu_process_callbacks+0x738/0x998 __do_softirq+0x264/0x4cc do_softirq+0x94/0xf4 irq_exit+0xbc/0x120 handle_IRQ+0x104/0x134 gic_handle_irq+0x70/0xac __irq_svc+0x44/0x78 _raw_spin_unlock+0x18/0x48 sync_inodes_sb+0x17c/0x1d8 sync_filesystem+0xac/0xfc vdfs_file_fsync+0x90/0xc0 vfs_fsync_range+0x74/0x7c INFO: Slab 0xd3b23f50 objects=32 used=31 fp=0xc4635600 flags=0x4080 INFO: Object 0xc4635600 @offset=5632 fp=0x (null) Bytes b4 c46355f0: 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a ZZZZZZZZZZZZZZZZ Object c4635600: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk Object c4635610: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk Object c4635620: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk Object c4635630: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b a5 kkkkkkkkkkkkkkk. Redzone c4635640: bb bb bb bb .... Padding c46356e8: 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a ZZZZZZZZZZZZZZZZ Padding c46356f8: 5a 5a 5a 5a 5a 5a 5a 5a ZZZZZZZZ CPU: 5 PID: 834 Comm: launchpad_prelo Tainted: PBO 3.10.30 #1 Backtrace: [<c00233a4>] (dump_backtrace+0x0/0x158) from [<c0023dec>] (show_stack+0x20/0x24) r7:c4634010 r6:d3b23f50 r5:c4635600 r4:d1002140 [<c0023dcc>] (show_stack+0x0/0x24) from [<c06d6d7c>] (dump_stack+0x20/0x28) [<c06d6d5c>] (dump_stack+0x0/0x28) from [<c01c1d50>] (print_trailer+0x124/0x144) [<c01c1c2c>] (print_trailer+0x0/0x144) from [<c01c1e88>] (object_err+0x3c/0x44) r7:c4635600 r6:d1002140 r5:d3b23f50 r4:c4635600 [<c01c1e4c>] (object_err+0x0/0x44) from [<c01cac18>] (kasan_report_error+0x2b8/0x538) r6:d1002140 r5:d3b23f50 r4:c6429cf8 r3:c09e1aa7 [<c01ca960>] (kasan_report_error+0x0/0x538) from [<c01c9430>] (__asan_load4+0xd4/0xf8) [<c01c935c>] (__asan_load4+0x0/0xf8) from [<c031e168>] (smack_task_to_inode+0x50/0x70) r5:c4635600 r4:ca9da000 [<c031e118>] (smack_task_to_inode+0x0/0x70) from [<c031af64>] (security_task_to_inode+0x3c/0x44) r5:cca25e80 r4:c0ba9780 [<c031af28>] (security_task_to_inode+0x0/0x44) from [<c023d614>] (pid_revalidate+0x124/0x178) r6:00000000 r5:cca25e80 r4:cbabe3c0 r3:00008124 [<c023d4f0>] (pid_revalidate+0x0/0x178) from [<c01db98c>] (lookup_fast+0x35c/0x43y4) r9:c6429efc r8:00000101 r7:c079d940 r6:c6429e90 r5:c6429ed8 r4:c83c4148 [<c01db630>] (lookup_fast+0x0/0x434) from [<c01deec8>] (do_last.isra.24+0x1c0/0x1108) [<c01ded08>] (do_last.isra.24+0x0/0x1108) from [<c01dff04>] (path_openat.isra.25+0xf4/0x648) [<c01dfe10>] (path_openat.isra.25+0x0/0x648) from [<c01e1458>] (do_filp_open+0x3c/0x88) [<c01e141c>] (do_filp_open+0x0/0x88) from [<c01ccb28>] (do_sys_open+0xf0/0x198) r7:00000001 r6:c0ea2180 r5:0000000b r4:00000000 [<c01cca38>] (do_sys_open+0x0/0x198) from [<c01ccc00>] (SyS_open+0x30/0x34) [<c01ccbd0>] (SyS_open+0x0/0x34) from [<c001db80>] (ret_fast_syscall+0x0/0x48) Read of size 4 by thread T834: Memory state around the buggy address: c4635380: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc c4635400: 00 00 00 00 00 00 00 00 fc fc fc fc fc fc fc fc c4635480: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc c4635500: 00 00 00 00 00 fc fc fc fc fc fc fc fc fc fc fc c4635580: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc >c4635600: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ^ c4635680: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb c4635700: 00 00 00 00 04 fc fc fc fc fc fc fc fc fc fc fc c4635780: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc c4635800: 00 00 00 00 00 00 04 fc fc fc fc fc fc fc fc fc c4635880: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc ================================================================== Signed-off-by: Andrey Ryabinin <a.ryabinin@samsung.com> Cc: <stable@vger.kernel.org>
2015-01-20Smack: secmark support for netfilterCasey Schaufler1-0/+1
Smack uses CIPSO to label internet packets and thus provide for access control on delivery of packets. The netfilter facility was not used to allow for Smack to work properly without netfilter configuration. Smack does not need netfilter, however there are cases where it would be handy. As a side effect, the labeling of local IPv4 packets can be optimized and the handling of local IPv6 packets is just all out better. The best part is that the netfilter tools use "contexts" that are just strings, and they work just as well for Smack as they do for SELinux. All of the conditional compilation for IPv6 was implemented by Rafal Krypa <r.krypa@samsung.com> Signed-off-by: Casey Schaufler <casey@schaufler-ca.com>
2014-08-29Make Smack operate on smack_known struct where it still used char*Lukasz Pawelczyk1-17/+17
Smack used to use a mix of smack_known struct and char* throughout its APIs and implementation. This patch unifies the behaviour and makes it store and operate exclusively on smack_known struct pointers when managing labels. Signed-off-by: Lukasz Pawelczyk <l.pawelczyk@samsung.com> Conflicts: security/smack/smack_access.c security/smack/smack_lsm.c
2014-08-28Smack: Bring-up access modeCasey Schaufler1-2/+3
People keep asking me for permissive mode, and I keep saying "no". Permissive mode is wrong for more reasons than I can enumerate, but the compelling one is that it's once on, never off. Nonetheless, there is an argument to be made for running a process with lots of permissions, logging which are required, and then locking the process down. There wasn't a way to do that with Smack, but this provides it. The notion is that you start out by giving the process an appropriate Smack label, such as "ATBirds". You create rules with a wide range of access and the "b" mode. On Tizen it might be: ATBirds System rwxalb ATBirds User rwxalb ATBirds _ rwxalb User ATBirds wb System ATBirds wb Accesses that fail will generate audit records. Accesses that succeed because of rules marked with a "b" generate log messages identifying the rule, the program and as much object information as is convenient. When the system is properly configured and the programs brought in line with the labeling scheme the "b" mode can be removed from the rules. When the system is ready for production the facility can be configured out. This provides the developer the convenience of permissive mode without creating a system that looks like it is enforcing a policy while it is not. Signed-off-by: Casey Schaufler <casey@schaufler-ca.com>
2014-04-11Smack: bidirectional UDS connect checkCasey Schaufler1-3/+3
Smack IPC policy requires that the sender have write access to the receiver. UDS streams don't do per-packet checks. The only check is done at connect time. The existing code checks if the connecting process can write to the other, but not the other way around. This change adds a check that the other end can write to the connecting process. Targeted for git://git.gitorious.org/smack-next/kernel.git Signed-off-by: Casey Schuafler <casey@schaufler-ca.com>
2014-04-11Smack: adds smackfs/ptrace interfaceLukasz Pawelczyk1-0/+9
This allows to limit ptrace beyond the regular smack access rules. It adds a smackfs/ptrace interface that allows smack to be configured to require equal smack labels for PTRACE_MODE_ATTACH access. See the changes in Documentation/security/Smack.txt below for details. Signed-off-by: Lukasz Pawelczyk <l.pawelczyk@partner.samsung.com> Signed-off-by: Rafal Krypa <r.krypa@samsung.com>
2014-04-11Smack: fix the subject/object order in smack_ptrace_traceme()Lukasz Pawelczyk1-0/+1
The order of subject/object is currently reversed in smack_ptrace_traceme(). It is currently checked if the tracee has a capability to trace tracer and according to this rule a decision is made whether the tracer will be allowed to trace tracee. Signed-off-by: Lukasz Pawelczyk <l.pawelczyk@partner.samsung.com> Signed-off-by: Rafal Krypa <r.krypa@samsung.com>
2013-12-23Smack: Make the syslog control configurableCasey Schaufler1-2/+3
The syslog control requires that the calling proccess have the floor ("_") Smack label. Tizen does not run any processes except for kernel helpers with the floor label. This changes allows the admin to configure a specific label for syslog. The default value is the star ("*") label, effectively removing the restriction. The value can be set using smackfs/syslog for anyone who wants a more restrictive behavior. Targeted for git://git.gitorious.org/smack-next/kernel.git Signed-off-by: Casey Schaufler <casey@schaufler-ca.com>
2013-10-18Smack: Implement lock security modeCasey Schaufler1-4/+8
Linux file locking does not follow the same rules as other mechanisms. Even though it is a write operation a process can set a read lock on files which it has open only for read access. Two programs with read access to a file can use read locks to communicate. This is not acceptable in a Mandatory Access Control environment. Smack treats setting a read lock as the write operation that it is. Unfortunately, many programs assume that setting a read lock is a read operation. These programs are unhappy in the Smack environment. This patch introduces a new access mode (lock) to address this problem. A process with lock access to a file can set a read lock. A process with write access to a file can set a read lock or a write lock. This prevents a situation where processes are granted write access just so they can set read locks. Targeted for git://git.gitorious.org/smack-next/kernel.git Signed-off-by: Casey Schaufler <casey@schaufler-ca.com>
2013-08-01Smack: network label match fixCasey Schaufler1-2/+6
The Smack code that matches incoming CIPSO tags with Smack labels reaches through the NetLabel interfaces and compares the network data with the CIPSO header associated with a Smack label. This was done in a ill advised attempt to optimize performance. It works so long as the categories fit in a single capset, but this isn't always the case. This patch changes the Smack code to use the appropriate NetLabel interfaces to compare the incoming CIPSO header with the CIPSO header associated with a label. It will always match the CIPSO headers correctly. Targeted for git://git.gitorious.org/smack-next/kernel.git Signed-off-by: Casey Schaufler <casey@schaufler-ca.com>
2013-08-01security: smack: add a hash table to quicken smk_find_entry()Tomasz Stanislawski1-0/+5
Accepted for the smack-next tree after changing the number of slots from 128 to 16. This patch adds a hash table to quicken searching of a smack label by its name. Basically, the patch improves performance of SMACK initialization. Parsing of rules involves translation from a string to a smack_known (aka label) entity which is done in smk_find_entry(). The current implementation of the function iterates over a global list of smack_known resulting in O(N) complexity for smk_find_entry(). The total complexity of SMACK initialization becomes O(rules * labels). Therefore it scales quadratically with a complexity of a system. Applying the patch reduced the complexity of smk_find_entry() to O(1) as long as number of label is in hundreds. If the number of labels is increased please update SMACK_HASH_SLOTS constant defined in security/smack/smack.h. Introducing the configuration of this constant with Kconfig or cmdline might be a good idea. The size of the hash table was adjusted experimentally. The rule set used by TIZEN contains circa 17K rules for 500 labels. The table above contains results of SMACK initialization using 'time smackctl apply' bash command. The 'Ref' is a kernel without this patch applied. The consecutive values refers to value of SMACK_HASH_SLOTS. Every measurement was repeated three times to reduce noise. | Ref | 1 | 2 | 4 | 8 | 16 | 32 | 64 | 128 | 256 | 512 -------------------------------------------------------------------------------------------- Run1 | 1.156 | 1.096 | 0.883 | 0.764 | 0.692 | 0.667 | 0.649 | 0.633 | 0.634 | 0.629 | 0.620 Run2 | 1.156 | 1.111 | 0.885 | 0.764 | 0.694 | 0.661 | 0.649 | 0.651 | 0.634 | 0.638 | 0.623 Run3 | 1.160 | 1.107 | 0.886 | 0.764 | 0.694 | 0.671 | 0.661 | 0.638 | 0.631 | 0.624 | 0.638 AVG | 1.157 | 1.105 | 0.885 | 0.764 | 0.693 | 0.666 | 0.653 | 0.641 | 0.633 | 0.630 | 0.627 Surprisingly, a single hlist is slightly faster than a double-linked list. The speed-up saturates near 64 slots. Therefore I chose value 128 to provide some margin if more labels were used. It looks that IO becomes a new bottleneck. Signed-off-by: Tomasz Stanislawski <t.stanislaws@samsung.com>
2013-05-28Smack: Add smkfstransmute mount optionCasey Schaufler1-0/+1
Suppliment the smkfsroot mount option with another, smkfstransmute, that does the same thing but also marks the root inode as transmutting. This allows a freshly created filesystem to be mounted with a transmutting heirarchy. Targeted for git://git.gitorious.org/smack-next/kernel.git Signed-off-by: Casey Schaufler <casey@schaufler-ca.com>
2013-05-28Smack: Improve access check performanceCasey Schaufler1-53/+55
Each Smack label that the kernel has seen is added to a list of labels. The list of access rules for a given subject label hangs off of the label list entry for the label. This patch changes the structures that contain subject labels to point at the label list entry rather that the label itself. Doing so removes a label list lookup in smk_access() that was accounting for the largest single chunk of Smack overhead. Targeted for git://git.gitorious.org/smack-next/kernel.git Signed-off-by: Casey Schaufler <casey@schaufler-ca.com>
2013-05-28Smack: Local IPv6 port based controlsCasey Schaufler1-0/+11
Smack does not provide access controls on IPv6 communications. This patch introduces a mechanism for maintaining Smack lables for local IPv6 communications. It is based on labeling local ports. The behavior should be compatible with any future "real" IPv6 support as it provides no interfaces for users to manipulate the labeling. Remote IPv6 connections use the ambient label the same way that unlabeled IPv4 packets are treated. Targeted for git://git.gitorious.org/smack-next/kernel.git Signed-off-by: Casey Schaufler <casey@schaufler-ca.com>
2013-03-19smack: SMACK_MAGIC to include/uapi/linux/magic.hJarkko Sakkinen1-5/+0
SMACK_MAGIC moved to a proper place for easy user space access (i.e. libsmack). Signed-off-by: Jarkko Sakkinen <jarkko.sakkinen@iki.fi>
2012-07-13Smack: onlycap limits on CAP_MAC_ADMINCasey Schaufler1-0/+13
Smack is integrated with the POSIX capabilities scheme, using the capabilities CAP_MAC_OVERRIDE and CAP_MAC_ADMIN to determine if a process is allowed to ignore Smack checks or change Smack related data respectively. Smack provides an additional restriction that if an onlycap value is set by writing to /smack/onlycap only tasks with that Smack label are allowed to use CAP_MAC_OVERRIDE. This change adds CAP_MAC_ADMIN as a capability that is affected by the onlycap mechanism. Targeted for git://git.gitorious.org/smack-next/kernel.git Signed-off-by: Casey Schaufler <casey@schaufler-ca.com>
2012-07-13Smack: fix smack_new_inode bogositiesCasey Schaufler1-1/+0
In January of 2012 Al Viro pointed out three bits of code that he titled "new_inode_smack bogosities". This patch repairs these errors. 1. smack_sb_kern_mount() included a NULL check that is impossible. The check and NULL case are removed. 2. smack_kb_kern_mount() included pointless locking. The locking is removed. Since this is the only place that lock was used the lock is removed from the superblock_smack structure. 3. smk_fill_super() incorrectly and unnecessarily set the Smack label for the smackfs root inode. The assignment has been removed. Targeted for git://gitorious.org/smack-next/kernel.git Signed-off-by: Casey Schaufler <casey@schaufler-ca.com>
2012-05-22Merge branch 'master' of git://git.infradead.org/users/eparis/selinux into nextJames Morris1-1/+1
Per pull request, for 3.5.
2012-05-14Smack: allow for significantly longer Smack labels v4Casey Schaufler1-36/+20
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-14Smack: recursive tramsmuteCasey Schaufler1-0/+1
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-04-09LSM: do not initialize common_audit_data to 0Eric Paris1-1/+1
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-03LSM: shrink the common_audit_data data unionEric Paris1-1/+9
After shrinking the common_audit_data stack usage for private LSM data I'm not going to shrink the data union. To do this I'm going to move anything larger than 2 void * ptrs to it's own structure and require it to be declared separately on the calling stack. Thus hot paths which don't need more than a couple pointer don't have to declare space to hold large unneeded structures. I could get this down to one void * by dealing with the key struct and the struct path. We'll see if that is helpful after taking care of networking. Signed-off-by: Eric Paris <eparis@redhat.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2012-04-03LSM: shrink sizeof LSM specific portion of common_audit_dataEric Paris1-1/+12
Linus found that the gigantic size of the common audit data caused a big perf hit on something as simple as running stat() in a loop. This patch requires LSMs to declare the LSM specific portion separately rather than doing it in a union. Thus each LSM can be responsible for shrinking their portion and don't have to pay a penalty just because other LSMs have a bigger space requirement. Signed-off-by: Eric Paris <eparis@redhat.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2011-10-20Smack: allow to access /smack/access as normal userJarkko Sakkinen1-0/+1
Allow query access as a normal user removing the need for CAP_MAC_ADMIN. Give RW access to /smack/access for UGO. Do not import smack labels in access check. Signed-off-by: Jarkko Sakkinen <jarkko.j.sakkinen@gmail.com> Signed-off-by: Casey Schaufler <cschaufler@cschaufler-intel.(none)>
2011-10-12Smack: Clean up commentsCasey Schaufler1-3/+2
There are a number of comments in the Smack code that are either malformed or include code. This patch cleans them up. Signed-off-by: Casey Schaufler <casey@schaufler-ca.com>
2011-10-12Smack: Rule list lookup performanceCasey Schaufler1-6/+12
This patch is targeted for the smack-next tree. Smack access checks suffer from two significant performance issues. In cases where there are large numbers of rules the search of the single list of rules is wasteful. Comparing the string values of the smack labels is less efficient than a numeric comparison would. These changes take advantage of the Smack label list, which maintains the mapping of Smack labels to secids and optional CIPSO labels. Because the labels are kept perpetually, an access check can be done strictly based on the address of the label in the list without ever looking at the label itself. Rather than keeping one global list of rules the rules with a particular subject label can be based off of that label list entry. The access check need never look at entries that do not use the current subject label. This requires that packets coming off the network with CIPSO direct Smack labels that have never been seen before be treated carefully. The only case where they could be delivered is where the receiving socket has an IPIN star label, so that case is explicitly addressed. On a system with 39,800 rules (200 labels in all permutations) a system with this patch runs an access speed test in 5% of the time of the old version. That should be a best case improvement. If all of the rules are associated with the same subject label and all of the accesses are for processes with that label (unlikely) the improvement is about 30%. Signed-off-by: Casey Schaufler <casey@schaufler-ca.com>
2011-04-25LSM: separate LSM_AUDIT_DATA_DENTRY from LSM_AUDIT_DATA_PATHEric Paris1-6/+1
This patch separates and audit message that only contains a dentry from one that contains a full path. This allows us to make it harder to misuse the interfaces or for the interfaces to be implemented wrong. Signed-off-by: Eric Paris <eparis@redhat.com> Acked-by: Casey Schaufler <casey@schaufler-ca.com>
2011-04-25LSM: split LSM_AUDIT_DATA_FS into _PATH and _INODEEric Paris1-4/+4
The lsm common audit code has wacky contortions making sure which pieces of information are set based on if it was given a path, dentry, or inode. Split this into path and inode to get rid of some of the code complexity. Signed-off-by: Eric Paris <eparis@redhat.com> Acked-by: Casey Schaufler <casey@schaufler-ca.com>
2011-02-09security:smack: kill unused SMACK_LIST_MAX, MAY_ANY and MAY_ANYWRITEShan Wei1-8/+0
Kill unused macros of SMACK_LIST_MAX, MAY_ANY and MAY_ANYWRITE. v2: As Casey Schaufler's advice, also remove MAY_ANY. Signed-off-by: Shan Wei <shanwei@cn.fujitsu.com> Signed-off-by: Casey Schaufler <casey@schaufler-ca.com>
2011-01-17Subject: [PATCH] Smack: mmap controls for library containmentCasey Schaufler1-3/+6
In the embedded world there are often situations where libraries are updated from a variety of sources, for a variety of reasons, and with any number of security characteristics. These differences might include privilege required for a given library provided interface to function properly, as occurs from time to time in graphics libraries. There are also cases where it is important to limit use of libraries based on the provider of the library and the security aware application may make choices based on that criteria. These issues are addressed by providing an additional Smack label that may optionally be assigned to an object, the SMACK64MMAP attribute. An mmap operation is allowed if there is no such attribute. If there is a SMACK64MMAP attribute the mmap is permitted only if a subject with that label has all of the access permitted a subject with the current task label. Security aware applications may from time to time wish to reduce their "privilege" to avoid accidental use of privilege. One case where this arises is the environment in which multiple sources provide libraries to perform the same functions. An application may know that it should eschew services made available from a particular vendor, or of a particular version. In support of this a secondary list of Smack rules has been added that is local to the task. This list is consulted only in the case where the global list has approved access. It can only further restrict access. Unlike the global last, if no entry is found on the local list access is granted. An application can add entries to its own list by writing to /smack/load-self. The changes appear large as they involve refactoring the list handling to accomodate there being more than one rule list. Signed-off-by: Casey Schaufler <casey@schaufler-ca.com>
2010-12-07Smack: Transmute labels on specified directoriesJarkko Sakkinen1-1/+16
In a situation where Smack access rules allow processes with multiple labels to write to a directory it is easy to get into a situation where the directory gets cluttered with files that the owner can't deal with because while they could be written to the directory a process at the label of the directory can't write them. This is generally the desired behavior, but when it isn't it is a real issue. This patch introduces a new attribute SMACK64TRANSMUTE that instructs Smack to create the file with the label of the directory under certain circumstances. A new access mode, "t" for transmute, is made available to Smack access rules, which are expanded from "rwxa" to "rwxat". If a file is created in a directory marked as transmutable and if access was granted to perform the operation by a rule that included the transmute mode, then the file gets the Smack label of the directory instead of the Smack label of the creating process. Note that this is equivalent to creating an empty file at the label of the directory and then having the other process write to it. The transmute scheme requires that both the access rule allows transmutation and that the directory be explicitly marked. Signed-off-by: Jarkko Sakkinen <ext-jarkko.2.sakkinen@nokia.com> Signed-off-by: Casey Schaufler <casey@schaufler-ca.com>
2010-12-02This patch adds a new security attribute to Smack calledCasey Schaufler1-0/+30
SMACK64EXEC. It defines label that is used while task is running. Exception: in smack_task_wait() child task is checked for write access to parent task using label inherited from the task that forked it. Fixed issues from previous submit: - SMACK64EXEC was not read when SMACK64 was not set. - inode security blob was not updated after setting SMACK64EXEC - inode security blob was not updated when removing SMACK64EXEC
2010-08-02security: move LSM xattrnames to xattr.hMimi Zohar1-10/+0
Make the security extended attributes names global. Updated to move the remaining Smack xattrs. Signed-off-by: Mimi Zohar <zohar@us.ibm.com> Acked-by: Serge Hallyn <serue@us.ibm.com> Signed-off-by: James Morris <jmorris@namei.org>
2009-07-10security: Make lsm_priv union in lsm_audit.h anonymousThomas Liu1-1/+1
Made the lsm_priv union in include/linux/lsm_audit.h anonymous. Signed-off-by: Thomas Liu <tliu@redhat.com> Acked-by: Eric Paris <eparis@redhat.com> Signed-off-by: James Morris <jmorris@namei.org>
2009-07-10Move variable function in lsm_audit.h into SMACK private spaceThomas Liu1-1/+1
Moved variable function in include/linux/lsm_audit.h into the smack_audit_data struct since it is never used outside of it. Also removed setting of function in the COMMON_AUDIT_DATA_INIT macro because that variable is now private to SMACK. Signed-off-by: Thomas Liu <tliu@redhat.com> Acked-by: Eric Paris <eparis@redhat.com> I-dont-see-any-problems-with-it: Casey Schaufler <casey@schaufler-ca.com> Signed-off-by: James Morris <jmorris@namei.org>
2009-04-14smack: implement logging V3Etienne Basset1-2/+106
the following patch, add logging of Smack security decisions. This is of course very useful to understand what your current smack policy does. As suggested by Casey, it also now forbids labels with ', " or \ It introduces a '/smack/logging' switch : 0: no logging 1: log denied (default) 2: log accepted 3: log denied&accepted Signed-off-by: Etienne Basset <etienne.basset@numericable.fr> Acked-by: Casey Schaufler <casey@schaufler-ca.com> Acked-by: Eric Paris <eparis@redhat.com> Signed-off-by: James Morris <jmorris@namei.org>