12:22 a.m.
Alright,
Once again, thank you to Serge, Chris, and David for all the insight.
Here's the latest patch incorporating many of the changes you all
suggested. There are still some things missing and not fully tested
(for instance, the locking).
TODO:
* Make filesystem auditing enabled/disabled at runtime
* Re-add comments with proper DocBook formatting
* Remove Makefile changes
* Move struct audit_file to a slab cache
Am I forgetting something? (Soooo tired ;-))
I'd appreciate any and all comments / feedback. Thank you.
--
- Timothy R. Chavez
11:35 a.m.
Ah, disregard this one. I don't think this can be a problem :)
thanks,
-serge
Quoting Serge E. Hallyn (serue(a)us.ibm.com):
Also, you are not protecting
current->audit_context->watched
--
Linux-audit mailing list
Linux-audit(a)redhat.com
http://www.redhat.com/mailman/listinfo/linux-audit
11:40 a.m.
--- "Timothy R. Chavez" <chavezt(a)gmail.com> wrote:
I'd appreciate any and all comments / feedback.
Not bad. Couple of comments/questions:
+ /* The root directory cannot be watched */
+ if (!strcmp(path, "/")) {
+ ret = -EPERM;
+ goto audit_remove_watch_exit;
What are the implications regarding a chroot
environment? I can imagine (although it strikes
me as somewhat insane) an admin wanting to audit
everything that goes on in a chroot environment,
say for a honeypot. The watching would have to
be enabled from outside. Not a bad thing, but is
it what you want?
+/* The structure that stores information about
files/directories being
+ * watched in the filesystem, that the syscall
accessed.
+ */
+
+struct audit_file {
+ struct audit_watch *watch;
+ struct list_head list;
+ unsigned long ino;
+ umode_t mode;
+ uid_t uid;
+ gid_t gid;
+ dev_t rdev;
+ int mask;
+};
Where does one put the ACL, MAC label, and/or
capability set of the file? I may not be able
to go get it later, as it may change or worse,
the file might be gone by then.
=====
Casey Schaufler
casey(a)schaufler-ca.com
__________________________________
Do you Yahoo!?
Yahoo! Mail - Helps protect you from nasty viruses.
http://promotions.yahoo.com/new_mail
11:58 a.m.
On Tue, 25 Jan 2005 09:40:00 PST, Casey Schaufler said:
What are the implications regarding a chroot
environment? I can imagine (although it strikes
me as somewhat insane) an admin wanting to audit
everything that goes on in a chroot environment,
say for a honeypot. The watching would have to
be enabled from outside. Not a bad thing, but is
it what you want?
Well, from where I'm sitting, *if* you buy into the idea of
a honeypot as being sane, you *definitely* want to be able
to enable auditing from "outside".
12:11 p.m.
--- Valdis.Kletnieks(a)vt.edu wrote:
On Tue, 25 Jan 2005 09:40:00 PST, Casey Schaufler
said:
> What are the implications regarding a chroot
> environment? I can imagine (although it strikes
> me as somewhat insane) an admin wanting to audit
> everything that goes on in a chroot environment,
> say for a honeypot. The watching would have to
> be enabled from outside. Not a bad thing, but is
> it what you want?
Well, from where I'm sitting, *if* you buy into the
idea of
a honeypot as being sane, you *definitely* want to
be able
to enable auditing from "outside".
Clearly. Are there any cases where it makes
sense for it to be done from inside? If not,
looking at "/" might be fine.
=====
Casey Schaufler
casey(a)schaufler-ca.com
__________________________________
Do you Yahoo!?
Read only the mail you want - Yahoo! Mail SpamGuard.
http://promotions.yahoo.com/new_mail
12:29 p.m.
On Tue, 25 Jan 2005 09:40:00 -0800 (PST), Casey Schaufler
<casey(a)schaufler-ca.com> wrote:
--- "Timothy R. Chavez" <chavezt(a)gmail.com> wrote:
> I'd appreciate any and all comments / feedback.
Not bad. Couple of comments/questions:
> + /* The root directory cannot be watched */
> + if (!strcmp(path, "/")) {
> + ret = -EPERM;
> + goto audit_remove_watch_exit;
What are the implications regarding a chroot
environment? I can imagine (although it strikes
me as somewhat insane) an admin wanting to audit
everything that goes on in a chroot environment,
say for a honeypot. The watching would have to
be enabled from outside. Not a bad thing, but is
it what you want?
To be honest, I haven't really considered the chroot environment. I
guess the check really needs to be after the lookup and I should
check:
if(nd.dentry == nd.dentry->d_parent) {
return -EPERM;
....
}
The reason for this is simple. You can't watch yourself. Is this a problem?
> +/* The structure that stores information about
files/directories being
> + * watched in the filesystem, that the syscall
accessed.
> + */
> +
> +struct audit_file {
> + struct audit_watch *watch;
> + struct list_head list;
> + unsigned long ino;
> + umode_t mode;
> + uid_t uid;
> + gid_t gid;
> + dev_t rdev;
> + int mask;
> +};
Where does one put the ACL, MAC label, and/or
capability set of the file? I may not be able
to go get it later, as it may change or worse,
the file might be gone by then.
I've not given this any thought. This is on the table and needs to
furthered discussed. Klaus?
=====
Casey Schaufler
casey(a)schaufler-ca.com
__________________________________
Do you Yahoo!?
Yahoo! Mail - Helps protect you from nasty viruses.
http://promotions.yahoo.com/new_mail
--
- Timothy R. Chavez
12:51 p.m.
--- "Timothy R. Chavez" <chavezt(a)gmail.com> wrote:
To be honest, I haven't really considered the chroot
environment. I
guess the check really needs to be after the lookup
and I should
check:
if(nd.dentry == nd.dentry->d_parent) {
return -EPERM;
....
}
I thought that might be what you really meant.
The reason for this is simple. You can't watch
yourself. Is this a problem?
No worries.
> Where does one put the ACL, MAC label, and/or
> capability set of the file? I may not be able
> to go get it later, as it may change or worse,
> the file might be gone by then.
I've not given this any thought. This is on the
table and needs to
furthered discussed. Klaus?
A field that is the head of a list of
additional "information units" (tokens
in other systems) would be most general.
=====
Casey Schaufler
casey(a)schaufler-ca.com
__________________________________
Do you Yahoo!?
Read only the mail you want - Yahoo! Mail SpamGuard.
http://promotions.yahoo.com/new_mail
2:24 p.m.
> Not bad. Couple of comments/questions:
>
> > + /* The root directory cannot be watched */
> > + if (!strcmp(path, "/")) {
> > + ret = -EPERM;
> > + goto audit_remove_watch_exit;
>
> What are the implications regarding a chroot
> environment? I can imagine (although it strikes
> me as somewhat insane) an admin wanting to audit
> everything that goes on in a chroot environment,
> say for a honeypot. The watching would have to
> be enabled from outside. Not a bad thing, but is
> it what you want?
To be honest, I haven't really considered the chroot environment. I
guess the check really needs to be after the lookup and I should
check:
if(nd.dentry == nd.dentry->d_parent) {
return -EPERM;
....
}
The reason for this is simple. You can't watch yourself. Is this a problem?
But you're looking up the parent of the file. So if you call
audit_insert_watch("/.autofsck"); then nd will be the nameidata for
'/'.
You're going to check that the parent is not '/', whereas before you
were checking that the file is not '/'. Clearly you want the latter.
That's not to say the strcmp(path, "/') will be acceptable upstream,
though.
-serge
--
Serge Hallyn <serue(a)us.ibm.com>
1:20 p.m.
* Serge Hallyn (serue(a)us.ibm.com) wrote:
But you're looking up the parent of the file. So if you call
audit_insert_watch("/.autofsck"); then nd will be the nameidata for
'/'.
You're going to check that the parent is not '/', whereas before you
were checking that the file is not '/'. Clearly you want the latter.
That's not to say the strcmp(path, "/') will be acceptable upstream,
though.
No, it's not. It also doesn't mean much. Think "///", or
"../../../".
These are user strings. If it's an issue, better compare against
something sane like resolved internal data structure.
thanks,
-chris
--
Linux Security Modules http://lsm.immunix.org http://lsm.bkbits.net
2:50 p.m.
Right, so I guess the correct check will involve perhaps checking
nd.last!=NULL before d_lookup, or dentry != nd.dentry after the
d_lookup?
(I don't know offhand what nd.last looks like if you looked up '/'.)
-serge
On Tue, 2005-01-25 at 11:20 -0800, Chris Wright wrote:
* Serge Hallyn (serue(a)us.ibm.com) wrote:
> But you're looking up the parent of the file. So if you call
> audit_insert_watch("/.autofsck"); then nd will be the nameidata for
'/'.
> You're going to check that the parent is not '/', whereas before you
> were checking that the file is not '/'. Clearly you want the latter.
>
> That's not to say the strcmp(path, "/') will be acceptable upstream,
> though.
No, it's not. It also doesn't mean much. Think "///", or
"../../../".
These are user strings. If it's an issue, better compare against
something sane like resolved internal data structure.
thanks,
-chris
--
Serge Hallyn <serue(a)us.ibm.com>
1:42 p.m.
* Serge Hallyn (serue(a)us.ibm.com) wrote:
Right, so I guess the correct check will involve perhaps checking
nd.last!=NULL before d_lookup, or dentry != nd.dentry after the
d_lookup?
(I don't know offhand what nd.last looks like if you looked up '/'.)
Should depend on how you got their I think. "/" vs. "../../../../.."
thanks,
-chris
--
Linux Security Modules http://lsm.immunix.org http://lsm.bkbits.net
2:34 p.m.
On Tue, 2005-01-25 at 12:29 -0600, Timothy R. Chavez wrote:
To be honest, I haven't really considered the chroot environment.
I
guess the check really needs to be after the lookup and I should
check:
It's not just chroot. Remember that every task in the system can in
theory have an entirely different namespace, with different file systems
mounted at different places.
--
dwmw2
3:25 p.m.
David,
Can you ellaborate on why you think namespaces are an issue? I'm
having a hard time understanding why this would be any more of a
problem then any other intentional subversion of the audit subsystem
by the administrator (where administrator == root). Perhaps there is
a way for a user process to subvert the audit subsystem using
namespace trickory?
If the root user issues a "watch /etc/passwd" it will resolve to the
inode for passwd in the given namespace. Any accesses on that inode,
in that namespace (presumably the only access we care about), by an
audited syscall will be noted and sent to userspace. Isn't that
sufficient?
On Tue, 25 Jan 2005 20:34:04 +0000, David Woodhouse <dwmw2(a)infradead.org> wrote:
On Tue, 2005-01-25 at 12:29 -0600, Timothy R. Chavez wrote:
> To be honest, I haven't really considered the chroot environment. I
> guess the check really needs to be after the lookup and I should
> check:
It's not just chroot. Remember that every task in the system can in
theory have an entirely different namespace, with different file systems
mounted at different places.
--
dwmw2
--
- Timothy R. Chavez
3:37 p.m.
On Tue, 2005-01-25 at 15:25 -0600, Timothy R. Chavez wrote:
Can you ellaborate on why you think namespaces are an issue?
I'm
having a hard time understanding why this would be any more of a
problem then any other intentional subversion of the audit subsystem
by the administrator (where administrator == root). Perhaps there is
a way for a user process to subvert the audit subsystem using
namespace trickory?
I'm not sure it's a _problem_ but I just wanted to make sure you bear it
in mind.
If the root user issues a "watch /etc/passwd" it will
resolve to the
inode for passwd in the given namespace. Any accesses on that inode,
in that namespace (presumably the only access we care about), by an
audited syscall will be noted and sent to userspace. Isn't that
sufficient?
Possibly; as long as the owner of the namespace can't mount the file
system containing it elsewhere, or 'mount --bind /etc /tmp/x' and get
round the watch. Your method of attaching to the dentry looks like it
works correctly in that case, but again I wanted to be sure it's by
design, and it stays that way.
--
dwmw2
5:29 p.m.
On Tue, 2005-01-25 at 21:37 +0000, David Woodhouse wrote:
Possibly; as long as the owner of the namespace can't mount the
file
system containing it elsewhere, or 'mount --bind /etc /tmp/x' and get
round the watch. Your method of attaching to the dentry looks like it
works correctly in that case, but again I wanted to be sure it's by
design, and it stays that way.
Yup, we've definately been keeping that in mind. And the ramifications
can get subtle, so please do let us know if you find a case we
overlooked. But as it stands, every meaningful case seems to be
handled:
watch /etc/passwd
chroot_ns /mnt/d6
touch /etc/passwd
that /etc/passwd is /mnt/d6/etc/passwd, so we don't care.
watch /etc/passwd
mount --bind /etc /mnt/d6/etc
chroot_ns /mnt/d6
touch /etc/passwd
since /mnt/d6/etc is in fact /etc, we will have the right watch list,
and /mnt/d6/etc/passwd will be watched.
watch /etc/passwd
touch /mtn/d6/etc/passwd
mount --bind /etc/passwd /mnt/d6/etc/passwd
chroot_ns /mnt/d6
touch /etc/passwd
(audited)
rm /etc/passwd
(audited)
touch /etc/passwd
(new file is *not* watched)
By the way, Tim, please test each case that I've mentioned here :) I'm
just saying our design should cover them. Please make sure!
thanks,
-serge
--
Serge Hallyn <serue(a)us.ibm.com>
4:46 p.m.
On Tue, 2005-01-25 at 15:25 -0600, Timothy R. Chavez wrote:
Any accesses on that inode,
in that namespace (presumably the only access we care about), by an
audited syscall will be noted and sent to userspace. Isn't that
sufficient?
Not quite right: Any access to that inode from any namespace. Another
namespace might simply mean that you have a different path to the inode.
--
Serge Hallyn <serue(a)us.ibm.com>
3:44 p.m.
On Tue, 25 Jan 2005 16:46:54 -0600, Serge Hallyn <serue(a)us.ibm.com> wrote:
On Tue, 2005-01-25 at 15:25 -0600, Timothy R. Chavez wrote:
> Any accesses on that inode,
> in that namespace (presumably the only access we care about), by an
> audited syscall will be noted and sent to userspace. Isn't that
> sufficient?
Not quite right: Any access to that inode from any namespace. Another
namespace might simply mean that you have a different path to the inode.
Alright, I see better now the concern. But because the audit
information is associated with the inode via an administrator action,
it still remains true that any access to that inode will be caught,
from any namespace. Correct?
I guess the assumption here is that the administrator knows that
he/she is in the right namespace when adding/removing watches so that
they tag the appropriate inodes.
--
Serge Hallyn <serue(a)us.ibm.com>
--
- Timothy R. Chavez
5:14 p.m.
On Tue, 2005-01-25 at 15:44 -0600, Timothy R. Chavez wrote:
On Tue, 25 Jan 2005 16:46:54 -0600, Serge Hallyn
<serue(a)us.ibm.com> wrote:
> On Tue, 2005-01-25 at 15:25 -0600, Timothy R. Chavez wrote:
> > Any accesses on that inode,
> > in that namespace (presumably the only access we care about), by an
> > audited syscall will be noted and sent to userspace. Isn't that
> > sufficient?
>
> Not quite right: Any access to that inode from any namespace. Another
> namespace might simply mean that you have a different path to the inode.
>
Alright, I see better now the concern. But because the audit
information is associated with the inode via an administrator action,
it still remains true that any access to that inode will be caught,
from any namespace. Correct?
Exactly.
I guess the assumption here is that the administrator knows that
he/she is in the right namespace when adding/removing watches so that
they tag the appropriate inodes.
Exactly.
--
Serge Hallyn <serue(a)us.ibm.com>
8:09 p.m.
--- "Timothy R. Chavez" <chavezt(a)gmail.com> wrote:
Alright, I see better now the concern. But because
the audit
information is associated with the inode via an
administrator action,
it still remains true that any access to that inode
will be caught,
from any namespace. Correct?
Okay so far. Let's use an example other than
/etc/passwd. Let's say the admin wants to watch
/home/casey/viruses.
# watch /home/casey/viruses/deadly37
Casey, expecting that they're on to him,
casey% mv viruses fuzzybunnys
This is still good from an object standpoint
the object the admin tagged is still being
audited. I think your code will continue to
report this as "/home/casey/viruses/deadly37".
casey% mkdir viruses
casey% echo "Would be wrong." > viruses/deadly37
At this point you won't be seeing what you
probably expect in the audit trail, no trusted
administrator has to be tricked, and everything
was legal. You can't detect it directly either
as the inode you are watching isn't involved
in the process. If the audit record includes
the path that you tagged as well as the path that
you use to access the file you're going to be
okay as you'll be able to distinguish the current
viruses/deadly37 from the current
fuzzybunnys/deadly37 that was once called
viruses/deadly37.
=====
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:28 p.m.
On Tue, 25 Jan 2005 18:09:12 -0800 (PST), Casey Schaufler
<casey(a)schaufler-ca.com> wrote:
--- "Timothy R. Chavez" <chavezt(a)gmail.com> wrote:
> Alright, I see better now the concern. But because
> the audit
> information is associated with the inode via an
> administrator action,
> it still remains true that any access to that inode
> will be caught,
> from any namespace. Correct?
Okay so far. Let's use an example other than
/etc/passwd. Let's say the admin wants to watch
/home/casey/viruses.
# watch /home/casey/viruses/deadly37
Casey, expecting that they're on to him,
casey% mv viruses fuzzybunnys
This is still good from an object standpoint
the object the admin tagged is still being
audited. I think your code will continue to
report this as "/home/casey/viruses/deadly37".
Ok, if you're watching /home/casey/viruses and you mv/rename()
viruses/ to fuzzybunnys/, you will lose the watch. The way it works
is that the administrator specifies specific paths and if we leave
such a path, we're no longer audited.
Also, when we watch /home/case/viruses/, it's important to note that
we are not watching anything within viruses/ and that access to
files/directories within viruses/ do not necessarly "pass through"
viruses/. So, if we do "cat /home/casey/viruses/deadly37" no audit
record for "viruses/" would be generated and recorded.
casey% mkdir viruses
casey% echo "Would be wrong." > viruses/deadly37
At this point you won't be seeing what you
probably expect in the audit trail, no trusted
administrator has to be tricked, and everything
was legal. You can't detect it directly either
as the inode you are watching isn't involved
in the process. If the audit record includes
the path that you tagged as well as the path that
you use to access the file you're going to be
okay as you'll be able to distinguish the current
viruses/deadly37 from the current
fuzzybunnys/deadly37 that was once called
viruses/deadly37.
You're right, if that directory were renamed, and a new one created,
the new directory would be auditable, and the one you were interested
in would not. But, really... the user could also DoS the system in a
CAPP environment (can't use the rate limit). I guess what this boils
down to is requirement. As far as I know, for this type of
certification, monitoring a user isn't the goal of file system
auditing, but rather, we're trying to validate and verify the kernel's
response/reaction to stimulus/action within the filesystem.
=====
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
--
- Timothy R. Chavez
10:44 a.m.
--- "Timothy R. Chavez" <chavezt(a)gmail.com> wrote:
Ok, if you're watching /home/casey/viruses and you
mv/rename()
viruses/ to fuzzybunnys/, you will lose the watch.
That is not what I would expect from an object
standpoint. I specified the object that I wanted
to watch and the rename did not change the object.
The way it works
is that the administrator specifies specific paths
and if we leave
such a path, we're no longer audited.
For this argument to make sense you would have to
keep an eye out /home/casey/viruses reappearing
in the namespace and marking it for audit.
casey% mv viruses fuzzybunnys
casey% mv fuzzybunnys viruses
should not disassociate the audit watch.
You're right, if that directory were renamed, and a
new one created,
the new directory would be auditable, and the one
you were interested
in would not. But, really... the user could also
DoS the system in a
CAPP environment (can't use the rate limit). I
guess what this boils
down to is requirement. As far as I know, for this
type of
certification, monitoring a user isn't the goal of
file system
auditing, but rather, we're trying to validate and
verify the kernel's
response/reaction to stimulus/action within the
filesystem.
Make no mistake. The stated and genuine purpose
of an audit trail is to track the changes to the
security state of the system and the access control
decisions made by the system. This requires that
it be 100% unambiguous what it means to specify
a watched object. The issue here is that the
file system name space you are using to specify
what object to watch can be changed within the
system security policy by unprivileged users in
such a way as to disassociate the watch. Your
mechanism is unreliable.
If, on the other hand, you said
# watch dev=8,9 inode=8776
that would be reliable, unambiguous, and
painful.
If you want to audit by pathname attaching
the audit watch to the inode is not right
because the two are not connected in any
real way.
=====
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
12:20 p.m.
On Wed, 2005-01-26 at 08:44 -0800, Casey Schaufler wrote:
--- "Timothy R. Chavez" <chavezt(a)gmail.com> wrote:
> Ok, if you're watching /home/casey/viruses and you
> mv/rename()
> viruses/ to fuzzybunnys/, you will lose the watch.
That is not what I would expect from an object
standpoint. I specified the object that I wanted
to watch and the rename did not change the object.
In the case of shadow all you care about is the new object. You have a
log entry saying that the object was moved, now you wait for a new one
to be created. You care about who is writing to the pathname which will
be used for authentication.
The case you're mentioning is when we're more concerned about protecting
the data itself. We've talked about supporting this, but it would have
to be very clear to the user which type of audit watch is being
requested. One of the main reasons we've not addressed the issue yet is
because in order for this type of tracking to survive a reboot, we would
have to either make use of extended attributes, or have the kernel
append to the list of audit rules stored in the config file. The latter
is clearly unacceptable, and the former would be nice to avoid if
possible.
Make no mistake. The stated and genuine purpose
of an audit trail is to track the changes to the
security state of the system and the access control
decisions made by the system.
Yes, and so when we know that login will check whatever object happens
to be located at /etc/shadow, then the object which can be reached
through /etc/shadow, whatever dentry it was actually reached through,
must be audited.
Note that the case you mention of
mv filename tempfile
mv tempfile filename
would result in filename being audited again after the second mv under
the current behavior. But any access to tempfile between the two moves
would not be audited.
(At least this is the intent. I'm not yet convinced that renames and
unlinks are all currently correctly handled, only because I haven't had
time to look for that yet)
This requires that
it be 100% unambiguous what it means to specify
a watched object.
Absolutely.
# watch dev=8,9 inode=8776
that would be reliable, unambiguous, and
painful.
Reliable depends on what you're trying to accomplish. It would be
worthless for the shadow case, because after the next run of passwd,
inode 8776 is no longer useful.
If you want to audit by pathname attaching
the audit watch to the inode is not right
because the two are not connected in any
real way.
Attaching to the inode is necessary because it is the only way to catch
every access to the object attached to this dentry, regardless of which
dentry (in whatever namespace) was used to access the inode.
--
Serge Hallyn <serue(a)us.ibm.com>
10:18 p.m.
On Tue, 25 Jan 2005 22:28:40 CST, "Timothy R. Chavez" said:
Also, when we watch /home/case/viruses/, it's important to note
that
we are not watching anything within viruses/ and that access to
files/directories within viruses/ do not necessarly "pass through"
viruses/. So, if we do "cat /home/casey/viruses/deadly37" no audit
record for "viruses/" would be generated and recorded.
Umm... did you mean the case where 'deadly37' has more than one hard link
to it, and references via "the other path" won't trip?
(If it doesn't "pass through", why does 'chmod 0
/home/casey/viruses' do
anything? We do the filesystem perms check, possibly an ACL check if the
filesystem supports them, and even an LSM hook. So how can you go "through"
without getting an audit record?
11:42 p.m.
On Wed, 26 Jan 2005 23:18:56 -0500, Valdis.Kletnieks(a)vt.edu
<Valdis.Kletnieks(a)vt.edu> wrote:
--
- Timothy R. Chavez
On Tue, 25 Jan 2005 22:28:40 CST, "Timothy R. Chavez"
said:
> Also, when we watch /home/case/viruses/, it's important to note that
> we are not watching anything within viruses/ and that access to
> files/directories within viruses/ do not necessarly "pass through"
> viruses/. So, if we do "cat /home/casey/viruses/deadly37" no audit
> record for "viruses/" would be generated and recorded.
Umm... did you mean the case where 'deadly37' has more than one hard link
to it, and references via "the other path" won't trip?
Nope.
(If it doesn't "pass through", why does 'chmod 0
/home/casey/viruses' do
anything? We do the filesystem perms check, possibly an ACL check if the
filesystem supports them, and even an LSM hook. So how can you go "through"
without getting an audit record?
Unless, I was doing something wrong. When I tested a watch point on
both "/etc" and "passwd". When I issued a "cat /etc/passwd"
only a
record for "passwd" was generated. Then, when I did a "cat /etc", I
received a record for "etc" -- I was only recording open() syscalls,
however.
I didn't look into this behavior too much, but I will. Let me retest
this in the morning with the patch #2 (since the current code is kind
of broken right now *cough*) and send some results.
11:57 p.m.
On Wed, 26 Jan 2005 23:42:10 CST, "Timothy R. Chavez" said:
Unless, I was doing something wrong. When I tested a watch point on
both "/etc" and "passwd". When I issued a "cat
/etc/passwd" only a
record for "passwd" was generated. Then, when I did a "cat /etc", I
received a record for "etc" -- I was only recording open() syscalls,
however.
Ah.. Yes.. it won't call open() on /etc on the way to /etc/passwd.
There's OTHER places that you get hooks in that case.
Look around in fs/namei.c - link_path_walk ends up calling permission()
on each component of the path in turn - and permission() ends up doing all
the grunt work (file modes, ACLs, LSM, etc...)
12:19 a.m.
On Thu, 27 Jan 2005 00:57:03 -0500, Valdis.Kletnieks(a)vt.edu
<Valdis.Kletnieks(a)vt.edu> wrote:
--
- Timothy R. Chavez
On Wed, 26 Jan 2005 23:42:10 CST, "Timothy R. Chavez"
said:
> Unless, I was doing something wrong. When I tested a watch point on
> both "/etc" and "passwd". When I issued a "cat
/etc/passwd" only a
> record for "passwd" was generated. Then, when I did a "cat
/etc", I
> received a record for "etc" -- I was only recording open() syscalls,
> however.
Ah.. Yes.. it won't call open() on /etc on the way to /etc/passwd.
There's OTHER places that you get hooks in that case.
Look around in fs/namei.c - link_path_walk ends up calling permission()
on each component of the path in turn - and permission() ends up doing all
the grunt work (file modes, ACLs, LSM, etc...)
So then, in theory, when I do a "cat /etc/passwd" and both
"etc/" and
"passwd" are being watched and the open syscall() will generate an
audit record, I should see a record for both file system objects in
the audit log. For the open syscall(), there should be a message for
"etc" and "passwd", right? Because if I hit the permission() for
"etc" and "passwd" I should be adding both "etc" and
"passwd" to the
audit context for the open() because they are both being watched. I
was only getting a record for "passwd"
This will be the first thing I look at tommorow morning at work.
12:49 a.m.
On Thu, 27 Jan 2005 00:19:29 CST, "Timothy R. Chavez" said:
So then, in theory, when I do a "cat /etc/passwd" and both
"etc/" and
"passwd" are being watched and the open syscall() will generate an
audit record, I should see a record for both file system objects in
the audit log. For the open syscall(), there should be a message for
"etc" and "passwd", right? Because if I hit the permission() for
"etc" and "passwd" I should be adding both "etc" and
"passwd" to the
audit context for the open() because they are both being watched. I
was only getting a record for "passwd"
Take care that you don't indiscriminately add entries for /etc to the audit
context for files you don't care about. If you have a /etc/we_dont_care,
you may fill up your audit trail for lots of bogus traces of /etc.
For that matter, so much stuff opens /etc/passwd in R/O mode (like every single
program that uses getpwent()) that auditing it is probably a Bad Idea on most
systems (unless it's an embedded box where you've hunted down all the getpwent()
callers already ;) So you need to make sure that your code doesn't attach
the /etc message unless the next path component is "passwd" *and* it's
something
other than R/O. Unfortunately, permission() really only has access to *this*
component of the pathname, so what you may have to do is just save a bit somewhere
saying "we went through /etc", and actually attach it when you're looking
at
the next component and decide it's something hinky enough to require an audit
record....
(If this stuff was easy, we'd have done it a decade ago.. ;)
2:54 p.m.
Hi Tim,
One more thing. Pay attention to your usage of
list_for_each_entry_safe. I believe you want to use it every time you
iterate over an audit_file->watchlist. You use list_for_each_entry for
one of those in audit_fetch_watch, but then use _safe while walking over
context->watched during audit_free_files, when I don't think you need
to.
--
Serge Hallyn <serue(a)us.ibm.com>
7:59 a.m.
On Tue, 2005-01-25 at 01:22, Timothy R. Chavez wrote:
Once again, thank you to Serge, Chris, and David for all the insight.
Here's the latest patch incorporating many of the changes you all
suggested. There are still some things missing and not fully tested
(for instance, the locking).
TODO:
* Make filesystem auditing enabled/disabled at runtime
* Re-add comments with proper DocBook formatting
* Remove Makefile changes
* Move struct audit_file to a slab cache
Am I forgetting something? (Soooo tired ;-))
I'd appreciate any and all comments / feedback. Thank you.
Very minor nit: Define a static inline for audit_inode_alloc() and use
it in alloc_inode(), and eliminate the #ifdef's there (and in
destroy_inode). You can just define them to the empty function in your
header file if the config option isn't set. Also, static inlines are
preferred to macros because they apply type checking even when the
option is disabled. Documentation/SubmittingPatches, Section 2.
--
Stephen Smalley <sds(a)epoch.ncsc.mil>
National Security Agency
12:44 p.m.
Very minor nit: Define a static inline for audit_inode_alloc() and
use
it in alloc_inode(), and eliminate the #ifdef's there (and in
destroy_inode). You can just define them to the empty function in your
header file if the config option isn't set. Also, static inlines are
preferred to macros because they apply type checking even when the
option is disabled. Documentation/SubmittingPatches, Section 2.
Stephen,
I personally think this is a better way of doing it. I'll make the
change barring any objections from Chris, David, or Serge. The
audit_inode_alloc() will only allocate space for an inode its
associated with a "watched" location.
--
Stephen Smalley <sds(a)epoch.ncsc.mil>
National Security Agency
--
- Timothy R. Chavez
1:04 p.m.
On Thu, 27 Jan 2005 12:44:51 -0600, Timothy R. Chavez <chavezt(a)gmail.com> wrote:
> Very minor nit: Define a static inline for audit_inode_alloc()
and use
> it in alloc_inode(), and eliminate the #ifdef's there (and in
> destroy_inode). You can just define them to the empty function in your
> header file if the config option isn't set. Also, static inlines are
> preferred to macros because they apply type checking even when the
> option is disabled. Documentation/SubmittingPatches, Section 2.
>
Stephen,
I personally think this is a better way of doing it. I'll make the
change barring any objections from Chris, David, or Serge. The
audit_inode_alloc() will only allocate space for an inode its
associated with a "watched" location.
> --
> Stephen Smalley <sds(a)epoch.ncsc.mil>
> National Security Agency
>
Then again, now that I think about this a little more... This won't
work. With only the inode, I'll have to automatically allocate space
for i_audit regardless of whether or not its being watched. There's
no way, at this level (and time), to infer whether or not the inode is
associated with a "watched" location. Is this acceptable? To
allocate every inode->i_audit if filesystem auditing is enabled?
Currently, we're at 28 bytes of data (1 pointer (4 bytes), 1 rw_lock
(8 bytes?), and 2 list_heads (16 bytes?). I suppose if I allocate
every inode though, I can reduce the size of audit_data by 1 list_head
because I can get rid of the list that uses it. By doing blanket
allocations it does reduce the complexity some of the code, currently.
>
--
- Timothy R. Chavez
--
- Timothy R. Chavez
1:04 p.m.
On Thu, 2005-01-27 at 14:04, Timothy R. Chavez wrote:
Then again, now that I think about this a little more... This
won't
work. With only the inode, I'll have to automatically allocate space
for i_audit regardless of whether or not its being watched.
I wasn't suggesting allocating the data there. I just saying that you
need to remove the #ifdef's from alloc_inode and destroy_inode and
replace them with unconditional calls to static inline functions, which
in turn can be defined away to nothing if the config option is disabled,
per Documentation/SubmittingPatches section 2. No real change in the
code, just avoiding #ifdefs in fs/inode.c.
--
Stephen Smalley <sds(a)epoch.ncsc.mil>
National Security Agency
10:16 p.m.
Hello,
First, a note on previous discussion..
So I was just fixing a bug and I took a look at why I wasn't
generating a record for both "etc" and "passwd" if they were both
being watched and I issued a "cat /etc/paswd"
When I took a look, I saw that permission() isn't called on "etc", but
instead exec_permission_lite() is. Once I hooked this function, I got
the expected audit records for both "etc" and "passwd"
I will release patch #3 most likely tommorow which addresses comments,
bugs, etc on patch #2. I've yet to talk to Chris about the possible
bug he sees in d_move(), but hope to resolve that soon and have any
needed changes in patch #4.
Patch #4 will mostly introduce new features (and include any bug
fixes, comments, nits on patch #3). Primarily the ability to
enable/disable the filesystem auditing dynamically (from userspace),
attaching a permissions bitmask to watch points, and a revision on the
audit_data preallocation mechanism. I also hope to be able to release
a usespace patch to auditctl so that the code can be functionally
tested by people other then myself.
Thanks all!
8:09 a.m.
On Tue, 2005-01-25 at 01:22, Timothy R. Chavez wrote:
Alright,
Once again, thank you to Serge, Chris, and David for all the insight.
Here's the latest patch incorporating many of the changes you all
suggested. There are still some things missing and not fully tested
(for instance, the locking).
TODO:
* Make filesystem auditing enabled/disabled at runtime
* Re-add comments with proper DocBook formatting
* Remove Makefile changes
* Move struct audit_file to a slab cache
Am I forgetting something? (Soooo tired ;-))
I'd appreciate any and all comments / feedback. Thank you.
Possibly I missed earlier discussion of this issue, but I would have
expected an audit watch to have an associated permission mask (i.e. I
only want to watch for writes to /etc/passwd, not reads), and have
audit_notify_watch() only add a entry to the audit context if the audit
watch mask has a non-zero intersection with the requested permission
mask. Otherwise, you will be generating a ton of useless entries.
--
Stephen Smalley <sds(a)epoch.ncsc.mil>
National Security Agency
8:19 a.m.
On Thu, 2005-01-27 at 09:09, Stephen Smalley wrote:
Possibly I missed earlier discussion of this issue, but I would have
expected an audit watch to have an associated permission mask (i.e. I
only want to watch for writes to /etc/passwd, not reads), and have
audit_notify_watch() only add a entry to the audit context if the audit
watch mask has a non-zero intersection with the requested permission
mask. Otherwise, you will be generating a ton of useless entries.
I suppose one exception to the above logic is if the mask specified for
the audit watch itself is 0, then you should always add the entry
regardless of the requested permission mask, so that you can audit even
existence tests (i.e. access(path, F_OK)) of the file if desired. So
legitimate masks might be 0 (audit all accesses, even existence tests)
or any combination of MAY_READ, MAY_WRITE, MAY_EXEC, and MAY_APPEND
(audit only the specified kind of accesses).
--
Stephen Smalley <sds(a)epoch.ncsc.mil>
National Security Agency
7266
days inactive
7270
days old
linux-audit@lists.linux-audit.osci.io
36 comments
8 participants
participants (8)
-
Casey Schaufler -
Chris Wright -
David Woodhouse -
Serge E. Hallyn -
Serge Hallyn
-
Stephen Smalley -
Timothy R. Chavez -
Valdis.Kletnieks＠vt.edu