[Bisected] CONFIG_AUDIT in linux-3.14-rc1+ breaking Linux Containers?

Adam Richter adam_richter2004 at yahoo.com
Tue Feb 18 02:17:48 UTC 2014


Hi, Eric.

Thank you for your detailed reply.  I confirm that adding "audit=0" to the boot arguments to my linux-3.14-rc2-x86_64 kernel running Ubuntu 13.10-x86_64 allowed me to log into an Ubuntu 13.04-i386 container.  Thank you for providing this work around, and please feel free to let me know if there is anything else you'd like me to try.

Adam Richter





On Monday, February 17, 2014 11:02 AM, Eric Paris <eparis at redhat.com> wrote:
 
boot with audit=0 on the command line and it will work.

The basic problem is that before this patch, trying to connect to the
kernel audit infrastructure when setting up a separate network namespace
returned EOPNOTSUPP or some such thing which told the pam stack that
audit was not compiled into the kernel.

This patch means that the kernel audit is actually listening in the
network namespace.  But, mostly likely, it is now rejecting the pam
module request because the new container is in a new pid namespace.  We
should have patches to allow that in the next kernel release.

Let me know if booting with audit=0 gets you login in a container
back...


On Fri, 2014-02-14 at 14:56 -0800, Adam Richter wrote:
> Hi.
> 
> 
> 
> If I take an Ubuntu 13.10-amd64 system and install an Ubuntu
> 13.04-i386 Linux Container, it works fine with kernel.org kernel
> releases through Linux-3.13, but, for Linux-13.14-rc1 and beyond, I
> cannot login with "lxc-console".  In that case, if I try to log in as
> "ubuntu" with the correct password, it quickly tell me the login was
> incorrect, and prompts me with a new "login:" prompt, but without the
> delay that occurs if I type in the wrong password.  I haven't bothered
> breaking into the "linux container", but, looking at its log files
> from the outside as it runs, I see some PAM errors about "operation
> not permitted."
> 
> I have reproduced this problem with the following container
> configurations, all on an 
> Ubuntu 13.10-amd64 hosts ("amd64" is Ubuntu's terminology, not my
> jibing Intel):
> 
> Ubuntu 13.04-i386
> Ubuntu 13.10-i386
> Ubuntu 13.10-amd64
> 
> I have also reproduced this with a kernel built from
> git://git.infradead.org/users/eparis/audit.git yesterday (Ubuntu
> 13.10-amd64 hosting an Ubuntu 13.04-i386 container).
> 
> I have also tried disabling CONFIG_AUDIT{SYSCALL,_WATCH,_TREE} and
> CONFIG_KVM_MMU_AUDIT from linux-3.14-rc2-x86_64 and still observed the
> same problem.
> 
> Doing a "git bisect" on Linus's public tree brought me to the
> following change (Ubuntu 13.10-x86_64 hosting an Ubuntu 13.04-i386
> container):
> 
> 33faba7fa7f2288d2f8aaea95958b2c97bf9ebfb is the first bad commit
> commit 33faba7fa7f2288d2f8aaea95958b2c97bf9ebfb
> Author: Richard Guy Briggs <rgb at redhat.com>
> Date:   Tue Jul 16 13:18:45 2013 -0400
> 
>     audit: listen in all network namespaces
>    
>     Convert audit from only listening in init_net to use
> register_pernet_subsys()
>     to dynamically manage the netlink socket list.
>    
>     Signed-off-by: Richard Guy Briggs <rgb at redhat.com>
>     Signed-off-by: Eric Paris <eparis at redhat.com>
> 
> :040000 040000 3c5f63118d5fe9b5a4f0a6dd828249979a10ffa0
> c8feaa4fd9bc260cde3bb703ff20ae6938fabe6a M    kernel
> 
> For those of you who are not used to using Linux Containers, here are
> some commands that should reproduce the bug, although I am going from
> memory rather than copying from my command history.
> 
> % sudo lxc-create -t ubuntu -n myubuntu13.04 -- --release raring
> --arch i386
> # ^^ This takes a while.  It installs a Linux distribution in a
> directory.
> 
> % sudo lxc-start -n myubuntu13.04 -d
> % sudo lxc-console -n myubuntu13.04
> ...Try to log in as "ubuntu" with password "ubuntu".  When you'd done,
> do <ctrl-A>q to disconnect the session.
> % sudo lxc-stop -n myubuntu13.04
> # This next command basically does "rm -rf" on the container's
> directory tree.
> % sudo lxc-destroy -n myubuntu13.04
> 
> In the above example, change "raring" to "saucy" if you want Ubuntu
> 13.10.  You can change i386 to amd64 to try 64-bit.  "myubuntu13.04"
> is just a name, which you can change to whatever you want.  The Fedora
> container template shipped with Ubuntu 13.10 does not install for me,
> otherwise I would have tested that too.
> 
> I am not yet sure if this is really a kernel bug or if this is a case
> of a valid change in Linux kernel behavior exposing a bug elsewhere
> (for example, Ubuntu's PAM configuration).  I am not a Linux Audit
> developer.  I am hoping that, if this is a Linux Audit bug, you folks
> will be able to take it from here, but I'm happy to try to help as
> best I can.
> 
> Thanks in advance for any help with this.
> 
> Adam
> 
> 
> 
> --
> Linux-audit mailing list
> Linux-audit at redhat.com
> https://www.redhat.com/mailman/listinfo/linux-audit
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/linux-audit/attachments/20140217/c091dc30/attachment.htm>


More information about the Linux-audit mailing list