On 2018-04-09 15:52, John Jasen wrote:
> As points of clarification:
> 
> would audit on the host have visibility into the container? (for
> example, logging execve calls from certain users)

Yes, but filenames and inodes may not make sense if the filesystem isn't
mounted in the host mount namespace.

> would pam_tty_audit running the host still be able to collect data upon
> entering the container?

Yes, I believe so.

> Thanks!
> 
> On 04/05/2018 02:28 PM, Steve Grubb wrote:
> > On Thursday, April 5, 2018 12:52:24 PM EDT Bob Beck wrote:
> >> Thanks for your quick reply.
> >>
> >> Do you mean that it logs events from within the 1 specific lxc container
> >> in which it is running but not the host VM?
> > Nope. It would only work as an aggregating server. Meaning it can collect 
> > logs from remote systems. But it cannot collect anything itself. Not from 
> > the 
> > container nor the host kernel. It can only log what comes across a tcp/ip 
> > connection from another auditd. This is a limitation of the kernel - which 
> > is 
> > being worked on currently.
> >
> > -Steve
> >
> >> -----Original Message-----
> >> From: Steve Grubb [mailto:sgr...@redhat.com]
> >> Sent: Thursday, April 05, 2018 12:37 PM
> >> To: linux-audit@redhat.com
> >> Cc: Bob Beck
> >> Subject: Re: Can auditd run in lxc on centos7
> >>
> >> On Thursday, April 5, 2018 12:26:15 PM EDT Bob Beck wrote:
> >>> Hi,
> >>>
> >>> I am attempting to run auditd in centos7 inside a lxc container.
> >> It can run inside a container only as an aggregating server. Meaning that
> >> it cannot audit the host system, but rather collect logs from remote
> >> systems. To do this, set  local_events = no. This was added in
> >> audit-2.5.2.
> >>> Here is the log I get when I run auditd -f
> >>>
> >>> config file /etc/audit/auditd.conf opened for parsing
> >>>
> >>> log_file_parser called with: /var/log/audit.log
> >>>
> >>> log_format_parser called with: RAW
> >>>
> >>> log_group_parser called with: root
> >>>
> >>> priority_boost_parser called with: 4
> >>>
> >>> flush_parser called with: INCREMENTAL
> >>>
> >>> freq_parser called with: 20
> >>>
> >>> num_logs_parser called with: 5
> >>>
> >>> qos_parser called with: lossy
> >>>
> >>> dispatch_parser called with: /usr/sbin/audispd
> >>>
> >>> name_format_parser called with: NONE
> >>>
> >>> max_log_size_parser called with: 6
> >>>
> >>> max_log_size_action_parser called with: ROTATE
> >>>
> >>> space_left_parser called with: 75
> >>>
> >>> space_action_parser called with: SYSLOG
> >>>
> >>> action_mail_acct_parser called with: root
> >>>
> >>> admin_space_left_parser called with: 50
> >>>
> >>> admin_space_left_action_parser called with: SUSPEND
> >>>
> >>> disk_full_action_parser called with: SUSPEND
> >>>
> >>> disk_error_action_parser called with: SUSPEND
> >>>
> >>> tcp_listen_queue_parser called with: 5
> >>>
> >>> tcp_max_per_addr_parser called with: 1
> >>>
> >>> tcp_client_max_idle_parser called with: 0
> >>>
> >>> enable_krb5_parser called with: no
> >>>
> >>> GSSAPI support is not enabled, ignoring value at line 30
> >>>
> >>> krb5_principal_parser called with: auditd
> >>>
> >>> GSSAPI support is not enabled, ignoring value at line 31
> >>>
> >>> Started dispatcher: /usr/sbin/audispd pid: 3028
> >>>
> >>> type=DAEMON_START msg=audit(1522944040.042:592): op=start ver=2.8.4
> >>> format=raw kernel=3.10.0-693.17.1.el7.centos.plus.i686 auid=4294967295
> >>> pid=3026 uid=0 ses=4294967295 subj=system_u:system_r:init_t
> >>> res=success
> >>>
> >>> config_manager init complete
> >>>
> >>> Error sending status request (Connection refused)
> >>>
> >>> Error sending enable request (Connection refused)
> >>>
> >>> type=DAEMON_ABORT msg=audit(1522944040.043:593): op=set-enable
> >>> auid=4294967295 pid=3026 uid=0 ses=4294967295
> >>> subj=system_u:system_r:init_t res=failed
> >>>
> >>> Unable to set initial audit startup state to 'enable', exiting
> >>>
> >>> The audit daemon is exiting.
> >>>
> >>> Error setting audit daemon pid (Connection refused)
> >> Yep. That is what you get when trying to audit the host from a unprivileged
> >> container. Container support in the kernel is still an ongoing project.
> >>
> >> -Steve

- RGB

--
Richard Guy Briggs <r...@redhat.com>
Sr. S/W Engineer, Kernel Security, Base Operating Systems
Remote, Ottawa, Red Hat Canada
IRC: rgb, SunRaycer
Voice: +1.647.777.2635, Internal: (81) 32635

--
Linux-audit mailing list
Linux-audit@redhat.com
https://www.redhat.com/mailman/listinfo/linux-audit

Reply via email to