net: wireless: Increase scan entry expiration to fit new scan time

Change-Id: I0e23ce45d78d7c17633670973f49943a5ed6032d
Signed-off-by: Dmitry Shmidt <dimitrysh@google.com>
Signed-off-by: Dan Trifan <jimsth@gmail.com>
->permission() sanitizing: don't pass flags to ->inode_permission()

pass that via mask instead.

Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Dan Trifan <jimsth@gmail.com>
selinux: don't transliterate MAY_NOT_BLOCK to IPERM_FLAG_RCU

Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Dan Trifan <jimsth@gmail.com>
security: optimize avc_audit() common path

avc_audit() did a lot of jumping around and had a big stack frame, all
for the uncommon case.

Split up the uncommon case (which we really can't make go fast anyway)
into its own slow function, and mark the conditional branches
appropriately for the common likely case.

This causes avc_audit() to no longer show up as one of the hottest
functions on the branch profiles (the new "perf -b" thing), and makes
the cycle profiles look really nice and dense too.

The whole audit path is still annoyingly very much one of the biggest
costs of name lookup, so these things are worth optimizing for.  I wish
we could just tell people to turn it off, but realistically we do need
it: we just need to make sure that the overhead of the necessary evil is
as low as possible.

Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Dan Trifan <jimsth@gmail.com>
selinux: don't inline slow-path code into avc_has_perm_noaudit()

The selinux AVC paths remain some of the hottest (and deepest) codepaths
at filename lookup time, and we make it worse by having the slow path
cases take up I$ and stack space even when they don't trigger.  Gcc
tends to always want to inline functions that are just called once -
never mind that this might make for slower and worse code in the caller.

So this tries to improve on it a bit by making the slow-path cases
explicitly separate functions that are marked noinline, causing gcc to
at least no longer allocate stack space for them unless they are
actually called.  It also seems to help register allocation a tiny bit,
since gcc now doesn't take the slow case code into account.

Uninlining the slow path may also allow us to inline the remaining hot
path into the one caller that actually matters: avc_has_perm_flags().
I'll have to look at that separately, but both avc_audit() and
avc_has_perm_noaudit() are now small and lean enough that inlining them
may make sense.

Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Dan Trifan <jimsth@gmail.com>
selinux: inline avc_audit() and avc_has_perm_noaudit() into caller

Now that all the slow-path code is gone from these functions, we can
inline them into the main caller - avc_has_perm_flags().

Now the compiler can see that 'avc' is allocated on the stack for this
case, which helps register pressure a bit.  It also actually shrinks the
total stack frame, because the stack frame that avc_has_perm_flags()
always needed (for that 'avc' allocation) is now sufficient for the
inlined functions too.

Inlining isn't bad - but mindless inlining of cold code (see the
previous commit) is.

Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Dan Trifan <jimsth@gmail.com>
apparmor: sparse fix: rename shadowed variables in policy_unpack.c

Fix the following warnings:

security/apparmor/policy_unpack.c:384:35: warning: symbol 'size' shadows an earlier one
security/apparmor/policy_unpack.c:370:24: originally declared here
security/apparmor/policy_unpack.c:443:29: warning: symbol 'tmp' shadows an earlier one
security/apparmor/policy_unpack.c:434:21: originally declared here

Signed-off-by: James Morris <jmorris@namei.org>
Acked-by: John Johansen <john.johansen@canonical.com>
Signed-off-by: Dan Trifan <jimsth@gmail.com>
AppArmor: Add mising end of structure test to caps unpacking

The unpacking of struct capsx is missing a check for the end of the
caps structure.  This can lead to unpack failures depending on what else
is packed into the policy file being unpacked.

Signed-off-by: John Johansen <john.johansen@canonical.com>
Acked-by: Kees Cook <kees@ubuntu.com>
Signed-off-by: Dan Trifan <jimsth@gmail.com>
AppArmor: Fix oops in policy unpack auditing

Post unpacking of policy a verification pass is made on x transition
indexes.  When this fails a call to audit_iface is made resulting in an
oops, because audit_iface is expecting a valid buffer position but
since the failure comes from post unpack verification there is none.

Make the position argument optional so that audit_iface can be called
from post unpack verification.

Signed-off-by: John Johansen <john.johansen@canonical.com>
Signed-off-by: Dan Trifan <jimsth@gmail.com>
AppArmor: Add ability to load extended policy

Add the base support for the new policy extensions. This does not bring
any additional functionality, or change current semantics.

Signed-off-by: John Johansen <john.johansen@canonical.com>
Acked-by: Kees Cook <kees@ubuntu.com>
Signed-off-by: Dan Trifan <jimsth@gmail.com>
capabilities: remove the task from capable LSM hook entirely

The capabilities framework is based around credentials, not necessarily the
current task.  Yet we still passed the current task down into LSMs from the
security_capable() LSM hook as if it was a meaningful portion of the security
decision.  This patch removes the 'generic' passing of current and instead
forces individual LSMs to use current explicitly if they think it is
appropriate.  In our case those LSMs are SELinux and AppArmor.

I believe the AppArmor use of current is incorrect, but that is wholely
unrelated to this patch.  This patch does not change what AppArmor does, it
just makes it clear in the AppArmor code that it is doing it.

The SELinux code still uses current in it's audit message, which may also be
wrong and needs further investigation.  Again this is NOT a change, it may
have always been wrong, this patch just makes it clear what is happening.

Signed-off-by: Eric Paris <eparis@redhat.com>
Signed-off-by: Dan Trifan <jimsth@gmail.com>
capabilities: reverse arguments to security_capable

security_capable takes ns, cred, cap.  But the LSM capable() hook takes
cred, ns, cap.  The capability helper functions also take cred, ns, cap.
Rather than flip argument order just to flip it back, leave them alone.
Heck, this should be a little faster since argument will be in the right
place!

Signed-off-by: Eric Paris <eparis@redhat.com>
Signed-off-by: Dan Trifan <jimsth@gmail.com>
capabilities: introduce security_capable_noaudit

Exactly like security_capable except don't audit any denials.  This is for
places where the kernel may make decisions about what to do if a task has a
given capability, but which failing that capability is not a sign of a
security policy violation.  An example is checking if a task has
CAP_SYS_ADMIN to lower it's likelyhood of being killed by the oom killer.
This check is not a security violation if it is denied.

Signed-off-by: Eric Paris <eparis@redhat.com>
Acked-by: Serge E. Hallyn <serge.hallyn@canonical.com>
Signed-off-by: Dan Trifan <jimsth@gmail.com>
capabilities: remove all _real_ interfaces

The name security_real_capable and security_real_capable_noaudit just don't
make much sense to me.  Convert them to use security_capable and
security_capable_noaudit.

Signed-off-by: Eric Paris <eparis@redhat.com>
Acked-by: Serge E. Hallyn <serge.hallyn@canonical.com>
Signed-off-by: Dan Trifan <jimsth@gmail.com>
capabilities: call has_ns_capability from has_capability

Declare the more specific has_ns_capability first in the code and then call it
from has_capability.  The declaration reversal isn't stricty necessary since
they are both declared in header files, but it just makes sense to put more
specific functions first in the code.

Signed-off-by: Eric Paris <eparis@redhat.com>
Acked-by: Serge E. Hallyn <serge.hallyn@canonical.com>
Signed-off-by: Dan Trifan <jimsth@gmail.com>
capabilites: introduce new has_ns_capabilities_noaudit

For consistency in interfaces, introduce a new interface called
has_ns_capabilities_noaudit.  It checks if the given task has the given
capability in the given namespace.  Use this new function by
has_capabilities_noaudit.

Signed-off-by: Eric Paris <eparis@redhat.com>
Acked-by: Serge E. Hallyn <serge.hallyn@canonical.com>
Signed-off-by: Dan Trifan <jimsth@gmail.com>
capabilities: style only - move capable below ns_capable

Although the current code is fine for consistency this moves the capable
code below the function it calls in the c file.  It doesn't actually change
code.

Signed-off-by: Eric Paris <eparis@redhat.com>
Acked-by: Serge E. Hallyn <serge.hallyn@canonical.com>
Signed-off-by: Dan Trifan <jimsth@gmail.com>
capabitlies: ns_capable can use the cap helpers rather than lsm call

Just to reduce the number of places to change if we every change the LSM
hook, use the capability helpers internally when possible.

Signed-off-by: Eric Paris <eparis@redhat.com>
Acked-by: Serge E. Hallyn <serge.hallyn@canonical.com>
Signed-off-by: Dan Trifan <jimsth@gmail.com>
capabilities: remove task_ns_* functions

task_ in the front of a function, in the security subsystem anyway, means
to me at least, that we are operating with that task as the subject of the
security decision.  In this case what it means is that we are using current as
the subject but we use the task to get the right namespace.  Who in the world
would ever realize that's what task_ns_capability means just by the name?  This
patch eliminates the task_ns functions entirely and uses the has_ns_capability
function instead.  This means we explicitly open code the ns in question in
the caller.  I think it makes the caller a LOT more clear what is going on.

Signed-off-by: Eric Paris <eparis@redhat.com>
Acked-by: Serge E. Hallyn <serge.hallyn@canonical.com>
Signed-off-by: Dan Trifan <jimsth@gmail.com>
ptrace: do not audit capability check when outputing /proc/pid/stat

Reading /proc/pid/stat of another process checks if one has ptrace permissions
on that process.  If one does have permissions it outputs some data about the
process which might have security and attack implications.  If the current
task does not have ptrace permissions the read still works, but those fields
are filled with inocuous (0) values.  Since this check and a subsequent denial
is not a violation of the security policy we should not audit such denials.

This can be quite useful to removing ptrace broadly across a system without
flooding the logs when ps is run or something which harmlessly walks proc.

Signed-off-by: Eric Paris <eparis@redhat.com>
Acked-by: Serge E. Hallyn <serge.hallyn@canonical.com>
Signed-off-by: Dan Trifan <jimsth@gmail.com>