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
| ||
|
Date: Wed, 18 Apr 2018 17:41:29 -0700 From: Casey Schaufler <casey@...aufler-ca.com> To: Paul Moore <paul@...l-moore.com>, Richard Guy Briggs <rgb@...hat.com> Cc: cgroups@...r.kernel.org, containers@...ts.linux-foundation.org, linux-api@...r.kernel.org, Linux-Audit Mailing List <linux-audit@...hat.com>, linux-fsdevel@...r.kernel.org, LKML <linux-kernel@...r.kernel.org>, netdev@...r.kernel.org, ebiederm@...ssion.com, luto@...nel.org, jlayton@...hat.com, carlos@...hat.com, dhowells@...hat.com, viro@...iv.linux.org.uk, simo@...hat.com, Eric Paris <eparis@...isplace.org>, serge@...lyn.com Subject: Re: [RFC PATCH ghak32 V2 01/13] audit: add container id On 4/18/2018 4:47 PM, Paul Moore wrote: > On Fri, Mar 16, 2018 at 5:00 AM, Richard Guy Briggs <rgb@...hat.com> wrote: >> Implement the proc fs write to set the audit container ID of a process, >> emitting an AUDIT_CONTAINER record to document the event. >> ... >> >> diff --git a/include/linux/sched.h b/include/linux/sched.h >> index d258826..1b82191 100644 >> --- a/include/linux/sched.h >> +++ b/include/linux/sched.h >> @@ -796,6 +796,7 @@ struct task_struct { >> #ifdef CONFIG_AUDITSYSCALL >> kuid_t loginuid; >> unsigned int sessionid; >> + u64 containerid; > This one line addition to the task_struct scares me the most of > anything in this patchset. Why? It's a field named "containerid" in > a perhaps one of the most widely used core kernel structures; the > possibilities for abuse are endless, and it's foolish to think we > would ever be able to adequately police this. If we can get the LSM infrastructure managed task blobs from module stacking in ahead of this we could create a trivial security module to manage this. It's not as if there aren't all sorts of interactions between security modules and the audit system already.
Powered by blists - more mailing lists