Re: Watch question

Re: Watch question

[Amy Griffis]

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.

--
redhat-lspp mailing list
redhat-lspp@redhat.com
https://www.redhat.com/mailman/listinfo/redhat-lspp

Re: [redhat-lspp] Watch question

[Casey Schaufler]

--- Amy Griffis <amy.griffis@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@schaufler-ca.com

Re: [redhat-lspp] Watch question

[Steve Grubb]

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