[PATCH for v3.14] AUDIT: Allow login in non-init namespaces
by Eric Paris
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(a)tomt.net>
Reported-by: Adam Richter <adam_richter2004(a)yahoo.com>
Signed-off-by: Eric Paris <eparis(a)redhat.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
10 years, 8 months
finit_module
by Steve Grubb
Hello,
In checking a system with newish kernel, 3.13.7, I noticed that sometimes
finit_module is producing PATH records. Why?
type=PATH msg=audit(04/04/2014 07:28:45.177:408) : item=1 name=(null)
inode=21788 dev=00:06 mode=dir,755 ouid=root ogid=root rdev=00:00
obj=system_u:object_r:debugfs_t:s0 nametype=CREATE
type=PATH msg=audit(04/04/2014 07:28:45.177:408) : item=0 name=(null)
inode=165 dev=00:06 mode=dir,755 ouid=root ogid=root rdev=00:00
obj=system_u:object_r:debugfs_t:s0 nametype=PARENT
type=SYSCALL msg=audit(04/04/2014 07:28:45.177:408) : arch=x86_64
syscall=finit_module success=yes exit=0 a0=0x0 a1=0x41a396 a2=0x0 a3=0x0
items=1348 ppid=1369 pid=1370 auid=unset uid=root gid=root euid=root suid=root
fsuid=root egid=root sgid=root fsgid=root ses=unset tty=(none) comm=modprobe
exe=/usr/bin/kmod subj=system_u:system_r:insmod_t:s0 key=module-load
Also, when it does this, it makes a whole lot of them:
type=PATH msg=audit(04/04/2014 07:28:45.177:408) : item=1347 name=(null)
inode=22461 dev=00:06 mode=dir,755 ouid=root ogid=root rde
v=00:00 obj=system_u:object_r:debugfs_t:s0 nametype=CREATE
Seriously, 1347 auxiliary records? Why?
-Steve
10 years, 8 months
ausearch question
by Burn Alting
All,
I note when interpreting raw audit with the ausearch --interpret option,
the code in src/ausearch-report.c:output_interpreted_node(), when
parsing key value pairs which are not enclosed in double or single
quotes, looks for embedded comma's in the value part and, if found,
effectively terminates the value at the comma. This in effect, makes the
data after the comma the start of the next key (if any). There are some
exceptions in the code (audit_type == AUDIT_VIRT_MACHINE_ID,
AUDIT_OBJ_PID, AUDIT_PATH and AUDIT_IPC).
What sort of input is this addressing?
Are there examples?
Thanks in advance
Burn
10 years, 8 months
Linux bug report submitted
by Burn Alting
All,
I finally submitted a bug report to the Linux kernel with respect to
invalid audit 'op' values.
The bug is listed as https://bugzilla.kernel.org/show_bug.cgi?id=73511
and is described as ...
Various audit events dealing with adding, removing and updating
rules result in invalid values set for the op keys which result
in embedded spaces in op= values.
The invalid values are
op="add rule" set in kernel/auditfilter.c
op="remove rule" set in kernel/auditfilter.c
op="remove rule" set in kernel/audit_tree.c
op="updated rules" set in kernel/audit_watch.c
op="remove rule" set in kernel/audit_watch.c
The attached patch replaces the space in the above values with
an underscore character ('_').
A patch was also provided.
One assumes the similar issues (cause keys having values with embedded
spaces) pointed out by Steve in the ima code in
https://www.redhat.com/archives/linux-audit/2014-April/msg00014.html
will also get fixed.
For those interested, I have attached the patch.
Rgds
10 years, 8 months
[RESEND PATCH 0/2] MIPS syscall auditing patches
by Manuel Lauss
From: Ralf Baechle <ralf(a)linux-mips.org>
Hello,
This is a resend of the syscall auditing patches for MIPS, as sent by
Ralf Baechle almost 3 years ago [1]. I've rediffed them against latest
linux kernels and audit userland trunk.
Here's what Ralf said then:
>>>
This is the first cut of the MIPS auditing patches. MIPS doesn't quite
fit into the existing pattern of other architectures and I'd appreciate
your comments and maybe even an Acked-by for the kernel part so I can
feed that upstream.
Ralf
<<<
Comments welcome!
Thanks,
Manuel Lauss
[1] https://www.redhat.com/archives/linux-audit/2011-June/msg00027.html
10 years, 8 months
