auditing users within a jail

[Eitan Adler]

)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-...@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "freebsd-securi...@freebsd.org"

[Christian Peron]

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

[Big Lebowski]

On Mon, Mar 12, 2018 at 3:17 AM, Christian Peron <cs...@sqrt.ca> wrote:

> 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 suppose this could/should be added to the docs? :)

[Mateusz Piotrowski]

On Sun, 11 Mar 2018 22:17:47 -0500
Christian Peron <cs...@sqrt.ca> wrote:

>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)

FYI, I'll submit a new setaudit port if Christian decides to pull in my
enhancements.

[Eitan Adler]

On 14 March 2018 at 06:13, Mateusz Piotrowski <0...@freebsd.org> wrote:
> On Sun, 11 Mar 2018 22:17:47 -0500
> Christian Peron <cs...@sqrt.ca> wrote:
>
>>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)
>
> FYI, I'll submit a new setaudit port if Christian decides to pull in my
> enhancements.

We chatted a bit offline, but thanks for the info! That was really helpful.



--
Eitan Adler

[Mateusz Piotrowski]

On Sat, 17 Mar 2018 04:48:52 -0700
Eitan Adler <li...@eitanadler.com> wrote:

>On 14 March 2018 at 06:13, Mateusz Piotrowski <0...@freebsd.org> wrote:
>> On Sun, 11 Mar 2018 22:17:47 -0500
>> Christian Peron <cs...@sqrt.ca> wrote:
>>
>>>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)
>>
>> FYI, I'll submit a new setaudit port if Christian decides to pull in
>> my enhancements.
>
>We chatted a bit offline, but thanks for the info! That was really
>helpful.

:)

BTW, the new port is already waiting on Bugzilla:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=226627