Instead of a hashtab entry counter function only useful for range
transition rules make a function generic for any hashtable to use.
Signed-off-by: NEric Paris <eparis@redhat.com>
Reviewed-by: NJames Morris <jmorris@namei.org>

We have custom debug functions like rangetr_hash_eval and symtab_hash_eval
which do the same thing.  Just create a generic function that takes the name
of the hash table as an argument instead of having custom functions.
Signed-off-by: NEric Paris <eparis@redhat.com>
Reviewed-by: NJames Morris <jmorris@namei.org>

Right now we walk to filename trans rule list for every inode that is
created.  First passes at policy using this facility creates around 5000
filename trans rules.  Running a list of 5000 entries every time is a bad
idea.  This patch adds a new ebitmap to policy which has a bit set for each
ttype that has at least 1 filename trans rule.  Thus when an inode is
created we can quickly determine if any rules exist for this parent
directory type and can skip the list if we know there is definitely no
relevant entry.
Signed-off-by: NEric Paris <eparis@redhat.com>
Reviewed-by: NJames Morris <jmorris@namei.org>

filename_compute_type() takes as arguments the numeric value of the type of
the subject and target.  It does not take a context.  Thus the names are
misleading.  Fix the argument names.
Signed-off-by: NEric Paris <eparis@redhat.com>
Reviewed-by: NJames Morris <jmorris@namei.org>

filename_compute_type used to take a qstr, but it now takes just a name.
Fix the comments to indicate it is an objname, not a qstr.
Signed-off-by: NEric Paris <eparis@redhat.com>

smack_file_lock has a struct path, so use that instead of only the
dentry.
Signed-off-by: NEric Paris <eparis@redhat.com>
Acked-by: NCasey Schaufler <casey@schaufler-ca.com>

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: NEric Paris <eparis@redhat.com>
Acked-by: NCasey Schaufler <casey@schaufler-ca.com>

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: NEric Paris <eparis@redhat.com>
Acked-by: NCasey Schaufler <casey@schaufler-ca.com>

Now that the security modules can decide whether they support the
dcache RCU walk or not it's possible to make selinux a bit more
RCU friendly.  The SELinux AVC and security server access decision
code is RCU safe.  A specific piece of the LSM audit code may not
be RCU safe.

This patch makes the VFS RCU walk retry if it would hit the non RCU
safe chunk of code.  It will normally just work under RCU.  This is
done simply by passing the VFS RCU state as a flag down into the
avc_audit() code and returning ECHILD there if it would have an issue.
Based-on-patch-by: NAndi Kleen <ak@linux.intel.com>
Signed-off-by: NEric Paris <eparis@redhat.com>

Right now all RCU walks fall back to reference walk when CONFIG_SECURITY
is enabled, even though just the standard capability module is active.
This is because security_inode_exec_permission unconditionally fails
RCU walks.

Move this decision to the low level security module. This requires
passing the RCU flags down the security hook. This way at least
the capability module and a few easy cases in selinux/smack work
with RCU walks with CONFIG_SECURITY=y
Signed-off-by: NAndi Kleen <ak@linux.intel.com>
Signed-off-by: NEric Paris <eparis@redhat.com>

The len should be an size_t but is a ssize_t.  Easy enough fix to silence
build warnings.  We have no need for signed-ness.
Signed-off-by: NEric Paris <eparis@redhat.com>
Reviewed-by: NJames Morris <jmorris@namei.org>

If one builds a kernel without CONFIG_BUG there are a number of 'may be
used uninitialized' warnings.  Silence these by returning after the BUG().
Signed-off-by: NEric Paris <eparis@redhat.com>
Reviewed-by: NJames Morris <jmorris@namei.org>

The filename_trans rule processing has some printk(KERN_ERR ) messages
which were intended as debug aids in creating the code but weren't removed
before it was submitted.  Remove them.
Signed-off-by: NEric Paris <eparis@redhat.com>

Initialize policydb.process_class once all symtabs read from policy image,
so that it could be used to setup the role_trans.tclass field when a lower
version policy.X is loaded.
Signed-off-by: NHarry Ciao <qingtao.cao@windriver.com>
Signed-off-by: NEric Paris <eparis@redhat.com>

Commit 6f5317e7 introduced a bug in the
handling of userspace object classes that is causing breakage for Xorg
when XSELinux is enabled.  Fix the bug by changing map_class() to return
SECCLASS_NULL when the class cannot be mapped to a kernel object class.
Reported-by: N"Justin P. Mattock" <justinmattock@gmail.com>
Signed-off-by: NStephen Smalley <sds@tycho.nsa.gov>
Signed-off-by: NJames Morris <jmorris@namei.org>

The attached patch allows /selinux/create takes optional 4th argument
to support TYPE_TRANSITION with name extension for userspace object
managers.
If 4th argument is not supplied, it shall perform as existing kernel.
In fact, the regression test of SE-PostgreSQL works well on the patched
kernel.

Thanks,
Signed-off-by: NKaiGai Kohei <kohei.kaigai@eu.nec.com>
[manually verify fuzz was not an issue, and it wasn't: eparis]
Signed-off-by: NEric Paris <eparis@redhat.com>

If kernel policy version is >= 26, then write the class field of the
role_trans structure into the binary reprensentation.
Signed-off-by: NHarry Ciao <qingtao.cao@windriver.com>
Acked-by: NStephen Smalley <sds@tycho.nsa.gov>
Signed-off-by: NEric Paris <eparis@redhat.com>

Apply role_transition rules for all kinds of classes.
Signed-off-by: NHarry Ciao <qingtao.cao@windriver.com>
Acked-by: NStephen Smalley <sds@tycho.nsa.gov>
Signed-off-by: NEric Paris <eparis@redhat.com>

If kernel policy version is >= 26, then the binary representation of
the role_trans structure supports specifying the class for the current
subject or the newly created object.

If kernel policy version is < 26, then the class field would be default
to the process class.
Signed-off-by: NHarry Ciao <qingtao.cao@windriver.com>
Acked-by: NStephen Smalley <sds@tycho.nsa.gov>
Signed-off-by: NEric Paris <eparis@redhat.com>

Add a keyctl op (KEYCTL_INSTANTIATE_IOV) that is like KEYCTL_INSTANTIATE, but
takes an iovec array and concatenates the data in-kernel into one buffer.
Since the KEYCTL_INSTANTIATE copies the data anyway, this isn't too much of a
problem.
Signed-off-by: NDavid Howells <dhowells@redhat.com>
Signed-off-by: NJames Morris <jmorris@namei.org>

Add a new keyctl op to reject a key with a specified error code.  This works
much the same as negating a key, and so keyctl_negate_key() is made a special
case of keyctl_reject_key().  The difference is that keyctl_negate_key()
selects ENOKEY as the error to be reported.

Typically the key would be rejected with EKEYEXPIRED, EKEYREVOKED or
EKEYREJECTED, but this is not mandatory.
Signed-off-by: NDavid Howells <dhowells@redhat.com>
Signed-off-by: NJames Morris <jmorris@namei.org>

Add a key type operation to permit the key type to vet the description of a new
key that key_alloc() is about to allocate.  The operation may reject the
description if it wishes with an error of its choosing.  If it does this, the
key will not be allocated.
Signed-off-by: NDavid Howells <dhowells@redhat.com>
Reviewed-by: NMimi Zohar <zohar@us.ibm.com>
Signed-off-by: NJames Morris <jmorris@namei.org>

Add an RCU payload dereference macro as this seems to be a common piece of code
amongst key types that use RCU referenced payloads.
Signed-off-by: NDavid Howells <dhowells@redhat.com>
Signed-off-by: NMimi Zohar <zohar@us.ibm.com>
Signed-off-by: NJames Morris <jmorris@namei.org>

For SELinux we do not allow security information to change during a remount
operation.  Thus this hook simply strips the security module options from
the data and verifies that those are the same options as exist on the
current superblock.
Signed-off-by: NEric Paris <eparis@redhat.com>
Reviewed-by: NJames Morris <jmorris@namei.org>

The VFS mount code passes the mount options to the LSM.  The LSM will remove
options it understands from the data and the VFS will then pass the remaining
options onto the underlying filesystem.  This is how options like the
SELinux context= work.  The problem comes in that -o remount never calls
into LSM code.  So if you include an LSM specific option it will get passed
to the filesystem and will cause the remount to fail.  An example of where
this is a problem is the 'seclabel' option.  The SELinux LSM hook will
print this word in /proc/mounts if the filesystem is being labeled using
xattrs.  If you pass this word on mount it will be silently stripped and
ignored.  But if you pass this word on remount the LSM never gets called
and it will be passed to the FS.  The FS doesn't know what seclabel means
and thus should fail the mount.  For example an ext3 fs mounted over loop

# mount -o loop /tmp/fs /mnt/tmp
# cat /proc/mounts | grep /mnt/tmp
/dev/loop0 /mnt/tmp ext3 rw,seclabel,relatime,errors=continue,barrier=0,data=ordered 0 0
# mount -o remount /mnt/tmp
mount: /mnt/tmp not mounted already, or bad option
# dmesg
EXT3-fs (loop0): error: unrecognized mount option "seclabel" or missing value

This patch passes the remount mount options to an new LSM hook.
Signed-off-by: NEric Paris <eparis@redhat.com>
Reviewed-by: NJames Morris <jmorris@namei.org>

The security context for the newly created socket shares the same
user, role and MLS attribute as its creator but may have a different
type, which could be specified by a type_transition rule in the relevant
policy package.
Signed-off-by: NHarry Ciao <qingtao.cao@windriver.com>
[fix call to security_transition_sid to include qstr, Eric Paris]
Signed-off-by: NEric Paris <eparis@redhat.com>
Acked-by: NStephen Smalley <sds@tycho.nsa.gov>

The socket SID would be computed on creation and no longer inherit
its creator's SID by default. Socket may have a different type but
needs to retain the creator's role and MLS attribute in order not
to break labeled networking and network access control.

The kernel value for a class would be used to determine if the class
if one of socket classes. If security_compute_sid is called from
userspace the policy value for a class would be mapped to the relevant
kernel value first.
Signed-off-by: NHarry Ciao <qingtao.cao@windriver.com>
Signed-off-by: NEric Paris <eparis@redhat.com>
Acked-by: NStephen Smalley <sds@tycho.nsa.gov>

The security_is_socket_class() is auto-generated by genheaders based
on classmap.h to reduce maintenance effort when a new class is defined
in SELinux kernel. The name for any socket class should be suffixed by
"socket" and doesn't contain more than one substr of "socket".
Signed-off-by: NHarry Ciao <qingtao.cao@windriver.com>
Signed-off-by: NEric Paris <eparis@redhat.com>
Acked-by: NStephen Smalley <sds@tycho.nsa.gov>

In tomoyo_check_open_permission() since 2.6.36, TOMOYO was by error
recalculating already calculated pathname when checking allow_rewrite
permission. As a result, memory will leak whenever a file is opened for writing
without O_APPEND flag. Also, performance will degrade because TOMOYO is
calculating pathname regardless of profile configuration.
This patch fixes the leak and performance degrade.
Signed-off-by: NTetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Signed-off-by: NJames Morris <jmorris@namei.org>

This reverts commit 242631c4.

Conflicts:

	security/selinux/hooks.c

SELinux used to recognize certain individual ioctls and check
permissions based on the knowledge of the individual ioctl.  In commit
242631c4 the SELinux code stopped trying to understand
individual ioctls and to instead looked at the ioctl access bits to
determine in we should check read or write for that operation.  This
same suggestion was made to SMACK (and I believe copied into TOMOYO).
But this suggestion is total rubbish.  The ioctl access bits are
actually the access requirements for the structure being passed into the
ioctl, and are completely unrelated to the operation of the ioctl or the
object the ioctl is being performed upon.

Take FS_IOC_FIEMAP as an example.  FS_IOC_FIEMAP is defined as:

FS_IOC_FIEMAP _IOWR('f', 11, struct fiemap)

So it has access bits R and W.  What this really means is that the
kernel is going to both read and write to the struct fiemap.  It has
nothing at all to do with the operations that this ioctl might perform
on the file itself!
Signed-off-by: NEric Paris <eparis@redhat.com>
Acked-by: NStephen Smalley <sds@tycho.nsa.gov>

These permissions are not used and can be dropped in the kernel
definitions.
Suggested-by: NStephen Smalley <sds@tycho.nsa.gov>
Signed-off-by: NEric Paris <eparis@redhat.com>
Acked-by: NStephen Smalley <sds@tycho.nsa.gov>

The IPSKB_FORWARDED and IP6SKB_FORWARDED flags are used only in the
multicast forwarding case to indicate that a packet looped back after
forward. So these flags are not a good indicator for packet forwarding.
A better indicator is the incoming interface. If we have no socket context,
but an incoming interface and we see the packet in the ip postroute hook,
the packet is going to be forwarded.

With this patch we use the incoming interface as an indicator on packet
forwarding.
Signed-off-by: NSteffen Klassert <steffen.klassert@secunet.com>
Acked-by: NPaul Moore <paul.moore@hp.com>
Signed-off-by: NEric Paris <eparis@redhat.com>

selinux_sock_rcv_skb_compat and selinux_ip_postroute_compat are just
called if selinux_policycap_netpeer is not set. However in these
functions we check if selinux_policycap_netpeer is set. This leads
to some dead code and to the fact that selinux_xfrm_postroute_last
is never executed. This patch removes the dead code and the checks
for selinux_policycap_netpeer in the compatibility functions.
Signed-off-by: NSteffen Klassert <steffen.klassert@secunet.com>
Acked-by: NPaul Moore <paul.moore@hp.com>
Signed-off-by: NEric Paris <eparis@redhat.com>

selinux_xfrm_sec_ctx_alloc accidentally checks the xfrm domain of
interpretation against the selinux context algorithm. This patch
fixes this by checking ctx_alg against the selinux context algorithm.
Signed-off-by: NSteffen Klassert <steffen.klassert@secunet.com>
Acked-by: NPaul Moore <paul.moore@hp.com>
Signed-off-by: NEric Paris <eparis@redhat.com>

The original ima_must_measure() function based its results on cached
iint information, which required an iint be allocated for all files.
Currently, an iint is allocated only for files in policy.  As a result,
for those files in policy, ima_must_measure() is now called twice: once
to determine if the inode is in the measurement policy and, the second
time, to determine if it needs to be measured/re-measured.

The second call to ima_must_measure() unnecessarily checks to see if
the file is in policy. As we already know the file is in policy, this
patch removes the second unnecessary call to ima_must_measure(), removes
the vestige iint parameter, and just checks the iint directly to determine
if the inode has been measured or needs to be measured/re-measured.
Signed-off-by: NMimi Zohar <zohar@us.ibm.com>
Acked-by: NEric Paris <eparis@redhat.com>

Expand security_capable() to include cred, so that it can be usable in a
wider range of call sites.
Signed-off-by: NChris Wright <chrisw@sous-sol.org>
Acked-by: NSerge Hallyn <serge.hallyn@canonical.com>
Signed-off-by: NJames Morris <jmorris@namei.org>

Now that i_readcount is maintained by the VFS layer, remove the
imbalance checking in IMA. Cleans up the IMA code nicely.
Signed-off-by: NMimi Zohar <zohar@us.ibm.com>
Acked-by: NEric Paris <eparis@redhat.com>

ima_counts_get() updated the readcount and invalidated the PCR,
as necessary. Only update the i_readcount in the VFS layer.
Move the PCR invalidation checks to ima_file_check(), where it
belongs.

Maintaining the i_readcount in the VFS layer, will allow other
subsystems to use i_readcount.
Signed-off-by: NMimi Zohar <zohar@us.ibm.com>
Acked-by: NEric Paris <eparis@redhat.com>

Convert the inode's i_readcount from an unsigned int to atomic.
Signed-off-by: NMimi Zohar <zohar@us.ibm.com>
Acked-by: NEric Paris <eparis@redhat.com>

The mmap policy enforcement checks the access of the
SMACK64MMAP subject against the current subject incorrectly.
The check as written works correctly only if the access
rules involved have the same access. This is the common
case, so initial testing did not find a problem.
Signed-off-by: NCasey Schaufler <casey@schaufler-ca.com>