16 Nov, 2016
1 commit
-
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
09 Sep, 2016
1 commit
-
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
24 Jun, 2016
1 commit
-
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
20 Oct, 2015
1 commit
-
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.txtChanges in v3:
* squashed into one commitChanges 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 itChanges 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 writeSigned-off-by: Zbigniew Jasinski
Signed-off-by: Rafal Krypa
Acked-by: Casey Schaufler
28 Jul, 2015
1 commit
-
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
23 Jul, 2015
1 commit
-
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
Signed-off-by: Amit Sahrawat
Acked-by: Casey Schaufler
03 Jun, 2015
1 commit
-
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
12 May, 2015
2 commits
-
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
Acked-by: John Johansen
Acked-by: Kees Cook
Acked-by: Paul Moore
Acked-by: Stephen Smalley
Acked-by: Tetsuo Handa
Signed-off-by: James Morris -
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.hSigned-off-by: Casey Schaufler
Acked-by: John Johansen
Acked-by: Kees Cook
Acked-by: Paul Moore
Acked-by: Stephen Smalley
Acked-by: Tetsuo Handa
Signed-off-by: James Morris
24 Mar, 2015
1 commit
-
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
22 Jan, 2015
1 commit
-
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:
[] (dump_backtrace+0x0/0x158) from [] (show_stack+0x20/0x24)
r7:c4634010 r6:d3b23f50 r5:c4635600 r4:d1002140
[] (show_stack+0x0/0x24) from [] (dump_stack+0x20/0x28)
[] (dump_stack+0x0/0x28) from [] (print_trailer+0x124/0x144)
[] (print_trailer+0x0/0x144) from [] (object_err+0x3c/0x44)
r7:c4635600 r6:d1002140 r5:d3b23f50 r4:c4635600
[] (object_err+0x0/0x44) from [] (kasan_report_error+0x2b8/0x538)
r6:d1002140 r5:d3b23f50 r4:c6429cf8 r3:c09e1aa7
[] (kasan_report_error+0x0/0x538) from [] (__asan_load4+0xd4/0xf8)
[] (__asan_load4+0x0/0xf8) from [] (smack_task_to_inode+0x50/0x70)
r5:c4635600 r4:ca9da000
[] (smack_task_to_inode+0x0/0x70) from [] (security_task_to_inode+0x3c/0x44)
r5:cca25e80 r4:c0ba9780
[] (security_task_to_inode+0x0/0x44) from [] (pid_revalidate+0x124/0x178)
r6:00000000 r5:cca25e80 r4:cbabe3c0 r3:00008124
[] (pid_revalidate+0x0/0x178) from [] (lookup_fast+0x35c/0x43y4)
r9:c6429efc r8:00000101 r7:c079d940 r6:c6429e90 r5:c6429ed8 r4:c83c4148
[] (lookup_fast+0x0/0x434) from [] (do_last.isra.24+0x1c0/0x1108)
[] (do_last.isra.24+0x0/0x1108) from [] (path_openat.isra.25+0xf4/0x648)
[] (path_openat.isra.25+0x0/0x648) from [] (do_filp_open+0x3c/0x88)
[] (do_filp_open+0x0/0x88) from [] (do_sys_open+0xf0/0x198)
r7:00000001 r6:c0ea2180 r5:0000000b r4:00000000
[] (do_sys_open+0x0/0x198) from [] (SyS_open+0x30/0x34)
[] (SyS_open+0x0/0x34) from [] (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
Cc:
21 Jan, 2015
1 commit
-
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 KrypaSigned-off-by: Casey Schaufler
30 Aug, 2014
1 commit
-
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
Conflicts:
security/smack/smack_access.c
security/smack/smack_lsm.c
29 Aug, 2014
1 commit
-
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 wbAccesses 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
12 Apr, 2014
3 commits
-
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
-
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
Signed-off-by: Rafal Krypa -
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
Signed-off-by: Rafal Krypa
24 Dec, 2013
1 commit
-
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
19 Oct, 2013
1 commit
-
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
02 Aug, 2013
2 commits
-
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
-
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.627Surprisingly, 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
29 May, 2013
3 commits
-
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
-
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
-
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
20 Mar, 2013
1 commit
-
SMACK_MAGIC moved to a proper place for easy user space access
(i.e. libsmack).Signed-off-by: Jarkko Sakkinen
14 Jul, 2012
2 commits
-
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
-
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
22 May, 2012
1 commit
-
Per pull request, for 3.5.
15 May, 2012
2 commits
-
V4 updated to current linux-security#next
Targeted for git://gitorious.org/smack-next/kernel.gitModern 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 likesoftwarehouse-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
-
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
10 Apr, 2012
1 commit
-
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
04 Apr, 2012
2 commits
-
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
Signed-off-by: Linus Torvalds -
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
Signed-off-by: Linus Torvalds
21 Oct, 2011
1 commit
-
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
Signed-off-by: Casey Schaufler
13 Oct, 2011
2 commits
-
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
-
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
26 Apr, 2011
2 commits
-
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
Acked-by: Casey Schaufler -
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
Acked-by: Casey Schaufler
10 Feb, 2011
1 commit
-
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
Signed-off-by: Casey Schaufler
18 Jan, 2011
1 commit
-
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