On Thu, 2005-05-19 at 11:27 -0400, Steve Grubb wrote:
On Tuesday 17 May 2005 09:12, Steve Grubb wrote:
> Then I'll ask Dan what's wrong. I think that libpam should probably be
> fixed if that is indeed the problem.
OK. I see the problem now.
In /fs/proc/base.c we have this code:
845 static ssize_t proc_loginuid_write(struct file * file, const char __user *
buf,
846 size_t count, loff_t *ppos)
847 {
854 if (!capable(CAP_AUDIT_CONTROL))
855 return -EPERM;
So, this means that the pam module has to have CONTROL capabilites to set the
loginuid. This is clearly not what we want. Should this be changed to WRITE
or should we have another capability? Or, does anyone have another idea?
No, CAP_AUDIT_WRITE would be worse, as any application that can generate
an audit message would then be able to also set its own loginuid.
Finer-grained control can be achieved using the SELinux permission
checks on netlink_audit_socket. CAP_AUDIT_CONTROL then becomes
necessary but not sufficient to modify the audit rules; you also need
SELinux nlmsg_write permission to netlink_audit_socket.
--
Stephen Smalley
National Security Agency