Re: Exec logging, FreeBSD Kernel Module.

From: Andrew R. Reiter (arr@watson.org)
Date: 07/17/01 

Date: Tue, 17 Jul 2001 13:56:26 -0400 (EDT)
From: "Andrew R. Reiter" <arr@watson.org>
To: Kris Kennaway <kris@obsecurity.org>

I basically got a 0 response to my initial SPY reply, so I will attempt to
mention it here again, and throw Robert's name on it.

AFAIK, at USENIX there was a BoF for those working on kernel related
security features (Trusted patch sets, other) to speak their minds on 1)
what they were doing and 2) to attempt to start to come up with some sort
of cross-OS standard for having "hooks" into kernel code. This would
allow for easy coding of kernel related features that could be cross-OS
allowing for only recoding of possible OS specific pieces (which would be
greatly lessened after this standard interface was in place).

Anyway, what I had been wondering was whether or not there were some
useful conclusions actually made from that BoF... These would be useful
in something like SPY -- or some work that Im doing -- so that they can
attempt to conform to a standard from the beginning.

Anyone have any thoughts on 1) what happened at hte BoF and 2) future of
kernel hook standards in fbsd?

Andrew

On Tue, 17 Jul 2001, Kris Kennaway wrote:

> On Tue, Jul 17, 2001 at 09:37:22AM -0700, Jason DiCioccio wrote:
> >
> > Try reading up on process accounting :-)
>
> Process accounting isn't intended as a security audit feature.
>
> Kris
>

*-------------.................................................
| Andrew R. Reiter
| arr@fledge.watson.org
| "It requires a very unusual mind
| to undertake the analysis of the obvious" -- A.N. Whitehead

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-security" in the body of the message

Relevant Pages

  • Re: WANTED: Volunteer to Scan Old Programs
    ... BASIC to the American National Standard for Minimal BASIC, ... Implementation-defined features ... Error and exception reporting ... of interpretation, and Section 5 for information peculiar to ...
    (comp.os.cpm)
  • Re: Fortran Features
    ... without a specific list of extensions. ... In order to make the features optional like this, ... will need to be included in the standard. ... means that you get into a substantial debate on each ...
    (comp.lang.fortran)
  • Re: C++ danger to break due to its weight, fragmentation danger - C++0x
    ... Also not all of the new features will be ... libraries for the standard on the way which are optional. ... extensions to the C++ compiler. ...
    (comp.lang.cpp)
  • Re: Fortran Features
    ... In order to make the features optional like this, ... will need to be included in the standard. ... means that you get into a substantial debate on each ... one might have wanted the iostat codes, and not at all in others. ...
    (comp.lang.fortran)
  • Re: TR 24731 approved
    ... best interests of all to have those features. ... Every keyboard I've used for the past 60 years has a caps ... having standard keyboards. ... Trigraphs, at least in my own experience and in the experience of ...
    (comp.std.c)