Re: [PATCH][RESEND 2] Revert "AUDIT: Allow login in non-init namespaces"

[Richard Guy Briggs <rgb@redhat.com>]

On 15/01/08, Calvin Owens wrote:
> This reverts 543bc6a1a987 "AUDIT: Allow login in non-init namespaces".
> 
> This commit incorrectly assumes that libpam treats -ECONNREFUSED as
> an indicator that audit is disabled, and -EPERM or any other error
> as a fatal error that prevents the login from continuing.

Which netlink audit message type is actually failing?
Is it AUDIT_TTY_{G,S}ET or is it an AUDIT_USER_* message?  The former
requires CAP_AUDIT_CONTROL and both PID and user init namespace (for
now) and the latter requires CAP_AUDIT_WRITE and only user init
namespace.

> The opposite is in fact true: -EPERM allows the login to continue,
> and -ECONNREFUSED causes it to refuse the login. This behavior has
> been unchanged in upstream linux-pam since at least 2008.

So this sounds to me like standard PAM usage is inverted from PAM usage
in containers.

> Reverting this change allows libpam to again work as expected in
> non-init user namespaces.

However, that will break other things...

Do you have test cases to show this?

Currently:
If audit is not available, return ECONNREFUSED. (netlink_unicast_kernel)

If not in init user namespace, return ECONNREFUSED. (audit_netlink_ok)

If control message and not init PID ns, return EPERM (audit_netlink_ok)

If control message and not CAP_AUDIT_CONTROL, return EPERM (audit_netlink_ok)

If user log message and not CAP_AUDIT_WRITE, return EPERM (audit_netlink_ok)

If unrecognized message, return EINVAL (audit_netlink_ok)


Listening in non-init net namespaces caused EPERM to be returned by
audit instead of ECONNREFUSED by netlink due to lack of perms when the
sending process didn't have CAP_AUDIT_WRITE.  Fixed in docker bz1119849
	http://blog.oddbit.com/2014/07/21/tracking-down-a-kernel-bug-wit/


> Signed-off-by: Calvin Owens <calvinowens@fb.com>
> Cc: stable@vger.kernel.org
> ---
> Relevant code in linux-pam:
> https://git.fedorahosted.org/cgit/linux-pam.git/tree/libpam/pam_audit.c#n56

This code only checks for an error return of -EPERM when the userid is
non-root.  Is login running as root, or has it already forked and is
running as an unprivileged user at that point?  Audit doesn't care about
the UID even though many equate root (superuser) with full capabilities.
Audit only looks at capabilities and namespaces.  Is this relevant to PAM?

>  kernel/audit.c | 12 +-----------
>  1 file changed, 1 insertion(+), 11 deletions(-)
> 
> diff --git a/kernel/audit.c b/kernel/audit.c
> index 80983df..656e8ce 100644
> --- a/kernel/audit.c
> +++ b/kernel/audit.c
> @@ -640,18 +640,8 @@ static int audit_netlink_ok(struct sk_buff *skb, u16 msg_type)
>  	int err = 0;
>  
>  	/* Only support initial user namespace for now. */
> -	/*
> -	 * We return ECONNREFUSED because it tricks userspace into thinking
> -	 * that audit was not configured into the kernel.  Lots of users
> -	 * configure their PAM stack (because that's what the distro does)
> -	 * to reject login if unable to send messages to audit.  If we return
> -	 * ECONNREFUSED the PAM stack thinks the kernel does not have audit
> -	 * configured in and will let login proceed.  If we return EPERM
> -	 * userspace will reject all logins.  This should be removed when we
> -	 * support non init namespaces!!
> -	 */
>  	if (current_user_ns() != &init_user_ns)
> -		return -ECONNREFUSED;
> +		return -EPERM;
>  
>  	switch (msg_type) {
>  	case AUDIT_LIST:

- RGB

--
Richard Guy Briggs <rbriggs@redhat.com>
Senior Software Engineer, Kernel Security, AMER ENG Base Operating Systems, Red Hat
Remote, Ottawa, Canada
Voice: +1.647.777.2635, Internal: (81) 32635, Alt: +1.613.693.0684x3545