Richard Guy Briggs, a kernel security engineer and Senior Software Engineer at Red Hat, talked about the current state of Kernel Audit and Linux Namespaces at the Linux Security Summit. He also shared problems plaguing containers and what might be done to address them soon.
His insights are borne of deep experience. Briggs was an early adopter of Linux back in 1992, and has written UNIX and Linux device drivers for telecom, video and network applications and embedded devices.
Audit, which he describes as “Syslog on steroids,” exists as the means to securely document exactly what occurred where, when and by whom in case the need to pinpoint a problem in a court of law arises. It works well with SELinux and with other security modules in the kernel, and it only reports behavior; thus, it doesn’t interfere with anything running on the system. You can, however, panic the kernel and stop the run, that is, shut down the machine, if a situation exists that Audit is unable to document or report. Otherwise, configurable kernel filters render select activities of interest or more detail on something questionable while ignoring other behavior reports without interference with other activities.
To understand the current state of Kernel Audit, it’s important to understand its relationship with namespaces, which are kernel-enforced user space views. Currently, there are seven namespaces: peer namespaces which include the Mount namespace; the UTS namespace (hostname and domain information); the IPC namespace (no one really knows what this one does); NET namespaces which are peer systems, peer namespaces so the system comes up in the initial NET namespace and all of the physical devices appear in that namespace; and, three hierarchy namespaces – PID, User, and Cgroups – so that the permissions are inherited from one to another.
The User namespaces are the most contentious, because there are a number of traps inherent to their use making securing them vexing. “As a result, there are number of distributions that have not enabled user namespaces by default yet, because there’s still some work to be done to iron out where these are going,” Briggs said.
There Can Be Only One
As to containers, there is no hard definition as to what they are and certainly the kernel has no concept of containers. As far as the kernel is concerned, it’s a concept that’s completely in user space at the moment.
There is interest in the community to move beyond the general consensus in defining containers as a combination of kernel namespaces, secure computing, seccomp, and cgroups, to a clearer definition of what a container is allowed to do in order to create a better auditing trail.
The biggest problem with containers is that a set of namespaces doesn’t work. “At this point, there can only be one audit daemon, and it has to live in the initial user and PID namespace and that’s locked down by kernel rules that basically say it detects what namespaces you’re in,” he explained.
There have been security weaknesses in the Mount namespace since its inception, but that was not overly concerning as they were not actually abusable. Until, that is, other namespaces and more ways to use them were added.
Work is ongoing in addressing the security issues in User namespaces and newly exposed issues in Mount.
“In terms of audit, the audit daemon, it seems to make the most sense to tie the audit daemon in to the user namespace,” Briggs said.
“In terms of the network namespaces, the initial network namespace was the one that was originally listening and there were a number of proposals on how to try and deal with it. In the end, the least complex solution won out for the moment for the short term.”
Watch the complete presentation below:
Sign up to access more than 40 recorded sessions from LinuxCon + ContainerCon, including keynotes from Joe Beda, Jim Whitehurst, Cory Doctorow, and more.
