Capabilities audit field

Capabilities audit field

[Steve Grubb]

Hi,

I recenetly found out that the kernel now allows more than 32 capabilities. 
This means I need to update the audit code that inteprets this value given 
from SE Linux. When I looked over the 2.6.27 kernel code, I found that SE 
Linux has not updated the capabilities code. Its still being kept as a simple 
integer in avc.h, but everywhere else I look in the kernel has moved to 
kernel_cap_t, which is an array. Are patches for moving to kernel_cap_t 
scheduled for 2.6.28? Are there security implications for not being able to 
access or control capabilities > 32?

Thanks,
-Steve

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: Capabilities audit field

[James Morris]

On Sun, 12 Oct 2008, Steve Grubb wrote:

> Hi,
> 
> I recenetly found out that the kernel now allows more than 32 capabilities. 
> This means I need to update the audit code that inteprets this value given 
> from SE Linux. When I looked over the 2.6.27 kernel code, I found that SE 
> Linux has not updated the capabilities code. Its still being kept as a simple 
> integer in avc.h, but everywhere else I look in the kernel has moved to 
> kernel_cap_t, which is an array. Are patches for moving to kernel_cap_t 
> scheduled for 2.6.28? Are there security implications for not being able to 
> access or control capabilities > 32?

The AVC can opnly handle 32-bit vectors, so a capability2 class was added 
to handle capabilities over 32-bits.

See

http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=b68e418c445e8a468634d0a7ca2fb63bbaa74028


-- 
James Morris
<jmorris@namei.org>

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: Capabilities audit field

[Joshua Brindle]

Steve Grubb wrote:
> Hi,
>
> I recenetly found out that the kernel now allows more than 32 capabilities. 
> This means I need to update the audit code that inteprets this value given 
> from SE Linux. When I looked over the 2.6.27 kernel code, I found that SE 
> Linux has not updated the capabilities code. Its still being kept as a simple 
> integer in avc.h, but everywhere else I look in the kernel has moved to 
> kernel_cap_t, which is an array. Are patches for moving to kernel_cap_t 
> scheduled for 2.6.28? Are there security implications for not being able to 
> access or control capabilities > 32?
>   

SELinux added an additional object class (capability2) so as to not 
extend the access vector.

The current object class looks like this:
class capability2
{
        mac_override    # unused by SELinux
        mac_admin       # unused by SELinux
}

We can control them but they should never be hit on an SELinux system 
anyway (IIUC)



--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: Capabilities audit field

[James Morris]

On Sun, 12 Oct 2008, Joshua Brindle wrote:

> Steve Grubb wrote:
> > Hi,
> > 
> > I recenetly found out that the kernel now allows more than 32 capabilities.
> > This means I need to update the audit code that inteprets this value given
> > from SE Linux. When I looked over the 2.6.27 kernel code, I found that SE
> > Linux has not updated the capabilities code. Its still being kept as a
> > simple integer in avc.h, but everywhere else I look in the kernel has moved
> > to kernel_cap_t, which is an array. Are patches for moving to kernel_cap_t
> > scheduled for 2.6.28? Are there security implications for not being able to
> > access or control capabilities > 32?
> >   
> 
> SELinux added an additional object class (capability2) so as to not extend the
> access vector.
> 
> The current object class looks like this:
> class capability2
> {
>        mac_override    # unused by SELinux
>        mac_admin       # unused by SELinux
> }
> 
> We can control them but they should never be hit on an SELinux system anyway
> (IIUC)

mac_admin is used to set and view deferred labels.

-- 
James Morris
<jmorris@namei.org>

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: Capabilities audit field

[Steve Grubb]

On Sunday 12 October 2008 19:12:47 James Morris wrote:
> On Sun, 12 Oct 2008, Steve Grubb wrote:
> > I recently found out that the kernel now allows more than 32
> > capabilities. This means I need to update the audit code that inteprets
> > this value given from SE Linux. When I looked over the 2.6.27 kernel
> > code, I found that SE Linux has not updated the capabilities code. Its
> > still being kept as a simple integer in avc.h, but everywhere else I look
> > in the kernel has moved to kernel_cap_t, which is an array. Are patches
> > for moving to kernel_cap_t scheduled for 2.6.28? Are there security
> > implications for not being able to access or control capabilities > 32?
>
> The AVC can opnly handle 32-bit vectors, so a capability2 class was added
> to handle capabilities over 32-bits.
>
> See
>
> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h
>=b68e418c445e8a468634d0a7ca2fb63bbaa74028

Then does this need some updating in avc.c ?

 570                case AVC_AUDIT_DATA_CAP:
 571                        audit_log_format(ab, " capability=%d", a->u.cap);
 572                        break;


Thanks,
-Steve

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: Capabilities audit field

[James Morris]

On Mon, 13 Oct 2008, Steve Grubb wrote:

> Then does this need some updating in avc.c ?
> 
>  570                case AVC_AUDIT_DATA_CAP:
>  571                        audit_log_format(ab, " capability=%d", a->u.cap);
>  572                        break;

Nope, the capability number is correctly recorded in a->u.cap, and you'll 
also see capability2 as the tclass value.


- James
-- 
James Morris
<jmorris@namei.org>

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: Capabilities audit field

[Steve Grubb]

On Monday 13 October 2008 18:54:50 James Morris wrote:
> >  570                case AVC_AUDIT_DATA_CAP:
> >  571                        audit_log_format(ab, " capability=%d",
> > a->u.cap); 572                        break;
>
> Nope, the capability number is correctly recorded in a->u.cap, and you'll
> also see capability2 as the tclass value.

avc:  denied  { ipc_owner } for  pid=4653 comm="ntpd" capability=15
scontext=root:system_r:ntpd_t tcontext=root:system_r:ntpd_t
tclass=capability

Hmm...the tclass field, being at the end, has not been parsed at the moment I 
need it to decide what capability we are talking about. tclass really should 
have been moved up nearer the beginning if its being used to determine how to 
interpret other fields. It would be nicer if there was some hint at whether 
we are dealing with a cap1 or cap2 capability before the capability field. I 
guess my other choice is to drop interpretation of capabilities in ausearch 
since now I don't know which set to use until after I've already printed what 
I thought it was.

-Steve


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: Capabilities audit field

[James Morris]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 1270 bytes --]

On Mon, 13 Oct 2008, Steve Grubb wrote:

> On Monday 13 October 2008 18:54:50 James Morris wrote:
> > >  570                case AVC_AUDIT_DATA_CAP:
> > >  571                        audit_log_format(ab, " capability=%d",
> > > a->u.cap); 572                        break;
> >
> > Nope, the capability number is correctly recorded in a->u.cap, and you'll
> > also see capability2 as the tclass value.
> 
> avc:  denied  { ipc_owner } for  pid=4653 comm="ntpd" capability=15
> scontext=root:system_r:ntpd_t tcontext=root:system_r:ntpd_t
> tclass=capability
> 
> Hmm...the tclass field, being at the end, has not been parsed at the moment I 
> need it to decide what capability we are talking about. tclass really should 
> have been moved up nearer the beginning if its being used to determine how to 
> interpret other fields. It would be nicer if there was some hint at whether 
> we are dealing with a cap1 or cap2 capability before the capability field. I 
> guess my other choice is to drop interpretation of capabilities in ausearch 
> since now I don't know which set to use until after I've already printed what 
> I thought it was.

The capability number reported will be correct in its own right, 
regardless of the class.


-- 
James Morris
<jmorris@namei.org>

Re: Capabilities audit field

[Stephen Smalley]

On Mon, 2008-10-13 at 06:35 -0400, Steve Grubb wrote:
> On Sunday 12 October 2008 19:12:47 James Morris wrote:
> > On Sun, 12 Oct 2008, Steve Grubb wrote:
> > > I recently found out that the kernel now allows more than 32
> > > capabilities. This means I need to update the audit code that inteprets
> > > this value given from SE Linux. When I looked over the 2.6.27 kernel
> > > code, I found that SE Linux has not updated the capabilities code. Its
> > > still being kept as a simple integer in avc.h, but everywhere else I look
> > > in the kernel has moved to kernel_cap_t, which is an array. Are patches
> > > for moving to kernel_cap_t scheduled for 2.6.28? Are there security
> > > implications for not being able to access or control capabilities > 32?
> >
> > The AVC can opnly handle 32-bit vectors, so a capability2 class was added
> > to handle capabilities over 32-bits.
> >
> > See
> >
> > http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h
> >=b68e418c445e8a468634d0a7ca2fb63bbaa74028
> 
> Then does this need some updating in avc.c ?
> 
>  570                case AVC_AUDIT_DATA_CAP:
>  571                        audit_log_format(ab, " capability=%d", a->u.cap);
>  572                        break;

Just to clarify:  this is reporting the simple integer value of the
capability (which is not a permission bitmask).  So it doesn't require
any changes.  For example, for capability 33, this will report
capability=33.  

That simple integer value is mapped to an index via CAP_TO_INDEX() and
to a bitmask via CAP_TO_MASK() in order to determine the right class and
permission bit to check for SELinux (see task_has_capability in
security/selinux/hooks.c), or to select the right word and bit within
the cap bitmap to check for capabilities (see cap_raised in
include/linux/capability.h).

-- 
Stephen Smalley
National Security Agency


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.