lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20160712145936.GH3190@htj.duckdns.org>
Date:	Tue, 12 Jul 2016 10:59:36 -0400
From:	Tejun Heo <tj@...nel.org>
To:	Topi Miettinen <toiwoton@...il.com>
Cc:	linux-kernel@...r.kernel.org, ebiederm@...ssion.com,
	pmladek@...e.com, luto@...nel.org, serge@...lyn.com,
	keescook@...omium.org, Paul Moore <paul@...l-moore.com>,
	Eric Paris <eparis@...hat.com>, Li Zefan <lizefan@...wei.com>,
	Johannes Weiner <hannes@...xchg.org>,
	Serge Hallyn <serge.hallyn@...onical.com>,
	"moderated list:AUDIT SUBSYSTEM" <linux-audit@...hat.com>,
	"open list:CONTROL GROUP (CGROUP)" <cgroups@...r.kernel.org>,
	"open list:CAPABILITIES" <linux-security-module@...r.kernel.org>
Subject: Re: [PATCH] capabilities: audit capability use

On Mon, Jul 11, 2016 at 07:47:44PM +0000, Topi Miettinen wrote:
> It's really critical to be able to associate a task in the logs to
> cgroups which were valid that time. Or can we infer somehow what cgroups

When is "that time"?  Without logging all operations, this is
meaningless.

> a task was taking part, long time after task exit? Perhaps task cgroup
> membership changes and changes in available cgroups should be logged too?
> 
> Some kind of cgroup IDs could be logged instead of long paths. Then
> these IDs should be reliably resolvable to paths offline somehow.

I don't think that's doable.  That pretty much requires the kernel to
remember paths of all past cgroups.

> How usual migrations between cgroups are? Why would a task ever move
> from (say) systemd/system.slice/smartd.service to anywhere else?

In most cases, they won't move once set up initially but that's not
the point of audit subsystem.  Logging this once one exit isn't gonna
help anything for auditing the system.

Thanks.

-- 
tejun

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ