linux-stable.git/kernel/auditsc.c, branch v3.13.2

audit: fix type of sessionid in audit_set_loginuid()

2013-11-06T16:47:24+00:00

sfr pointed out that with CONFIG_UIDGID_STRICT_TYPE_CHECKS set the audit
tree would not build.  This is because the oldsessionid in
audit_set_loginuid() was accidentally being declared as a kuid_t.  This
patch fixes that declaration mistake.

Example of problem:
kernel/auditsc.c: In function 'audit_set_loginuid':
kernel/auditsc.c:2003:15: error: incompatible types when assigning to
type 'kuid_t' from type 'int'
  oldsessionid = audit_get_sessionid(current);

Reported-by: Stephen Rothwell 
Signed-off-by: Eric Paris

audit: call audit_bprm() only once to add AUDIT_EXECVE information

2013-11-05T16:15:03+00:00

Move the audit_bprm() call from search_binary_handler() to exec_binprm().  This
allows us to get rid of the mm member of struct audit_aux_data_execve since
bprm->mm will equal current->mm.

This also mitigates the issue that ->argc could be modified by the
load_binary() call in search_binary_handler().

audit_bprm() was being called to add an AUDIT_EXECVE record to the audit
context every time search_binary_handler() was recursively called.  Only one
reference is necessary.

Reported-by: Oleg Nesterov 
Cc: Eric Paris 
Signed-off-by: Richard Guy Briggs 
Signed-off-by: Eric Paris 
---
This patch is against 3.11, but was developed on Oleg's post-3.11 patches that
introduce exec_binprm().

audit: move audit_aux_data_execve contents into audit_context union

2013-11-05T16:09:36+00:00

audit_bprm() was being called to add an AUDIT_EXECVE record to the audit
context every time search_binary_handler() was recursively called.  Only one
reference is necessary, so just update it.  Move the the contents of
audit_aux_data_execve into the union in audit_context, removing dependence on a
kmalloc along the way.

Reported-by: Oleg Nesterov 
Cc: Eric Paris 
Signed-off-by: Richard Guy Briggs 
Signed-off-by: Eric Paris

audit: remove unused envc member of audit_aux_data_execve

2013-11-05T16:09:31+00:00

Get rid of write-only audit_aux_data_exeve structure member envc.

Signed-off-by: Richard Guy Briggs 
Signed-off-by: Eric Paris

audit: Kill the unused struct audit_aux_data_capset

2013-11-05T16:09:20+00:00

Signed-off-by: "Eric W. Biederman" 
(cherry picked from ebiederman commit 6904431d6b41190e42d6b94430b67cb4e7e6a4b7)
Signed-off-by: Eric Paris

audit: update AUDIT_INODE filter rule to comparator function

2013-11-05T16:08:24+00:00

It appears this one comparison function got missed in f368c07d (and 9c937dcc).

Signed-off-by: Richard Guy Briggs 
Signed-off-by: Eric Paris

audit: audit feature to set loginuid immutable

2013-11-05T16:08:17+00:00

This adds a new 'audit_feature' bit which allows userspace to set it
such that the loginuid is absolutely immutable, even if you have
CAP_AUDIT_CONTROL.

Signed-off-by: Eric Paris 
Signed-off-by: Richard Guy Briggs 
Signed-off-by: Eric Paris

audit: audit feature to only allow unsetting the loginuid

2013-11-05T16:08:13+00:00

This is a new audit feature which only grants processes with
CAP_AUDIT_CONTROL the ability to unset their loginuid.  They cannot
directly set it from a valid uid to another valid uid.  The ability to
unset the loginuid is nice because a priviledged task, like that of
container creation, can unset the loginuid and then priv is not needed
inside the container when a login daemon needs to set the loginuid.

Signed-off-by: Eric Paris 
Signed-off-by: Richard Guy Briggs 
Signed-off-by: Eric Paris

audit: allow unsetting the loginuid (with priv)

2013-11-05T16:08:09+00:00

If a task has CAP_AUDIT_CONTROL allow that task to unset their loginuid.
This would allow a child of that task to set their loginuid without
CAP_AUDIT_CONTROL.  Thus when launching a new login daemon, a
priviledged helper would be able to unset the loginuid and then the
daemon, which may be malicious user facing, do not need priv to function
correctly.

Signed-off-by: Eric Paris 
Signed-off-by: Richard Guy Briggs 
Signed-off-by: Eric Paris

audit: remove CONFIG_AUDIT_LOGINUID_IMMUTABLE

2013-11-05T16:08:01+00:00

After trying to use this feature in Fedora we found the hard coding
policy like this into the kernel was a bad idea.  Surprise surprise.
We ran into these problems because it was impossible to launch a
container as a logged in user and run a login daemon inside that container.
This reverts back to the old behavior before this option was added.  The
option will be re-added in a userspace selectable manor such that
userspace can choose when it is and when it is not appropriate.

Signed-off-by: Eric Paris 
Signed-off-by: Richard Guy Briggs 
Signed-off-by: Eric Paris