Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 7 Dec 2012 10:23:56 +0100
From:      Fleuriot Damien <ml@my.gd>
To:        Paul Schmehl <pschmehl_lists@tx.rr.com>
Cc:        n j <nino80@gmail.com>, tundra@tundraware.com, FreeBSD Mailing List <freebsd-questions@freebsd.org>
Subject:   Re: Somewhat OT: Is Full Command Logging Possible?
Message-ID:  <04283347-1955-4C49-9ADD-6D2FBB1B0EDC@my.gd>
In-Reply-To: <6A61448BD1FE69ED206EB42E@utd71538.campus.ad.utdallas.edu>
References:  <50BFD674.8000305@tundraware.com> <8BFA2629-45CA-491B-9BA8-E8AC78A4D66E@my.gd> <50BFDCFD.4010108@tundraware.com> <CALf6cgb0%2BGXrtTymOPOmjV_C2sk7EaGK=qJOF2z4mB3pQkzV_g@mail.gmail.com> <50C0EFA4.3010902@tundraware.com> <6A61448BD1FE69ED206EB42E@utd71538.campus.ad.utdallas.edu>

next in thread | previous in thread | raw e-mail | index | archive | help

On Dec 6, 2012, at 9:20 PM, Paul Schmehl <pschmehl_lists@tx.rr.com> =
wrote:

> --On December 6, 2012 1:19:00 PM -0600 Tim Daneliuk =
<tundra@tundraware.com> wrote:
>>=20
>> I understand this.  Even the organization in question understands
>> this.  They are not trying to *prevent* any kind of access.  All
>> they're trying to do *log* it.  Why?  To meet some obscure
>> compliance requirement they have to adhere to in order to
>> remain in business.
>>=20
>> <rant>
>> I know all of this is silly but that's our future when you
>> let Our Fine Government regulate pretty much anything.
>> </rant>
>>=20
>=20
> I sent this last night, but for some reason it never showed up.
>=20
> /usr/ports/security/sudoscript
>=20
> I believe this will meet your requirements.


I'm sorry to say it won't.
Nothing will prevent a user from removing sudoscript's FIFO once he gets =
root privileges.


Basically, what Tim wants to do sounds very akin to the PCI DSS =
requirements that every user's action be logged.
The bad news is _this is not achievable on MS/nux/bsd_ systems.
The kind of logging and security required can only be attained on =
mainframes (read: i/Series , z/Series) using RACF and other absolutely =
awesome features.


The only thing Tim can do is try to approach the level of security =
that's required.

Devin's suggestion of a kernel module is what comes closest to achieving =
the goal, provided that:
- the functionnality is compiled in-kernel to prevent kldunload'ing the =
module
- the system runs at a secure level high enough to prevent kldunloads , =
if it can't be compiled in-kernel
- the functions used by the module cannot be overriden by another module =
(for example redeclare this module's sendlog() function with another =
dummy module, making sendlog() basically do a NOOP)

Another contestant that comes a close second is the use of the AUDIT =
framework, however one would need to ensure:
- audit trails cannot be tampered (chflags sappend)
- the audit daemon cannot be killed




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?04283347-1955-4C49-9ADD-6D2FBB1B0EDC>