#7: [PATCH] Allow changing of passwords in containers lacking CAP_AUDIT_WRITE --------------------+------------------------------- Reporter: lennart | Owner: pam-developers@… Type: defect | Status: new Priority: major | Component: modules Version: | Resolution: Keywords: | Blocked By: Blocking: | --------------------+------------------------------- Comment (by ldv): The issue is not new, it first arose about 3 years ago: http://sourceforge.net/mailarchive/forum.php?thread_name=20090408140842.G... =pam-patches There was no consensus to remove this unreliable getuid check, so I had to remove it in my branch only. Maybe we can agree now to remove the check. -- Ticket URL: <https://fedorahosted.org/linux-pam/ticket/7#comment:1> linux-pam <http://fedorahosted.org/linux-pam> The Linux-PAM (Pluggable Authentication Modules) project

Heya, On 23.04.2012 02:12, Kees Cook wrote: Well, there's more in this world than just capabalities. Some kind of other security framework might still prohibit processes audit write access for a reason: SELinux, AppArmor or any other LSM. I think it is generally a bad idea to second-guess the kernel here, and try to come to the same security check conclusion as the kernel without actually being the kernel. I think the best way to check whether writing to audit works is actually doing it and looking for EPERM. Lennart

#7: [PATCH] Allow changing of passwords in containers lacking CAP_AUDIT_WRITE --------------------+------------------------------- Reporter: lennart | Owner: pam-developers@… Type: defect | Status: new Priority: major | Component: modules Version: | Resolution: Keywords: | Blocked By: Blocking: | --------------------+------------------------------- Comment (by lennart): Replying to [comment:2 sgrubb]: is not part of any Common Criteria evaluation. The reality is that all use of the authentication mechanism is supposed to be audited. This is a mandatory requirement. So, it sounds like something is being creating that violates this basic security requirement and the code is being changed so it does not fail. point. Does this container have access to pam_faillock's state directories? Does this container also correctly update btmp and wtmp for the system? certain number of failed login attempts and that on successful login the number of bad login attempts since last login as well as the last login date and time be displayed. This must be shared across different services. Umm, no. This is about running a second Fedora instance on another Fedora instance inside a Linux container (i.e. something built from Linux namespaces, cgroups and dropped capabilities). Since we don't want that the second instance's auditing messages pollute the audit logs of the host (since they make little sense outside the context of the container), we turn off CAP_AUDIT_WRITE for the container. This works mostly fine except that the audit stuff in PAM then chokes on this and in the ill belief it was always in the possession of all capabilities refuses logins and password changes. The container maintains its own faillog, it's own wtmp, it's on btmp. It's a second system within the host, that should share as little with the host as possible. And one thing is the audit stuff. -- Ticket URL: <https://fedorahosted.org/linux-pam/ticket/7#comment:3> linux-pam <http://fedorahosted.org/linux-pam> The Linux-PAM (Pluggable Authentication Modules) project

#7: [PATCH] Allow changing of passwords in containers lacking CAP_AUDIT_WRITE --------------------+------------------------------- Reporter: lennart | Owner: pam-developers@… Type: defect | Status: new Priority: major | Component: modules Version: | Resolution: Keywords: | Blocked By: Blocking: | --------------------+------------------------------- Comment (by lennart): Replying to [comment:4 kukuk]: Fedora instance inside a Linux container (i.e. something built from Linux namespaces, cgroups and dropped capabilities). Since we don't want that the second instance's auditing messages pollute the audit logs of the host (since they make little sense outside the context of the container), we turn off CAP_AUDIT_WRITE for the container. This works mostly fine except that the audit stuff in PAM then chokes on this and in the ill belief it was always in the possession of all capabilities refuses logins and password changes. system without audit log, and this is an absolute no-go. Hmm? That's not true. We still check for EPERM here, which is about access control not about "audit not available". own auditing. This is not supported on Linux, and is not even desirable in many cases where the host shall do auditing but the container shouldn't. Forcing the container to use auditing just because the host uses it is very suboptimal, since containers are intended to be lightweight. I mean, if I run a 1000 containers on a server with an Apache in each, then I am quite sure I want to avoid running a 1000 auditds for that. But since I rent these 1000 auditds to customers who can do with it what they want I also don't want those logs show up in the main audit logs, and generate noise. And honestly, a setup like I just described is probably going to be the common use case for containers, not the exception. -- Ticket URL: <https://fedorahosted.org/linux-pam/ticket/7#comment:5> linux-pam <http://fedorahosted.org/linux-pam> The Linux-PAM (Pluggable Authentication Modules) project