Memory leak in smack_cred_prepare()function.
smack_cred_prepare() hook returns error if there is error in allocating
memory in smk_copy_rules() or smk_copy_relabel() function.
If smack_cred_prepare() function returns error then the calling
function should call smack_cred_free() function for cleanup.
In smack_cred_free() function first credential is  extracted and
then all rules are deleted. In smack_cred_prepare() function security
field is assigned in the end when all function return success. But this
function may return before and memory will not be freed.
Signed-off-by: NHimanshu Shukla <himanshu.sh@samsung.com>
Acked-by: NCasey Schaufler <casey@schaufler-ca.com>

Smack prohibits processes from using the star ("*") and web ("@") labels.
Checks have been added in other functions. In smack_setprocattr()
hook, only check for web ("@") label has been added and restricted
from applying web ("@") label.
Check for star ("*") label should also be added in smack_setprocattr()
hook. Return error should be "-EINVAL" not "-EPERM" as permission
is there for setting label but not the label value as star ("*") or
web ("@").
Signed-off-by: NHimanshu Shukla <himanshu.sh@samsung.com>
Acked-by: NCasey Schaufler <casey@schaufler-ca.com>

In smack_set_mnt_opts()first the SMACK mount options are being
parsed and later it is being checked whether the user calling
mount has CAP_MAC_ADMIN capability.
This sequence of operationis will allow unauthorized user to add
SMACK labels in label list and may cause denial of security attack
by adding many labels by allocating kernel memory by unauthorized user.
Superblock smack flag is also being set as initialized though function
may return with EPERM error.
First check the capability of calling user then set the SMACK attributes
and smk_flags.
Signed-off-by: NHimanshu Shukla <himanshu.sh@samsung.com>
Acked-by: NCasey Schaufler <casey@schaufler-ca.com>

Assign smack_known_web label for kernel thread's socket

Creating struct sock by sk_alloc function in various kernel subsystems
like bluetooth doesn't call smack_socket_post_create(). In such case,
received sock label is the floor('_') label and makes access deny.
Signed-off-by: Njooseong lee <jooseong.lee@samsung.com>
Acked-by: NCasey Schaufler <casey@schaufler-ca.com>

Right now, various places in the kernel check for the existence of
getxattr, setxattr, and removexattr inode operations and directly call
those operations.  Switch to helper functions and test for the IOP_XATTR
flag instead.
Signed-off-by: NAndreas Gruenbacher <agruenba@redhat.com>
Acked-by: NJames Morris <james.l.morris@oracle.com>
Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>

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: NCasey Schaufler <casey@schaufler-ca.com>

This makes it possible to route the error to the appropriate
labelling engine.  CALIPSO is far less verbose than CIPSO
when encountering a bogus packet, so there is no need for a
CALIPSO error handler.
Signed-off-by: NHuw Davies <huw@codeweavers.com>
Signed-off-by: NPaul Moore <paul@paul-moore.com>

The SMACK64, SMACK64EXEC, and SMACK64MMAP labels are all handled
differently in untrusted mounts. This is confusing and
potentically problematic. Change this to handle them all the same
way that SMACK64 is currently handled; that is, read the label
from disk and check it at use time. For SMACK64 and SMACK64MMAP
access is denied if the label does not match smk_root. To be
consistent with suid, a SMACK64EXEC label which does not match
smk_root will still allow execution of the file but will not run
with the label supplied in the xattr.
Signed-off-by: NSeth Forshee <seth.forshee@canonical.com>
Acked-by: NCasey Schaufler <casey@schaufler-ca.com>
Signed-off-by: NEric W. Biederman <ebiederm@xmission.com>

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: NSeth Forshee <seth.forshee@canonical.com>
Acked-by: NCasey Schaufler <casey@schaufler-ca.com>
Signed-off-by: NEric W. Biederman <ebiederm@xmission.com>

Kill with signal number 0 is commonly used for checking PID existence.
Smack treated such cases like any other kills, although no signal is
actually delivered when sig == 0.

Checking permissions when sig == 0 didn't prevent an unprivileged caller
from learning whether PID exists or not. When it existed, kernel returned
EPERM, when it didn't - ESRCH. The only effect of policy check in such
case is noise in audit logs.

This change lets Smack silently ignore kill() invocations with sig == 0.
Signed-off-by: NRafal Krypa <r.krypa@samsung.com>
Acked-by: NCasey Schaufler <casey@schaufler-ca.com>

smack ->d_instantiate() uses ->setxattr(), so to be able to call it before
we'd hashed the new dentry and attached it to inode, we need ->setxattr()
instances getting the inode as an explicit argument rather than obtaining
it from dentry.

Similar change for ->getxattr() had been done in commit ce23e640.  Unlike
->getxattr() (which is used by both selinux and smack instances of
->d_instantiate()) ->setxattr() is used only by smack one and unfortunately
it got missed back then.
Reported-by: NSeung-Woo Kim <sw0312.kim@samsung.com>
Tested-by: NCasey Schaufler <casey@schaufler-ca.com>
Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>

Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>

... and neither can ever be NULL
Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>

Before this commit, removing the access property of
a file, aka, the extended attribute security.SMACK64
was not effictive until the cache had been cleaned.

This patch fixes that problem.
Signed-off-by: NJosé Bollo <jobol@nonadev.net>
Acked-by: NCasey Schaufler <casey@schaufler-ca.com>

Prior to the 4.2 kernel there no no harm in providing
a security module hook that does nothing, as the default
hook would get called if the module did not supply one.
With the list based infrastructure an empty hook adds
overhead. This patch removes the three Smack hooks that
don't actually do anything.
Signed-off-by: NCasey Schaufler <casey@schaufler-ca.com>

It looks like smack and yama weren't aware that the ptrace mode
can have flags ORed into it - PTRACE_MODE_NOAUDIT until now, but
only for /proc/$pid/stat, and with the PTRACE_MODE_*CREDS patch,
all modes have flags ORed into them.
Signed-off-by: NJann Horn <jann@thejh.net>
Acked-by: NKees Cook <keescook@chromium.org>
Acked-by: NCasey Schaufler <casey@schaufler-ca.com>
Cc: Oleg Nesterov <oleg@redhat.com>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: James Morris <james.l.morris@oracle.com>
Cc: "Serge E. Hallyn" <serge.hallyn@ubuntu.com>
Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Cc: Andy Lutomirski <luto@kernel.org>
Cc: Al Viro <viro@zeniv.linux.org.uk>
Cc: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: Willy Tarreau <w@1wt.eu>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Make the inode argument of the inode_getsecid hook non-const so that we
can use it to revalidate invalid security labels.
Signed-off-by: NAndreas Gruenbacher <agruenba@redhat.com>
Acked-by: NStephen Smalley <sds@tycho.nsa.gov>
Signed-off-by: NPaul Moore <pmoore@redhat.com>

Make the inode argument of the inode_getsecurity hook non-const so that
we can use it to revalidate invalid security labels.
Signed-off-by: NAndreas Gruenbacher <agruenba@redhat.com>
Acked-by: NStephen Smalley <sds@tycho.nsa.gov>
Signed-off-by: NPaul Moore <pmoore@redhat.com>

Smack security handler for sendmsg() syscall
is vulnerable to type confusion issue what
can allow to privilege escalation into root
or cause denial of service.

A malicious attacker can create socket of one
type for example AF_UNIX and pass is into
sendmsg() function ensuring that this is
AF_INET socket.

Remedy
Do not trust user supplied data.
Proposed fix below.
Signed-off-by: NRoman Kubiak <r.kubiak@samsung.com>
Signed-off-by: NMateusz Fruba <m.fruba@samsung.com>
Acked-by: NCasey Schaufler <casey@schaufler-ca.com>

Add a nfs_listxattr operation.  Move the call to security_inode_listsecurity
from list operation of the "security.*" xattr handler to nfs_listxattr.
Signed-off-by: NAndreas Gruenbacher <agruenba@redhat.com>
Cc: Trond Myklebust <trond.myklebust@primarydata.com>
Cc: Anna Schumaker <anna.schumaker@netapp.com>
Cc: linux-nfs@vger.kernel.org
Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>

The existing file receive hook checks for access on
the file inode even for UDS. This is not right, as
the inode is not used by Smack to make access checks
for sockets. This change checks for an appropriate
access relationship between the receiving (current)
process and the socket. If the process can't write
to the socket's send label or the socket's receive
label can't write to the process fail.

This will allow the legitimate cases, where the
socket sender and socket receiver can freely communicate.
Only strangly set socket labels should cause a problem.
Signed-off-by: NCasey Schaufler <casey@schaufler-ca.com>

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: NZbigniew Jasinski <z.jasinski@samsung.com>
Signed-off-by: NRafal Krypa <r.krypa@samsung.com>
Acked-by: NCasey Schaufler <casey@schaufler-ca.com>

This fix writes the task label when
smack_d_instantiate is called, before the
label of the superblock was written on the
pipe's inode.
Signed-off-by: NRoman Kubiak <r.kubiak@samsung.com>
Acked-by: NCasey Schaufler <casey@schaufler-ca.com>

This change has two goals:
 - delay the setting of 'smack_enabled' until
   it will be really effective
 - ensure that smackfs is valid only if 'smack_enabled'
   is set (it is already the case in smack_netfilter.c)
Signed-off-by: NJosé Bollo <jose.bollo@iot.bzh>
Acked-by: NCasey Schaufler <casey@schaufler-ca.com>

Fixes the following sparse warning:

 security/smack/smack_lsm.c:55:1: warning: symbol 'smk_ipv6_port_list'
 was not declared. Should it be static?
Signed-off-by: NGeliang Tang <geliangtang@163.com>
Acked-by: NCasey Schaufler <casey@schaufler-ca.com>

The changes for mounting binary filesystems was allied
improperly, with the list of tokens being in an ifdef that
it shouldn't have been. Fix that, and a couple style issues
that were bothering me.
Reported-by: NJim Davis <jim.epost@gmail.com>
Signed-off-by: NCasey Schaufler <casey@schaufler-ca.com>

The kbuild test robot reported a couple of these,
and the third showed up by inspection. Making the
symbols static is proper.
Reported-by: NFengguang Wu <fengguang.wu@intel.com>
Signed-off-by: NCasey Schaufler <casey@schaufler-ca.com>

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: NCasey Schaufler <casey@schaufler-ca.com>

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: NVivek Trivedi <t.vivek@samsung.com>
Signed-off-by: NAmit Sahrawat <a.sahrawat@samsung.com>
Acked-by: NCasey Schaufler <casey@schaufler-ca.com>

This patch makes the following functions to use ERR_PTR() and related
macros to pass the appropriate error code through returned pointers:

smk_parse_smack()
smk_import_entry()
smk_fetch()

It also makes all the other functions that use them to handle the
error cases properly. This ways correct error codes from places
where they happened can be propagated to the user space if necessary.

Doing this it fixes a bug in onlycap and unconfined files
handling. Previously their content was cleared on any error from
smk_import_entry/smk_parse_smack, be it EINVAL (as originally intended)
or ENOMEM. Right now it only reacts on EINVAL passing other codes
properly to userspace.

Comments have been updated accordingly.
Signed-off-by: NLukasz Pawelczyk <l.pawelczyk@samsung.com>

The dmabuf fd can be shared between processes via unix domain
socket. The file of dmabuf fd is came from anon_inode. The inode
has no set and get xattr operations, so it can not be shared
between processes with smack. This patch fixes just to ignore
private inode including anon_inode for smack_file_receive.
Signed-off-by: NSeung-Woo Kim <sw0312.kim@samsung.com>

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: NCasey Schaufler <casey@schaufler-ca.com>
Acked-by: NJohn Johansen <john.johansen@canonical.com>
Acked-by: NKees Cook <keescook@chromium.org>
Acked-by: NPaul Moore <paul@paul-moore.com>
Acked-by: NStephen Smalley <sds@tycho.nsa.gov>
Acked-by: NTetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Signed-off-by: NJames Morris <james.l.morris@oracle.com>

Add a list header for each security hook. They aren't used until
later in the patch series. They are grouped together in a structure
so that there doesn't need to be an external address for each.

Macro-ize the initialization of the security_operations
for each security module in anticipation of changing out
the security_operations structure.
Signed-off-by: NCasey Schaufler <casey@schaufler-ca.com>
Acked-by: NJohn Johansen <john.johansen@canonical.com>
Acked-by: NKees Cook <keescook@chromium.org>
Acked-by: NPaul Moore <paul@paul-moore.com>
Acked-by: NStephen Smalley <sds@tycho.nsa.gov>
Acked-by: NTetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Signed-off-by: NJames Morris <james.l.morris@oracle.com>

most of the ->d_inode uses there refer to the same inode IO would
go to, i.e. d_backing_inode()
Signed-off-by: NDavid Howells <dhowells@redhat.com>
Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>

Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>

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: NCasey Schaufler <casey@schaufler-ca.com>

With this commit, the LSM Smack implements the LSM
side part of the system call keyctl with the action
code KEYCTL_GET_SECURITY.

It is now possible to get the context of, for example,
the user session key using the command "keyctl security @s".

The original patch has been modified for merge.
Signed-off-by: NJosé Bollo <jose.bollo@open.eurogiciel.org>
Signed-off-by: NCasey Schaufler <casey@schaufler-ca.com>

This change fixes the bug associated with sockets owned by kernel threads. These
sockets, created usually by network devices' drivers tasks, received smk_in
label from the task that created them - the "floor" label in the most cases. The
result was that they were not able to receive data packets because of missing
smack rules. The main reason of the access deny is that the socket smk_in label
is placed as the object during smk check, kernel thread's capabilities are
omitted.
Signed-off-by: NMarcin Lis <m.lis@samsung.com>

Use d_is_positive() rather than testing dentry->d_inode in Smack to get rid of
direct references to d_inode outside of the VFS.
Signed-off-by: NDavid Howells <dhowells@redhat.com>
Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>

If the secmark is available us it on connection as
well as packet delivery.
Signed-off-by: NCasey Schaufler <casey@schaufler-ca.com>