All of lore.kernel.org
 help / color / mirror / Atom feed
* Audit, lxc containers and logged paths
@ 2016-06-30 17:27 Michele Giacomoli
  2016-06-30 17:40 ` Michele Giacomoli
  2016-06-30 18:09 ` Richard Guy Briggs
  0 siblings, 2 replies; 4+ messages in thread
From: Michele Giacomoli @ 2016-06-30 17:27 UTC (permalink / raw)
  To: linux-audit

Hello everybody,

I need to watch folders inside unprivileged linux containers. From what 
I know it's not possible to run audit inside a lxc guest, so I set up 
audit inside the host to log access to dirs using absolute path (e.g. 
/var/lib/lxc/mycontainer/rootfs/etc/) and it works, but giving a look at 
the logs I found that both the paths of the executable and the path that 
has been accessed are relative to the container (i.e. /bin/ls and 
/etc/passwd), so I don't have a clue of which is the container that 
generated the record. I could compare the uid that generated it whith 
the uids set for the containers, but it seems an ugly solution.

Can audit be configured for logging the absolute paths, or give me a 
hint of the container that generated the record?

Best regards
Michele

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: Audit, lxc containers and logged paths
  2016-06-30 17:27 Audit, lxc containers and logged paths Michele Giacomoli
@ 2016-06-30 17:40 ` Michele Giacomoli
  2016-06-30 18:09 ` Richard Guy Briggs
  1 sibling, 0 replies; 4+ messages in thread
From: Michele Giacomoli @ 2016-06-30 17:40 UTC (permalink / raw)
  To: linux-audit

Sorry, forgot to mention:
Host is Ubuntu 14.04, while guests are different Ubuntu versions
Audit is installed from Ubuntu repos (version 1:2.3.2-2ubuntu1)

Thank you

Il 30/06/2016 19:27, Michele Giacomoli ha scritto:
> Hello everybody,
>
> I need to watch folders inside unprivileged linux containers. From 
> what I know it's not possible to run audit inside a lxc guest, so I 
> set up audit inside the host to log access to dirs using absolute path 
> (e.g. /var/lib/lxc/mycontainer/rootfs/etc/) and it works, but giving a 
> look at the logs I found that both the paths of the executable and the 
> path that has been accessed are relative to the container (i.e. 
> /bin/ls and /etc/passwd), so I don't have a clue of which is the 
> container that generated the record. I could compare the uid that 
> generated it whith the uids set for the containers, but it seems an 
> ugly solution.
>
> Can audit be configured for logging the absolute paths, or give me a 
> hint of the container that generated the record?
>
> Best regards
> Michele

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: Audit, lxc containers and logged paths
  2016-06-30 17:27 Audit, lxc containers and logged paths Michele Giacomoli
  2016-06-30 17:40 ` Michele Giacomoli
@ 2016-06-30 18:09 ` Richard Guy Briggs
  2016-07-01  7:40   ` Michele Giacomoli
  1 sibling, 1 reply; 4+ messages in thread
From: Richard Guy Briggs @ 2016-06-30 18:09 UTC (permalink / raw)
  To: Michele Giacomoli; +Cc: linux-audit

On 2016-06-30 19:27, Michele Giacomoli wrote:
> Hello everybody,

Hi Michele,

> I need to watch folders inside unprivileged linux containers. From
> what I know it's not possible to run audit inside a lxc guest, so I
> set up audit inside the host to log access to dirs using absolute
> path (e.g. /var/lib/lxc/mycontainer/rootfs/etc/) and it works, but
> giving a look at the logs I found that both the paths of the
> executable and the path that has been accessed are relative to the
> container (i.e. /bin/ls and /etc/passwd), so I don't have a clue of
> which is the container that generated the record. I could compare
> the uid that generated it whith the uids set for the containers, but
> it seems an ugly solution.

General topics surrounding this sort of issue have been discussed on
this list over the last couple of year.  The way things are currently
set up you are correct in the current way to address this problem.  The
kernel currently has no concept of containers.

> Can audit be configured for logging the absolute paths, or give me a
> hint of the container that generated the record?

There have been some proposals to address this sort of challenge, but
there is no consensus yet.  I'm doing a presentaiton at the Linux
Security Summit in Toronto this year in August that will touch on some
of these issues and how we might address them.  Some approaches document
the namespaces of events and others allow audit to run in the container.

(As to the follow-on reply, at this point the distribution is irrelevant
since it isn't in the upstream kernel yet.)

> Michele

- RGB

--
Richard Guy Briggs <rgb@redhat.com>
Kernel Security Engineering, Base Operating Systems, Red Hat
Remote, Ottawa, Canada
Voice: +1.647.777.2635, Internal: (81) 32635

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: Audit, lxc containers and logged paths
  2016-06-30 18:09 ` Richard Guy Briggs
@ 2016-07-01  7:40   ` Michele Giacomoli
  0 siblings, 0 replies; 4+ messages in thread
From: Michele Giacomoli @ 2016-07-01  7:40 UTC (permalink / raw)
  To: linux-audit

Got it. Thank you very much Richard

Il 30/06/2016 20:09, Richard Guy Briggs ha scritto:
> On 2016-06-30 19:27, Michele Giacomoli wrote:
>> Hello everybody,
> Hi Michele,
>
>> I need to watch folders inside unprivileged linux containers. From
>> what I know it's not possible to run audit inside a lxc guest, so I
>> set up audit inside the host to log access to dirs using absolute
>> path (e.g. /var/lib/lxc/mycontainer/rootfs/etc/) and it works, but
>> giving a look at the logs I found that both the paths of the
>> executable and the path that has been accessed are relative to the
>> container (i.e. /bin/ls and /etc/passwd), so I don't have a clue of
>> which is the container that generated the record. I could compare
>> the uid that generated it whith the uids set for the containers, but
>> it seems an ugly solution.
> General topics surrounding this sort of issue have been discussed on
> this list over the last couple of year.  The way things are currently
> set up you are correct in the current way to address this problem.  The
> kernel currently has no concept of containers.
>
>> Can audit be configured for logging the absolute paths, or give me a
>> hint of the container that generated the record?
> There have been some proposals to address this sort of challenge, but
> there is no consensus yet.  I'm doing a presentaiton at the Linux
> Security Summit in Toronto this year in August that will touch on some
> of these issues and how we might address them.  Some approaches document
> the namespaces of events and others allow audit to run in the container.
>
> (As to the follow-on reply, at this point the distribution is irrelevant
> since it isn't in the upstream kernel yet.)
>
>> Michele
> - RGB
>
> --
> Richard Guy Briggs <rgb@redhat.com>
> Kernel Security Engineering, Base Operating Systems, Red Hat
> Remote, Ottawa, Canada
> Voice: +1.647.777.2635, Internal: (81) 32635

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2016-07-01  7:40 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2016-06-30 17:27 Audit, lxc containers and logged paths Michele Giacomoli
2016-06-30 17:40 ` Michele Giacomoli
2016-06-30 18:09 ` Richard Guy Briggs
2016-07-01  7:40   ` Michele Giacomoli

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.