[Bug 125] add BSM audit support

[bugzilla-daemon at mindrot.org]

http://bugzilla.mindrot.org/show_bug.cgi?id=125


dtucker at zip.com.au changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
 Attachment #800 is|0                           |1
           obsolete|                            |




------- Additional Comments From dtucker at zip.com.au  2005-02-06 12:40 -------
Created an attachment (id=804)
 --> (http://bugzilla.mindrot.org/attachment.cgi?id=804&action=view)
Use audit hooks for BSM auditting

I think this is ready to start testing.  I have put up a snapshot with the
patch applied at:
http://www.zip.com.au/~dtucker/tmp/openssh-audit-bsm.tar.gz

There's some code in the patch #if'ed out.  I think the code in question should
be removed but it's left there for discussion.

Remaining issues:

- what is the correct way to construct the device identifier part of Terminal
ID?  The telnet events seem to use something other than a source port.

- what is the value of logging the command supplied to sshd?  It seems to be an
attempt to mimic AUE_rshd but it's not equivalent since there may be zero, one
or many command sessions supplied in a given sshd session.

  Would this not be better handled by using the built-in "ex" class? Appending
it as text token to the logout event seems wrong for a couple of reasons:
  - it'll only ever record the last command supplied
  - by my read the text tokens are limited to 255 bytes in length (or 127 if
the "length" field is unsigned, the docs don't say).

  If it's really required then should it not be a separate event number?

- why does the patch call GetAuditFunc(&now, sizeof (now))?  AFAICT the "now"
struct is never used after being populated.

- why does the original patch save the tty name?  AFAICT it's never used.

- should all of the au_* functions have their return codes checked, or is
checking au_close() adequate?

- what values should be specified with the return token?  praudit seems to
interpret the "process error" as an errno.  Are these just picked arbitrarily
by the application, with zero as success?  I noticed that later patches try to
use error numbers from 240 - 255, outside of the errno range, is this
advisable?  And are these expected to be stable for a given application (ie
sshd)?



------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.