Re: Auditing of Samba activity and SOX

[Joachim Schipper <j.schipper () math uu nl>]

On Thu, Feb 03, 2005 at 01:49:03PM +0930, Peter.McLarty () mincom com wrote:
> Hi
> I am having some discussions with a client about a solution to access 
> reports on a Unix server and our proposal is and has been in the past for 
> our customers  to use Samba to do this. Some of the trouble comes from the 
> big 4 consulting house which is there SOX auditor
> This customer is balking  due to their organisation having to be SOX 
> compliant. 
> The complaint is that a user could view or edit a sensitive file /report 
> and as Samba has no capability to audit all the users activity and on the 
> face of it this is a somewhat valid argument.
>
> Obviously other organisations are SOX compliant and using Samba so there 
> has to be a solution. My initial thought is to use Unix auditing  by 
> enabling the HP-UX trusted computing.
>
> How have other organisations been able to meet SOX with Samba servers
>
>
> Cheers
>
> Peter 

> -- 
> This transmission is for the intended addressee only and is confidential information. If you have received this 
> transmission in error, please notify the sender and delete the transmission. The contents of this e-mail are the 
> opinion of the writer only and are not endorsed by the Mincom Group of companies unless expressly stated otherwise.

Dear Peter,

while I don't know anything about SOX, I consider installing SAMBA to
not be a terribly good idea under any circumstance. It has far too many
flaws.

That being said, if you are really adamant about using it, there are
quite a few options to make it more secure: chroot() jail and the
extd_audit module come to mind (if you want to audit file access,
extd_audit is quite good; however, I'm not sure it will distinguish
between read-only and read-write access; it probably will if you crank
the log level up enough); coupled with proper file permissions, this
would make it pretty much impossible to do bad stuff without hacking the
server and/or appearing in the logs. Of course, some would say that
hacking is a real threat here. *I* would never put SAMBA on any server
if it can be helped (obviously, putting SAMBA on the office's fileserver
is one instance where this can't be helped - short of migrating
everything to AFS or something, at least).

Oh, and please fix your .sig - not only is this a public mailing list,
but it's also a whopping 340 columns long!

                        Joachim