10:41 a.m.
Hi,
I ran across something that I was wondering if we have a deficiency/bug. Do we
need to capture supplemental group information? For example:
[sgrubb@beast ~]$ su - root
Password:
[root@beast ~]# echo "test" > /opt/test.txt
[root@beast ~]# chmod 0660 /opt/test.txt
[root@beast ~]# chgrp wheel /opt/test.txt
[root@beast ~]# ls -l /opt/test.txt
-rw-rw---- 1 root wheel 5 Feb 22 11:30 /opt/test.txt
[root@beast ~]# auditctl -a exit,always -S open -F loginuid=501
AUDIT_LIST: exit always loginuid=501 (0x10e5) syscall=open
We created a file that's readable if you have wheel as a supplemental group.
Now from another terminal:
[sgrubb@beast ~]$ cat /opt/test.txt
test
[sgrubb@beast ~]$
OK...it worked. So let's go see what's in the logs:
type=KERNEL msg=audit(1109089864.512:6279351): item=0 name=/opt/test.txt
inode=136 dev=00:00
type=KERNEL msg=audit(1109089864.512:6279351): syscall=5 exit=3 a0=bff6aa07
a1=8000 a2=0 a3=8000 items=1 pid=26538 loginuid=501 uid=501 gid=501 euid=501
suid=501 fsuid=501 egid=501 sgid=501 fsgid=501
Somewhere in there I expected group #10 to be mentioned since that is what
gave me access capability to the file. Does anyone know why its not recorded?
Don't we need that information?
-Steve Grubb
11:50 a.m.
* Steve Grubb (sgrubb(a)redhat.com) wrote:
type=KERNEL msg=audit(1109089864.512:6279351): item=0
name=/opt/test.txt
inode=136 dev=00:00
type=KERNEL msg=audit(1109089864.512:6279351): syscall=5 exit=3 a0=bff6aa07
a1=8000 a2=0 a3=8000 items=1 pid=26538 loginuid=501 uid=501 gid=501 euid=501
suid=501 fsuid=501 egid=501 sgid=501 fsgid=501
Somewhere in there I expected group #10 to be mentioned since that is what
gave me access capability to the file. Does anyone know why its not recorded?
It's a simple dump of basic credentials. Not only are supplemental
groups not dumped (nor capabilities), but also there is nothing that's
telling you what mode (or capability) granted you the access (ignoring
SELinux audit records).
Don't we need that information?
I don't know, I don't think it's explicitly required by CAPP (unless
you interpret subject identity to include suplemental group IDs).
As far as groups go, they can become large (no longer a fixed size array).
thanks,
-chris
--
Linux Security Modules http://lsm.immunix.org http://lsm.bkbits.net
11:58 a.m.
On Tuesday 22 February 2005 12:50, Chris Wright wrote:
I don't know, I don't think it's explicitly required by
CAPP (unless
you interpret subject identity to include suplemental group IDs).
Yes, this is what I was meaning.
As far as groups go, they can become large (no longer a fixed size
array).
I'm only wondering about the one group that was used to grant access, not the
whole collection that any user belongs to.
-Steve
12:01 p.m.
* Steve Grubb (sgrubb(a)redhat.com) wrote:
On Tuesday 22 February 2005 12:50, Chris Wright wrote:
> I don't know, I don't think it's explicitly required by CAPP (unless
> you interpret subject identity to include suplemental group IDs).
Yes, this is what I was meaning.
> As far as groups go, they can become large (no longer a fixed size array).
I'm only wondering about the one group that was used to grant access, not the
whole collection that any user belongs to.
Yeah, that's the bit that's not tracked at all.
thanks,
-chris
--
Linux Security Modules http://lsm.immunix.org http://lsm.bkbits.net
12:02 p.m.
--- Chris Wright <chrisw(a)osdl.org> wrote:
> Don't we need that information?
I don't know, I don't think it's explicitly required
by CAPP (unless
you interpret subject identity to include
suplemental group IDs).
If the suplemental group information is used
to make access control decisions it needs to
be in the audit record. Same with the capabilities.
=====
Casey Schaufler
casey(a)schaufler-ca.com
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
10:55 a.m.
On Tue, Feb 22, 2005 at 10:02:55AM -0800, Casey Schaufler wrote:
--- Chris Wright <chrisw(a)osdl.org> wrote:
> I don't know, I don't think it's explicitly required by CAPP (unless
> you interpret subject identity to include suplemental group IDs).
If the suplemental group information is used to make access control
decisions it needs to be in the audit record. Same with the
capabilities.
Sorry to disagree once again, but auditing the reasons for access control
decisions isn't required by CAPP anywhere, see section 5.1.1.2 and table
1 for the exhaustive list of audit record requirements. It just needs to
record the success/failure result of the operation.
LSPP adds a requirement that the "sensitivity labels of subjects,
objects, or information involved" be included in each audit record
(that's the MAC information), this does not include any DAC information
such as group membership or ACLs.
I agree that having this type of information in the audit records would
be useful, but doing it right would need many changes to the OS and goes
beyond what CAPP/LSPP require.
Capabilities are different, this could be considered to be covered by the
"use of the rights of a role" requirement for FMT_SMR.1. The existing
Linux security targets had not made any fine-grained role distinctions
based on capabilities, they have used the simplified "administrator ==
UID 0 == all capabilities" model which makes it sufficient to record the
effective UID. If you have an ST that identifies distinct roles based on
individual capability bits, you would need to audit the current
capabilities of the process. Note that the audit requirement for CAPP and
LSPP is that "the role and the origin of the request" be included in the
record.
-Klaus
11:07 a.m.
* Klaus Weidner (klaus(a)atsec.com) wrote:
On Tue, Feb 22, 2005 at 10:02:55AM -0800, Casey Schaufler wrote:
> --- Chris Wright <chrisw(a)osdl.org> wrote:
> > I don't know, I don't think it's explicitly required by CAPP
(unless
> > you interpret subject identity to include suplemental group IDs).
>
> If the suplemental group information is used to make access control
> decisions it needs to be in the audit record. Same with the
> capabilities.
Sorry to disagree once again, but auditing the reasons for access control
decisions isn't required by CAPP anywhere, see section 5.1.1.2 and table
1 for the exhaustive list of audit record requirements. It just needs to
record the success/failure result of the operation.
It's a matter of interpretation of 5.1.1.2 a) "... subject identity, ..."
LSPP adds a requirement that the "sensitivity labels of
subjects,
objects, or information involved" be included in each audit record
(that's the MAC information), this does not include any DAC information
such as group membership or ACLs.
I don't think it's reasonable to expect to track which bit let you
access the file, but it is reasonble to consider dumping the 'subject
identity' as defined by uid's, gid's (including supplemental groups),
capabilities (and with LSPP clearly labels).
I agree that having this type of information in the audit records
would
be useful, but doing it right would need many changes to the OS and goes
beyond what CAPP/LSPP require.
It's simple to add the info without including which allowed you to access
the object. I agree, we aren't going to track which key let you in.
Capabilities are different, this could be considered to be covered by
the
"use of the rights of a role" requirement for FMT_SMR.1. The existing
Linux security targets had not made any fine-grained role distinctions
based on capabilities, they have used the simplified "administrator ==
UID 0 == all capabilities" model which makes it sufficient to record the
effective UID. If you have an ST that identifies distinct roles based on
individual capability bits, you would need to audit the current
capabilities of the process. Note that the audit requirement for CAPP and
LSPP is that "the role and the origin of the request" be included in the
record.
Already some userspace apps drop capabilities.
thanks,
-chris
--
Linux Security Modules http://lsm.immunix.org http://lsm.bkbits.net
11:42 a.m.
On Wed, Feb 23, 2005 at 09:07:31AM -0800, Chris Wright wrote:
* Klaus Weidner (klaus(a)atsec.com) wrote:
> Sorry to disagree once again, but auditing the reasons for access control
> decisions isn't required by CAPP anywhere, see section 5.1.1.2 and table
> 1 for the exhaustive list of audit record requirements. It just needs to
> record the success/failure result of the operation.
It's a matter of interpretation of 5.1.1.2 a) "... subject identity, ..."
Since "subjects" are defined to be processes (running on behalf of
users), I'd consider them to be identified by the PID, and the security
attributes would be properties of the process but not part of the
identity. (A privileged process may change its own security properties,
and I'd think it would be weird if that would correspond to a change of
identity for that process.)
> I agree that having this type of information in the audit
records would
> be useful, but doing it right would need many changes to the OS and goes
> beyond what CAPP/LSPP require.
It's simple to add the info without including which allowed you to access
the object. I agree, we aren't going to track which key let you in.
Agreed, including that information would be useful, even if CAPP doesn't
directly require it.
Already some userspace apps drop capabilities.
Okay, but it's only security relevant from the CC point of view if the
security target actually makes a distinction based on capabilities.
Voluntarily giving up rights isn't interesting if you don't make claims
that this increases security. Adding additional capabilities would be
security relevant, but currently this simply causes the application to be
considered a trusted process, same as a standard suid root process.
-Klaus
11:52 a.m.
* Klaus Weidner (klaus(a)atsec.com) wrote:
On Wed, Feb 23, 2005 at 09:07:31AM -0800, Chris Wright wrote:
> * Klaus Weidner (klaus(a)atsec.com) wrote:
> > Sorry to disagree once again, but auditing the reasons for access control
> > decisions isn't required by CAPP anywhere, see section 5.1.1.2 and table
> > 1 for the exhaustive list of audit record requirements. It just needs to
> > record the success/failure result of the operation.
>
> It's a matter of interpretation of 5.1.1.2 a) "... subject identity,
..."
Since "subjects" are defined to be processes (running on behalf of
users), I'd consider them to be identified by the PID, and the security
attributes would be properties of the process but not part of the
identity. (A privileged process may change its own security properties,
and I'd think it would be weird if that would correspond to a change of
identity for that process.)
OK, I had always considered security attributes to be part of the
identity. Thanks for clarification.
> > I agree that having this type of information in the audit
records would
> > be useful, but doing it right would need many changes to the OS and goes
> > beyond what CAPP/LSPP require.
>
> It's simple to add the info without including which allowed you to access
> the object. I agree, we aren't going to track which key let you in.
Agreed, including that information would be useful, even if CAPP doesn't
directly require it.
Well, let's see if there's any trouble with dumping them (since they are
variable length).
> Already some userspace apps drop capabilities.
Okay, but it's only security relevant from the CC point of view if the
security target actually makes a distinction based on capabilities.
Voluntarily giving up rights isn't interesting if you don't make claims
that this increases security. Adding additional capabilities would be
security relevant, but currently this simply causes the application to be
considered a trusted process, same as a standard suid root process.
Ah OK, that makes sense.
thanks,
-chris
--
Linux Security Modules http://lsm.immunix.org http://lsm.bkbits.net
3:27 p.m.
--- Chris Wright <chrisw(a)osdl.org> wrote:
* Klaus Weidner (klaus(a)atsec.com) wrote:
...
> Since "subjects" are defined to be processes
(running on behalf of
> users), I'd consider them to be identified by the
PID, and the security
> attributes would be properties of the process but
not part of the
> identity. (A privileged process may change its own
security properties,
> and I'd think it would be weird if that would
correspond to a change of
> identity for that process.)
OK, I had always considered security attributes to
be part of the
identity. Thanks for clarification.
This audit trail does not contain sufficient
information to identify what security policy
was enforced on failure, nor does it provide
sufficient information to demonstrate an access
was in fact appropriate.
This may be an audit trail, but it ain't a
security audit trail! The fact that an event
occurred without the information about the
subject and the object is not sufficient for
any analysis. What is the point of this
exercise? Without the subject and object
security attributes, especially those used
to make the access in question, what is this
good for?
=====
Casey Schaufler
casey(a)schaufler-ca.com
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
3:36 p.m.
* Casey Schaufler (casey(a)schaufler-ca.com) wrote:
--- Chris Wright <chrisw(a)osdl.org> wrote:
>
> OK, I had always considered security attributes to
> be part of the
> identity. Thanks for clarification.
This audit trail does not contain sufficient
information to identify what security policy
was enforced on failure, nor does it provide
sufficient information to demonstrate an access
was in fact appropriate.
It's CAPP vs. useful ;-)
This may be an audit trail, but it ain't a
security audit trail! The fact that an event
occurred without the information about the
subject and the object is not sufficient for
any analysis. What is the point of this
exercise? Without the subject and object
security attributes, especially those used
to make the access in question, what is this
good for?
Most of these things are there, we're just identifying what's missing.
I don't think anyone believes they aren't useful (however, we won't be
tracking which bit gave access, that'd have to be deduced).
thanks,
-chris
--
Linux Security Modules http://lsm.immunix.org http://lsm.bkbits.net
3:46 p.m.
--- Chris Wright <chrisw(a)osdl.org> wrote:
It's CAPP vs. useful ;-)
Then why bother?
> This may be an audit trail, but it ain't a
> security audit trail! The fact that an event
> occurred without the information about the
> subject and the object is not sufficient for
> any analysis. What is the point of this
> exercise? Without the subject and object
> security attributes, especially those used
> to make the access in question, what is this
> good for?
Most of these things are there, we're just
identifying what's missing.
I don't think anyone believes they aren't useful
(however, we won't be
tracking which bit gave access, that'd have to be
deduced).
Why not? Other systems do it. Dickins, even
MicroSoft can do that!
=====
Casey Schaufler
casey(a)schaufler-ca.com
__________________________________
Do you Yahoo!?
Take Yahoo! Mail with you! Get it on your mobile phone.
http://mobile.yahoo.com/maildemo
3:49 p.m.
* Casey Schaufler (casey(a)schaufler-ca.com) wrote:
--- Chris Wright <chrisw(a)osdl.org> wrote:
> It's CAPP vs. useful ;-)
Then why bother?
Point being, 1) make sure it's compliant, 2) while we're at it, make
sure it's useful (for reasonable pain threshold).
> > This may be an audit trail, but it ain't a
> > security audit trail! The fact that an event
> > occurred without the information about the
> > subject and the object is not sufficient for
> > any analysis. What is the point of this
> > exercise? Without the subject and object
> > security attributes, especially those used
> > to make the access in question, what is this
> > good for?
>
> Most of these things are there, we're just
> identifying what's missing.
> I don't think anyone believes they aren't useful
> (however, we won't be
> tracking which bit gave access, that'd have to be
> deduced).
Why not? Other systems do it. Dickins, even
MicroSoft can do that!
Because it's a disruptive change that exceeds that pain threshold.
thanks,
-chris
--
Linux Security Modules http://lsm.immunix.org http://lsm.bkbits.net
5:34 p.m.
On Wed, 23 Feb 2005 13:36:14 -0800, Chris Wright <chrisw(a)osdl.org> wrote:
* Casey Schaufler (casey(a)schaufler-ca.com) wrote:
> --- Chris Wright <chrisw(a)osdl.org> wrote:
<snip>
It's CAPP vs. useful ;-)
This is definately a concern of mine.
<snip>
--
- Timothy R. Chavez
7241
days inactive
7242
days old
linux-audit@lists.linux-audit.osci.io
13 comments
5 participants
participants (5)
-
Casey Schaufler -
Chris Wright -
Klaus Weidner -
Steve Grubb -
Timothy R. Chavez