linux.git/security/apparmor, branch v4.9-rc2

fs: Replace CURRENT_TIME with current_time() for inode timestamps

2016-09-28T01:06:21+00:00

CURRENT_TIME macro is not appropriate for filesystems as it
doesn't use the right granularity for filesystem timestamps.
Use current_time() instead.

CURRENT_TIME is also not y2038 safe.

This is also in preparation for the patch that transitions
vfs timestamps to use 64 bit time and hence make them
y2038 safe. As part of the effort current_time() will be
extended to do range checks. Hence, it is necessary for all
file system timestamps to use current_time(). Also,
current_time() will be transitioned along with vfs to be
y2038 safe.

Note that whenever a single call to current_time() is used
to change timestamps in different inodes, it is because they
share the same time granularity.

Signed-off-by: Deepa Dinamani 
Reviewed-by: Arnd Bergmann 
Acked-by: Felipe Balbi 
Acked-by: Steven Whitehouse 
Acked-by: Ryusuke Konishi 
Acked-by: David Sterba 
Signed-off-by: Al Viro

apparmor: fix SECURITY_APPARMOR_HASH_DEFAULT parameter handling

2016-07-27T07:39:26+00:00

The newly added Kconfig option could never work and just causes a build error
when disabled:

security/apparmor/lsm.c:675:25: error: 'CONFIG_SECURITY_APPARMOR_HASH_DEFAULT' undeclared here (not in a function)
 bool aa_g_hash_policy = CONFIG_SECURITY_APPARMOR_HASH_DEFAULT;

The problem is that the macro undefined in this case, and we need to use the IS_ENABLED()
helper to turn it into a boolean constant.

Another minor problem with the original patch is that the option is even offered
in sysfs when SECURITY_APPARMOR_HASH is not enabled, so this also hides the option
in that case.

Signed-off-by: Arnd Bergmann 
Fixes: 6059f71f1e94 ("apparmor: add parameter to control whether policy hashing is used")
Signed-off-by: John Johansen 
Signed-off-by: James Morris

apparmor: fix arg_size computation for when setprocattr is null terminated

2016-07-12T15:43:10+00:00

Signed-off-by: John Johansen

apparmor: fix oops, validate buffer size in apparmor_setprocattr()

2016-07-12T15:43:10+00:00

When proc_pid_attr_write() was changed to use memdup_user apparmor's
(interface violating) assumption that the setprocattr buffer was always
a single page was violated.

The size test is not strictly speaking needed as proc_pid_attr_write()
will reject anything larger, but for the sake of robustness we can keep
it in.

SMACK and SELinux look safe to me, but somebody else should probably
have a look just in case.

Based on original patch from Vegard Nossum 
modified for the case that apparmor provides null termination.

Fixes: bb646cdb12e75d82258c2f2e7746d5952d3e321a
Reported-by: Vegard Nossum 
Cc: Al Viro 
Cc: John Johansen 
Cc: Paul Moore 
Cc: Stephen Smalley 
Cc: Eric Paris 
Cc: Casey Schaufler 
Cc: stable@kernel.org
Signed-off-by: John Johansen 
Reviewed-by: Tyler Hicks 
Signed-off-by: James Morris

apparmor: do not expose kernel stack

2016-07-12T15:43:10+00:00

Do not copy uninitalized fields th.td_hilen, th.td_data.

Signed-off-by: Heinrich Schuchardt 
Signed-off-by: John Johansen

apparmor: fix module parameters can be changed after policy is locked

2016-07-12T15:43:10+00:00

the policy_lock parameter is a one way switch that prevents policy
from being further modified. Unfortunately some of the module parameters
can effectively modify policy by turning off enforcement.

split policy_admin_capable into a view check and a full admin check,
and update the admin check to test the policy_lock parameter.

Signed-off-by: John Johansen

apparmor: fix oops in profile_unpack() when policy_db is not present

2016-07-12T15:43:10+00:00

BugLink: http://bugs.launchpad.net/bugs/1592547

If unpack_dfa() returns NULL due to the dfa not being present,
profile_unpack() is not checking if the dfa is not present (NULL).

Signed-off-by: John Johansen

apparmor: don't check for vmalloc_addr if kvzalloc() failed

2016-07-12T15:43:10+00:00

Signed-off-by: John Johansen

apparmor: add missing id bounds check on dfa verification

2016-07-12T15:43:10+00:00

Signed-off-by: John Johansen

apparmor: allow SYS_CAP_RESOURCE to be sufficient to prlimit another task

2016-07-12T15:43:10+00:00

While using AppArmor, SYS_CAP_RESOURCE is insufficient to call prlimit
on another task. The only other example of a AppArmor mediating access to
another, already running, task (ignoring fork+exec) is ptrace.

The AppArmor model for ptrace is that one of the following must be true:
1) The tracer is unconfined
2) The tracer is in complain mode
3) The tracer and tracee are confined by the same profile
4) The tracer is confined but has SYS_CAP_PTRACE

1), 2, and 3) are already true for setrlimit.

We can match the ptrace model just by allowing CAP_SYS_RESOURCE.

We still test the values of the rlimit since it can always be overridden
using a value that means unlimited for a particular resource.

Signed-off-by: Jeff Mahoney 
Signed-off-by: John Johansen