linux-kernel - Re: [PATCH for v3.14] AUDIT: Allow login in non-init namespaces

Open Source and information security mailing list archives

Message-ID: <20140331005713.GA6407@sergelap>
Date:	Sun, 30 Mar 2014 19:57:13 -0500
From:	Serge Hallyn <serge.hallyn@...ntu.com>
To:	Eric Paris <eparis@...hat.com>
Cc:	Linus Torvalds <torvalds@...ux-foundation.org>, rgb@...hat.com,
	containers@...ts.linux-foundation.org, linux-audit@...hat.com,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH for v3.14] AUDIT: Allow login in non-init namespaces

Quoting Eric Paris (eparis@...hat.com):
> It its possible to configure your PAM stack to refuse login if
> audit messages (about the login) were unable to be sent.  This is common
> in many distros and thus normal configuration of many containers. The
> PAM modules determine if audit is enabled/disabled in the kernel based
> on the return value from sending an audit message on the netlink socket.
> If userspace gets back ECONNREFUSED it believes audit is disabled in the
> kernel.  If it gets any other error else it refuses to let the login
> proceed.
> 
> Just about ever since the introduction of namespaces the kernel audit
> subsystem has returned EPERM if the task sending a message was not in
> the init user or pid namespace.  So many forms of containers have never
> worked if audit was enabled in the kernel.
> 
> BUT if the container was not in net_init then the kernel network code
> would send ECONNREFUSED (instead of the audit code sending EPERM).  Thus
> by pure accident/dumb luck/bug if an admin configured the PAM stack to
> reject all logins that didn't talk to audit, but then ran the login
> untility in the non-init_net namespace, it would work!!  Clearly this
> was a bug, but it is a bug some people expected.
> 
> With the introduction of network namespace support in 3.14-rc1 the two
> bugs stopped cancelling each other out.  Now, containers in the
> non-init_net namespace refused to let users log in (just like PAM was
> configfured!)  Obviously some people were not happy that what used to
> let users log in, now didn't!
> 
> This fix is kinda hacky.  We return ECONNREFUSED for all non-init
> relevant namespaces.  That means that not only will the old broken
> non-init_net setups continue to work, now the broken non-init_pid or
> non-init_user setups will 'work'.  They don't really work, since audit
> isn't logging things.  But it's what most users want.
> 
> In 3.15 we should have patches to support not only the non-init_net
> (3.14) namespace but also the non-init_pid and non-init_user namespace.
> So all will be right in the world.  This just opens the doors wide open
> on 3.14 and hopefully makes users happy, if not the audit system...
> 
> Reported-by: Andre Tomt <andre@...t.net>
> Reported-by: Adam Richter <adam_richter2004@...oo.com>
> Signed-off-by: Eric Paris <eparis@...hat.com>

Acked-by: Serge E. Hallyn <serge.hallyn@...ntu.com>

> ---
>  kernel/audit.c | 12 +++++++++++-
>  1 file changed, 11 insertions(+), 1 deletion(-)
> 
> diff --git a/kernel/audit.c b/kernel/audit.c
> index 3392d3e..95a20f3 100644
> --- a/kernel/audit.c
> +++ b/kernel/audit.c
> @@ -608,9 +608,19 @@ static int audit_netlink_ok(struct sk_buff *skb, u16 msg_type)
>  	int err = 0;
>  
>  	/* Only support the initial namespaces 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) ||
>  	    (task_active_pid_ns(current) != &init_pid_ns))
> -		return -EPERM;
> +		return -ECONNREFUSED;
>  
>  	switch (msg_type) {
>  	case AUDIT_LIST:
> -- 
> 1.8.5.3
> 
> 
> 
> _______________________________________________
> Containers mailing list
> Containers@...ts.linux-foundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/containers
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives