2:25 p.m.
Timothy R. Chavez wrote: [Fri Apr 28 2006, 11:29:27AM EDT]
On Fri, 2006-04-28 at 08:50 -0400, Steve Grubb wrote:
> I completely disagree with the current file system auditing approach requiring
> explicit syscall coupling. I think it is a big problem for the security
> community to have a tool for auditing files that requires knowledge of
> syscalls.
This audit subsystem was designed around knowledge of syscalls, to the
point that it requires the user to know whether a particular rule
field is applicable at syscall entry or exit time. (!)
The filesystem auditing capability that is currently upstream
(inode-based) requires a knowledge of syscalls. The path-based
functionality I've been working on isn't supposed to be a replacement
for the current inode-based filtering. It is supposed to complement
it to provide a way to audit config files.
> I personally want to be able to tell the kernel that I want
notification of:
> reads, writes, execution, or changes to attributes of a specific file or all
> files in that directory and subdirectories. User space should not have to
> know which syscalls implement each of the categories.
This is really simple and intuitive. I like it. These abstractions
should be easily expressed. I don't imagine that the majority of the
users of audit are going to need the level of granularity that's been
provided, which is why the above makes sense.
Agreed, I think this makes a lot of sense. As Al also mentioned in
another thread, having auditctl specify a special bit or flag that
tells the kernel to set the appropriate bits in the syscall mask would
solve the problem for userspace.
2:56 p.m.
New subject: [redhat-lspp] Watch question
--- Amy Griffis <amy.griffis(a)hp.com> wrote:
Timothy R. Chavez wrote: [Fri Apr 28 2006,
11:29:27AM EDT]
> On Fri, 2006-04-28 at 08:50 -0400, Steve Grubb
wrote:
> > I completely disagree with the current file
system auditing approach requiring
> > explicit syscall coupling. I think it is a big
problem for the security
> > community to have a tool for auditing files that
requires knowledge of
> > syscalls.
This audit subsystem was designed around knowledge
of syscalls, to the
point that it requires the user to know whether a
particular rule
field is applicable at syscall entry or exit time.
(!)
The alternative to understanding system calls is
understanding the underlying security policy in
detail, and in truth you'll get lost pretty
quickly if you don't understand both on whatever
system you're using. For audit to be complete it
must be done at a low enough level that access
control decisions can be observed. Since access
control is deeply embedded in the system it is
necessary to embed audit as well. Systems that
use a explicitly modular reference monitor have
an advantage, but are still constrained by the
information provided them. (reference the recent
"inode" vs. "pathname" discussion on LSM)
It is also the case that auditing must be coupled
to the action requested. I'll admit that open()
is not a very informative event, and that ioctl()
is even worse. But for "real intent" there is no
metric.
Casey Schaufler
casey(a)schaufler-ca.com
3:24 p.m.
New subject: [redhat-lspp] Watch question
On Monday 01 May 2006 15:25, Amy Griffis wrote:
This audit subsystem was designed around knowledge of syscalls,
I think its fairer to say that syscall auditing is designed around knowledge
of syscalls.
to the point that it requires the user to know whether a particular
rule
field is applicable at syscall entry or exit time. (!)
auditctl figures that out for people.
The filesystem auditing capability that is currently upstream
(inode-based) requires a knowledge of syscalls.
I really don't consider this to be file system auditing because the
perspective is from a syscall point of view.
To me, and in RHEL4, file system auditing is a whole different approach. It
does away with any knowledge of syscalls and just requires the system admin
to state what path and access type they are interested in. The approach is
decoupled from syscall auditing mostly because of the heavy performance
penalty that syscall auditing incurs. The decoupling does several things. It
keeps syscalls that have nothing to do with the file system from paying any
performance penalty. It frees user space from having to maintain any kind of
function/syscall mapping. Upgrading users space and kernel can happen
independently and both pieces continue to work. But it also allows the
structuring of the command to a simpler format because they are decoupled in
the kernel.
If we were to create a network auditing subsystem, I would want it designed
similarly. Step back from the problem, ask what the user would really want to
know about the network, and design a command interface to answer those
questions. It would not be coupled to syscalls because they have little to do
with the question a user might ask. (Besides, if syscalls figured into it in
anyway, they should use the syscall interface.) It should have properties of
maintaining performance, no coupling with other types of auditing, and be
cohesive or focused on just its one area.
As Al also mentioned in another thread, having auditctl specify a
special
bit or flag that tells the kernel to set the appropriate bits in the syscall
mask would solve the problem for userspace.
Who is going to maintain that mask in the future ? What about people with old
user space utilities?
-Steve
6810
days inactive
6810
days old
linux-audit@lists.linux-audit.osci.io
2 comments
3 participants
participants (3)
-
Amy Griffis -
Casey Schaufler -
Steve Grubb