7:27 a.m.
Hi,
We're starting to see bug reports of SELinux denials with no audit
messages in FC4/devel due to the fact that the audit capabilities are
checked on the receive side via a direct cap_raised() test on the
effective capability set saved earlier by the netlink_send hook. This
manifests as programs failing in enforcing mode and working in
permissive mode, but no audit messages being generated. I know there
was an earlier rfc/patch by Chris to allow moving the netlink message
checking to the send side via a new callback, which would allow us to
perform a traditional capable() call rather than a direct cap_raised()
test and thus have the usual auditing behavior for SELinux there. Is
that stalled?
--
Stephen Smalley
National Security Agency
7:52 a.m.
On Tuesday 17 May 2005 08:27, Stephen Smalley wrote:
We're starting to see bug reports of SELinux denials with no
audit
messages in FC4/devel due to the fact that the audit capabilities are
checked on the receive side via a direct cap_raised() test on the
effective capability set saved earlier by the netlink_send hook.
Is the bug report in bugzilla or a mail list? I'd like to see it to figure out
what best to do.
This manifests as programs failing in enforcing mode and working in
permissive mode, but no audit messages being generated.
Was the program making calls into the audit system? pam is the only thing that
does that in the public. If there's a problem with pam, I need to know.
I know there was an earlier rfc/patch by Chris to allow moving the
netlink
message checking to the send side via a new callback, which would allow us
to perform a traditional capable() call rather than a direct cap_raised()
test and thus have the usual auditing behavior for SELinux there. Is
that stalled?
What are we doing wrong? Shouldn't it be a matter of calling the right selinux
function for a capabilities check after the DAC checks? That seems simpler
and has less impact on user space.
-Steve
7:53 a.m.
On Tue, 2005-05-17 at 08:52 -0400, Steve Grubb wrote:
Is the bug report in bugzilla or a mail list? I'd like to see it
to figure out
what best to do.
Private email from Dan Walsh. This one was for vsftpd; failed unless
given audit_control, which seems wrong anyway. I assume libpam is
triggering it.
Was the program making calls into the audit system? pam is the only
thing that
does that in the public. If there's a problem with pam, I need to know.
I'm assuming it is being caused by libpam, although I don't know much
beyond the fact that vsftpd stopped working without it.
What are we doing wrong? Shouldn't it be a matter of calling the
right selinux
function for a capabilities check after the DAC checks? That seems simpler
and has less impact on user space.
The problem arises from the async nature of netlink processing; the
effective capability bitmap of the task is computed and saved in the
netlink message's control buffer at send time, and then the receive-side
kernel code just checks the appropriate capability bit in that bitmap
(in audit_netlink_ok for the audit code). SELinux sees the send-time
computation, but doesn't know a priori what capabilities, if any, will
be checked by the receive side code, so it just performs a computation
of what is allowed and doesn't audit anything at that point. Then, when
the message is received and processed, audit_netlink_ok() just checks
the capability bit and SELinux isn't involved, so no audit message is
generated. Even if you changed audit_netlink_ok() to call a LSM hook
rather than directly performing a cap_raised() test, SELinux wouldn't
know the security context of the sender, since that isn't saved with the
netlink message. Simplest solution is Chris' earlier patches to allow
callbacks to be registered for netlink send so that audit_netlink_ok()
checking can occur at send time. At that point, audit_netlink_ok() can
perform capable() checks against the current task, which will trigger
SELinux audit as expected.
--
Stephen Smalley
National Security Agency
8:12 a.m.
On Tuesday 17 May 2005 08:53, Stephen Smalley wrote:
I'm assuming it is being caused by libpam, although I don't
know much
beyond the fact that vsftpd stopped working without it.
Then I'll ask Dan what's wrong. I think that libpam should probably be fixed
if that is indeed the problem.
> What are we doing wrong? Shouldn't it be a matter of calling
the right
> selinux function for a capabilities check after the DAC checks?
Even if you changed audit_netlink_ok() to call a LSM hook
rather than directly performing a cap_raised() test, SELinux wouldn't
know the security context of the sender, since that isn't saved with the
netlink message.
We need to do this for LSPP, so maybe we should take that step if needed.
Simplest solution is Chris' earlier patches to allow
callbacks to be registered for netlink send so that audit_netlink_ok()
checking can occur at send time.
My only concern is whether or not this will impact the user space side.
-Steve
10:27 a.m.
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?
-Steve
10:32 a.m.
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
11:49 a.m.
Quoting Stephen Smalley (sds(a)tycho.nsa.gov):
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.
So we can add a security_audit_loginuid() hook. Do we consider this a
good reason to switch from capabilities to LSM hooks for all the audit
permissions?
-serge
11:49 a.m.
On Thu, 2005-05-19 at 11:49 -0500, serue(a)us.ibm.com wrote:
Quoting Stephen Smalley (sds(a)tycho.nsa.gov):
> 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.
So we can add a security_audit_loginuid() hook. Do we consider this a
good reason to switch from capabilities to LSM hooks for all the audit
permissions?
Not clear you need such a hook. The current situation is as follows:
1) Without SELinux, CAP_AUDIT_CONTROL allows both setting of loginuid
and control over audit rules and settings.
2) With SELinux, CAP_AUDIT_CONTROL allows setting of loginuid, and
CAP_AUDIT_CONTROL + netlink_audit_socket:nlmsg_write permission allows
setting of loginuid and control over audit rules and settings.
Hence, you can allow some programs to set their loginuid
(capability:audit_control) without allowing them to modify audit rules
or settings (netlink_audit_socket:nlmsg_write). Only reason you would
need a hook on setting the loginuid is if you want to allow some
programs to modify audit settings and rules without being able to set
their loginuid, but it isn't clear that is justified, as they can always
just disable auditing entirely at that point (except for the event of
disabling auditing itself).
--
Stephen Smalley
National Security Agency
8:04 a.m.
On Tue, 2005-05-17 at 08:27 -0400, Stephen Smalley wrote:
I know there was an earlier rfc/patch by Chris to allow moving the
netlink message checking to the send side via a new callback, which
would allow us to perform a traditional capable() call rather than a
direct cap_raised() test and thus have the usual auditing behavior for
SELinux there. Is that stalled?
It was decided at the time that there was insufficient reason to make
such a change. I don't remember whether Chris had updated and completed
the patch by then or not; I suspect not.
--
dwmw2
12:40 p.m.
* David Woodhouse (dwmw2(a)infradead.org) wrote:
On Tue, 2005-05-17 at 08:27 -0400, Stephen Smalley wrote:
> I know there was an earlier rfc/patch by Chris to allow moving the
> netlink message checking to the send side via a new callback, which
> would allow us to perform a traditional capable() call rather than a
> direct cap_raised() test and thus have the usual auditing behavior for
> SELinux there. Is that stalled?
It was decided at the time that there was insufficient reason to make
such a change. I don't remember whether Chris had updated and completed
the patch by then or not; I suspect not.
I did not update it beyond the patch I sent before I left for Cambridge.
We talked about leaving it as is and putting the loginuid directly into
netlink_skb_parms. I can dust it off and resend if it's useful.
thanks,
-chris
7203
days inactive
7205
days old
linux-audit@lists.linux-audit.osci.io
9 comments
5 participants
participants (5)
-
Chris Wright -
David Woodhouse -
serue＠us.ibm.com -
Stephen Smalley -
Steve Grubb