Watch question
A message that is not in the archive (sent off-list or not yet received): [email protected]
A message that is not in the archive (sent off-list or not yet received): [email protected]
A message that is not in the archive (sent off-list or not yet received): [email protected]
Timothy R. Chavez wrote: [Fri Apr 28 2006, 11:29:27AM EDT]
Quoted 5 lines · Steve Grubb
Quoted 4 lines
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.
Quoted 9 lines
Quoted 4 lines
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
[email protected]
https://www.redhat.com/mailman/listinfo/redhat-lspp
Quoted 10 lines · --- Amy Griffis
Timothy R. Chavez wrote: [Fri Apr 28 2006,
11:29:27AM EDT]Quoted 1 line
On Fri, 2006-04-28 at 08:50 -0400, Steve Grubb
Quoted 1 line · wrote:
Quoted 1 line
I completely disagree with the current file
system auditing approach requiring
Quoted 1 line
Quoted 1 line
explicit syscall coupling. I think it is a big
problem for the security
Quoted 1 line
Quoted 1 line
community to have a tool for auditing files that
requires knowledge of
Quoted 8 lines
Quoted 1 line
Quoted 1 line
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
[email protected]
Quoted 1 line · Amy Griffis
This audit subsystem was designed around knowledge of syscalls,
I think its fairer to say that syscall auditing is designed around knowledge of syscalls.
Quoted 2 lines
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.
Quoted 2 lines
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.
Quoted 3 lines
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