auditing users within a jail

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

auditing users within a jail

Eitan Adler-4
)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
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: auditing users within a jail

Christian S.J. Peron-2
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
> _______________________________________________
> [hidden email] mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-security
> To unsubscribe, send any mail to "[hidden email]"
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: auditing users within a jail

Big Lebowski
On Mon, Mar 12, 2018 at 3:17 AM, Christian Peron <[hidden email]> 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? :)
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: auditing users within a jail

Mateusz Piotrowski
In reply to this post by Christian S.J. Peron-2
On Sun, 11 Mar 2018 22:17:47 -0500
Christian Peron <[hidden email]> 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.
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: auditing users within a jail

Eitan Adler-4
On 14 March 2018 at 06:13, Mateusz Piotrowski <[hidden email]> wrote:

> On Sun, 11 Mar 2018 22:17:47 -0500
> Christian Peron <[hidden email]> 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
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: auditing users within a jail

Mateusz Piotrowski
On Sat, 17 Mar 2018 04:48:52 -0700
Eitan Adler <[hidden email]> wrote:

>On 14 March 2018 at 06:13, Mateusz Piotrowski <[hidden email]> wrote:
>> On Sun, 11 Mar 2018 22:17:47 -0500
>> Christian Peron <[hidden email]> 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
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "[hidden email]"