From owner-freebsd-security@freebsd.org Mon Mar 12 03:27:49 2018 Return-Path: Delivered-To: freebsd-security@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 92E4CF4410D for ; Mon, 12 Mar 2018 03:27:49 +0000 (UTC) (envelope-from csjp@sqrt.ca) Received: from ion.sqrt.ca (ion.sqrt.ca [192.73.242.220]) by mx1.freebsd.org (Postfix) with ESMTP id 3E6788C793 for ; Mon, 12 Mar 2018 03:27:48 +0000 (UTC) (envelope-from csjp@sqrt.ca) Received: by ion.sqrt.ca (Postfix, from userid 114) id 6DA3E813DA; Sun, 11 Mar 2018 20:17:50 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on ion.sqrt.ca X-Spam-Level: X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.1 Received: from cps-macbook-pro.lan (S010690e2ba2e31d4.wp.shawcable.net [50.71.250.131]) by ion.sqrt.ca (Postfix) with ESMTPSA id 85DB3813D3; Sun, 11 Mar 2018 20:17:49 -0700 (PDT) Date: Sun, 11 Mar 2018 22:17:47 -0500 From: Christian Peron To: Eitan Adler Cc: "freebsd-security@freebsd.org" Subject: Re: auditing users within a jail Message-ID: <20180312031746.GB7114@cps-macbook-pro.lan> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.3 (2018-01-21) X-Mailman-Approved-At: Mon, 12 Mar 2018 10:33:08 +0000 X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Mar 2018 03:27:49 -0000 Hi Eitan, IIRC the short version is the audit related syscalls are currently disabled in jails. This means that a jailed process can not set audit configurations for themselves (or child processes). This also means things like auditd(8) wont work. However, it is possible for processes in jails to produce audit records. The processes just need an audit mask. Since audit masks (configurations) are inherited across forks, you could set a global audit configuration for the jail using the following tool (or something like it): https://github.com/csjayp/setaudit (I just dropped it on to github) We could hack on it to make it more friendly for jails etc.. but this should get you going in the right direction. With a bit of work, it could be possible to "virtualize" the core audit objects so we could have functional per jail auditing configurations, but certain care needs to be taken to ensure it couldn't override the config in the host (et al). I hope this helps. -- Best, Christian S.J. Peron On Sun, Mar 11, 2018 at 01:11:53AM -0800, Eitan Adler wrote: > )Hi all, > > I am fairly new to using the auditd framework. I'd like to set up some > basic auditing for one of my FreeBSD boxes. > > The setup is fairly simple: > - host - has "eax" and "root" > - bastion jail - has "bastion" and "root" > > I have the following audit_user file: > > root:lo:no,ad:no,aa,+fd,+ex > bastion:ex,fw,fm,fc,fd,pc,nt,ip,ad,lo:no,aa > > audit_control: > dir:/var/audit > dist:on > flags:lo,aa > minfree:5 > naflags:lo,aa > policy:cnt,argv > filesz:2M > expire-after:10M > > The auditd service is running on the host (as pid 68828) however > running "praudit /dev/auditpipe" shows no output when accessing the > bastion user on the jail. This makes sense, however trying to run > auditd in the jail shows this error: > > root@bastion:~ # /usr/sbin/auditd -d > auditd[27548]: starting... > auditd[27548]: Error opening trigger messaging mechanism > > I know I'm doing something wrong but the overall configuration confuses me. > > (a) What do I need to do to get auditing of the bastion user from (a1) > within the jail and (a2) from the host > (b) Is the auditing setup above reasonable? Am I missing obvious > events or capturing things which utterly routine? > (c) Why does praudit /dev/auditpipe show nothing but "praudit > /var/audit/current" show some events? > > > Thanks! > > > > > > > -- > Eitan Adler > _______________________________________________ > freebsd-security@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-security > To unsubscribe, send any mail to "freebsd-security-unsubscribe@freebsd.org"