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>