[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: auditing file access



On Mon, 1 Oct 2001, Shaul Karl wrote:

> > further, our code does logging using printf, which causes load
> > if you're logging a lot of information.
>
> If I understand you correctly then printf causes more load then other
> alternatives. What other alternatives are there, why printf causes more load
> and why have you choose to use it?

sorry, i meant to say 'kprintf'. this implies logging goes kernel -> klogd
->syslogd -> disk with sync

i think the long route, together with this sync (syslogd sync the file to
disk, probably using fsycn() or fdatasync() after each record it logs to a
file - to make sure a system crash won't cause log records to vanish).

why did we choose kprintf? cause it was the easiest way to have
_something_ done. we intend to replace this with using a device file and
then sending log records into user space, letting the user-space daemon
perform the actuall logging. this way you could loose log data if the
system crashes, but the logging should be much more efficient. (device
file support just barely started).

btw, if you're interested in these kind of things, you might want to read
'linux device drivers, 2nd edition' - its one of those cases where a book
is worth every penny (and many of them don't).

> > you might also check medusa DS9 - its a kernel patch and user-level utils
> > for security issues - they might have what you need -
> > http://medusa.fornax.sk . it looks like that also got a nice logging
> > facility, and their product is certainly more mature.
>
> How are the features of your project compared to medusa?

their software is much more advanced then ours, but the focus is
different. they focus on security - we focus on system debugging.
their system requires a kernel patch - our system requires only compiling
a kernel module (which still requires kernel sources configured like your
run-time kernel). their system splits decision making between kernel code
and user-level code. our system (currently) performs all decision making
inside the kernel - thought we might add support for user-mode decision
making in the future.

> How is your project compared to the "kernel auditing facility" that was
> mentioned here by Herouth Maoz?

if you're refering to the 'linux privs' document - its just a document, no
code. so they do not compare, and we do not implement anyone's standard
right now. if you're refering to something else - then please remind me
what it was.

btw, there is also 'lsm' (linux security model) which appears to be worked
on for version 2.5, which should implement a security framework in a
standard linux kernel, thought currently, i think its a patch for
2.4.something .

--
guy

"For world domination - press 1,
 or dial 0, and please hold, for the creator." -- nob o. dy


=================================================================
To unsubscribe, send mail to linux-il-request@linux.org.il with
the word "unsubscribe" in the message body, e.g., run the command
echo unsubscribe | mail linux-il-request@linux.org.il