2:56 p.m.
Hello,
This patch introduces fixes for:
1. sys_rename() return code debacle
->
as a side effect of removing the error handling from fs/namei.c this bug was
also removed
2. leaky memory in auditfs_attach_wdata in failure path
3. NULL dereference on audit_inode_free()
->
race could occur between the child inode being deleted and the watch being
removed from parent
This patch adds:
1. Implicit watc removal message with -1 loginuid
2. New type, AUDIT_FS_INODE (1308)
->
now that we have watches per inode per record, we collect common inode
information for the watch on AUDIT_FS_INODE and use AUDIT_FS_WATCH to list
the watch information
3. Minor code cleanups (eliminating pointless goto's)
What's left:
1. Hooking chmod/chown/chgrp and the appropriate ACL calls (Me)
2. Watch scalability problem (Me)
3. AUID filtering on USER messages and watches (David)
4. PATH record woes... add a new token stating "I'm the parent of the file or
I'm the file"
-tim
3:06 p.m.
On Wednesday 15 June 2005 15:56, Timothy R. Chavez wrote:
4. PATH record woes... add a new token stating "I'm the
parent of the file
or I'm the file"
If we are required to emit a record for the file and you add a label saying
its the directory...don't we still need to dig up the file's attributes? I
think labeling it makes the mode clear to what it belongs to, but the intent
was to provide a record with the *correct* attributes for the object. I
think that in the case where we have a mismatch, the code needs to go dig up
the correct mode of the file instead of "getting it for free".
-Steve
3:36 p.m.
On Wednesday 15 June 2005 15:06, Steve Grubb wrote:
On Wednesday 15 June 2005 15:56, Timothy R. Chavez wrote:
> 4. PATH record woes... add a new token stating "I'm the parent of the
file
> or I'm the file"
If we are required to emit a record for the file and you add a label saying
its the directory...don't we still need to dig up the file's attributes? I
think labeling it makes the mode clear to what it belongs to, but the intent
was to provide a record with the *correct* attributes for the object. I
think that in the case where we have a mismatch, the code needs to go dig up
the correct mode of the file instead of "getting it for free".
Well, its intuitive that the information being reported is the parent's information
and not the childs in these certain cases. But you have to understand how the
system call works and I think that's where the real problem lies. To do what you
suggest would/could get quite ugly I think. We can already get all this info from
watching the child...
Rik's hook can only give back the _relevant_ information the system call was able
to use when deciding its courses of action. In some cases that's the parent and
in others it's the child.
I think we're abusing the original purpose of the hook.
-tim
-Steve
--
Linux-audit mailing list
Linux-audit(a)redhat.com
http://www.redhat.com/mailman/listinfo/linux-audit
3:44 p.m.
On Wednesday 15 June 2005 15:36, Timothy R. Chavez wrote:
Rik's hook can only give back the _relevant_ information the system call was able
to use when deciding its courses of action. In some cases that's the parent and
in others it's the child.
I think we're abusing the original purpose of the hook.
Rather, misunderstanding..
I think the only confusing part of the hook is that path= returns the path of the
file in question, always, but the rest of the information is in regards to whatever
inode was needed in making a decision on what to do. If the inode belonging to
the file was not important (or not available) to make a decision with, then its not
going to be reported.
-tim
3:55 p.m.
On Wednesday 15 June 2005 16:36, Timothy R. Chavez wrote:
Well, its intuitive that the information being reported is the
parent's
information and not the childs in these certain cases.
That doesn't matter. If the intent was to report on the file, and the
directory's mode is reported its wrong.
But you have to understand how the system call works and I think
that's
where the real problem lies.
This is irrelevant. I tried this on execve. I wanted to know the file's
execute permissions. What I got was the parent dir's permissions. You don't
need to know how the syscall works to say that the information being reported
is wrong.
To do what you suggest would/could get quite ugly I think.
I think people will want the right permissions for executables.
We can already get all this info from watching the child...
Rik's hook can only give back the _relevant_ information the system call
was able to use when deciding its courses of action. In some cases that's
the parent and in others it's the child.
Let's go back to the CAPP requirements and see what is necessary. If we are
supposed to have the permissions of the file and not the parent directory -
that's what we need. If Rik's hook is wrong - so be it, let's do it right.
We are going to trap the changes to file attributes in the file system
auditing to meet FMY_MSA.1. This means it will generate PATH records. If it
records by accident, the parent directory - we haven't met the requirement.
This also means the PATH record for -p x will always be wrong. This is used to
monitor auditd startup attempts and unsuccessful attempts to retrieve audit
information.
-Steve
4:28 p.m.
--- Steve Grubb <sgrubb(a)redhat.com> wrote:
That doesn't matter. If the intent was to report on
the file, and the
directory's mode is reported its wrong.
The right thing to do is report the pathname
and attributes of the component upon which the
access control decision failed or ultimatly
succeeded. Thus, for
/a/b/c
if the access was successful the audit record
ought to always contain the path "/a/b/c" and
the attributes of "c". If the access control
failed on "b", the record needs to include
"/a/b" and the attributes of "b" as well as an
indication that what you were ultimatly after
was "/a/b/c/", even though you never got there.
If the access failed on "c" the record needs
the path "/a/b/c" and the attributes of "c",
just as in the success case.
This can get hairy. On exec(), for example,
the audit record may include the path of a
directory, not a program file. You have to be
ready for this in postprocessing.
You never want the attributes of the directory
on a successful access, this does not make
sense and certainly fails the CAPP requirement.
You only want the attributes of the directory
if that is the object upon which access was
denied.
Casey Schaufler
casey(a)schaufler-ca.com
__________________________________
Discover Yahoo!
Get on-the-go sports scores, stock quotes, news and more. Check it out!
http://discover.yahoo.com/mobile.html
11:41 a.m.
On Wed, 2005-06-15 at 14:56 -0500, Timothy R. Chavez wrote:
This patch introduces fixes for:
1. sys_rename() return code debacle
->
as a side effect of removing the error handling from fs/namei.c this bug was
also removed
2. leaky memory in auditfs_attach_wdata in failure path
3. NULL dereference on audit_inode_free()
->
race could occur between the child inode being deleted and the watch being
removed from parent
This patch adds:
1. Implicit watc removal message with -1 loginuid
2. New type, AUDIT_FS_INODE (1308)
->
now that we have watches per inode per record, we collect common inode
information for the watch on AUDIT_FS_INODE and use AUDIT_FS_WATCH to list
the watch information
3. Minor code cleanups (eliminating pointless goto's)
OK, it's built in audit.58 which is in the yum repository now.
What's left:
1. Hooking chmod/chown/chgrp and the appropriate ACL calls (Me)
2. Watch scalability problem (Me)
3. AUID filtering on USER messages and watches (David)
That's building in audit.59 which will be up there later.
4. PATH record woes... add a new token stating "I'm the
parent of the file or
I'm the file"
I'll do that next, along with going through the rest of Steve's bugzilla
items.
--
dwmw2
7127
days inactive
7129
days old
linux-audit@lists.linux-audit.osci.io
6 comments
4 participants
participants (4)
-
Casey Schaufler -
David Woodhouse -
Steve Grubb -
Timothy R. Chavez