linux-kernel - Re: [RFC Part1 PATCH 00/20 v2] Add namespace support for audit

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: <1386705056.23829.13.camel@flatline.rdu.redhat.com>
Date:	Tue, 10 Dec 2013 14:50:56 -0500
From:	Eric Paris <eparis@...hat.com>
To:	Serge Hallyn <serge.hallyn@...ntu.com>
Cc:	Gao feng <gaofeng@...fujitsu.com>,
	Richard Guy Briggs <rgb@...hat.com>,
	containers@...ts.linux-foundation.org,
	linux-kernel@...r.kernel.org, linux-audit@...hat.com,
	ebiederm@...ssion.com, sgrubb@...hat.com
Subject: Re: [RFC Part1 PATCH 00/20 v2] Add namespace support for audit

On Tue, 2013-12-10 at 10:51 -0600, Serge Hallyn wrote:
> Quoting Gao feng (gaofeng@...fujitsu.com):
> > On 12/10/2013 02:26 AM, Serge Hallyn wrote:
> > > Quoting Gao feng (gaofeng@...fujitsu.com):
> > >> On 12/07/2013 06:12 AM, Serge E. Hallyn wrote:
> > >>> Quoting Gao feng (gaofeng@...fujitsu.com):
> > >>>> Hi
> > >>>>
> > >>>> On 10/24/2013 03:31 PM, Gao feng wrote:
> > >>>>> Here is the v1 patchset: http://lwn.net/Articles/549546/
> > >>>>>
> > >>>>> The main target of this patchset is allowing user in audit
> > >>>>> namespace to generate the USER_MSG type of audit message,
> > >>>>> some userspace tools need to generate audit message, or
> > >>>>> these tools will broken.
> > >>>>>
> > >>>>
> > >>>> I really need this feature, right now,some process such as
> > >>>> logind are broken in container becase we leak of this feature.
> > >>>
> > >>> Your set doesn't address loginuid though right?  How exactly do you
> > >>> expect to do that?  If user violates MAC policy and audit msg is
> > >>> sent to init user ns by mac subsys, you need the loginuid from
> > >>> init_audit_ns.  where will that be stored if you allow updates
> > >>> of loginuid in auditns?
> > >>>
> > >> This patchset doesn't include the loginuid part.
> > >>
> > >> the loginuid is stored in task as before.
> > >> In my opinion, when task creates a new audit namespace, this task's
> > >> loginuid will be reset to zero, so the children tasks can set their
> > >> loginuid. Does this change break the MAC?
> > > 
> > > I think so, yes.  In an LSPP selinux environment, if the task
> > > manages to trigger an selinux deny rule which is audited, then
> > > the loginuid must make sense on the host.  Now presumably it
> > > will get translated to the mapped host uid, and we can figure
> > > out the host uid owning it through /etc/subuid.  But that adds
> > > /etc/subuid as a new part of the TCB without any warning <shrug>
> > > So in that sense, for LSPP, it breaks it.
> > > 
> > 
> > Looks like my opinion is incorrect.
> > 
> > In the audit-next tree, Eric added a new audit feature to allow privileged
> > user to disable AUDIT_LOGINUID_IMMUTABLE. after AUDIT_LOGINUID_IMMUTABLE
> > is disabled, the privileged user can reset/set the loginuid of task. I
> > think this way is safe since only privileged user can do the change.
> > 
> > So I will not change the loginuid part.
> > 
> > Thanks for your information Serge :)
> 
> Unfortunately this makes the patchset much less compelling :)  The
> problem I was looking into is that a container running in a user
> namespace cannot (bc he has ns_capable(CAP_AUDIT_*) but not
> capable(CAP_AUDIT_*)) set loginuids at all.
> 
> Which from an LSPP pov is correct;  which is why I was hoping you were
> going to have the audit namespaces be hierarchical, with a task in a
> level 2 audit ns having two loginuids - one in his own auditns, and
> one in the initial one.

Right now user namespace + audit is just total crud.  We all know
this...  (I'm not sure pid is must better, but I digress)   All thoughts
around loginuid in the kernel right this very moment only make sense in
the initial user namespace and all permission checks are in the initial
user namespace as well.

I think I'm a proponent of the hierarchical approach to audit
namespaces.  An audit namespace would hold a reference to the
pid/user/whatever namespace it was created in/with.  Each audit
namespace should have it's own set of filter rules, etc.  Instead of
just storing 'loginuid' we store 'loginuid+user namespace'.   When the
kernel creates a record it should translate the loginuid to the
namespace of the audit namespace and send the record.

It's a pretty major rewrite, but at least it makes sense.  Things like
AVC's might show up in multiple audit logs, but in every log they would
make sense to the admin of that namespace...

But what the hell do I know...  Namespaces scare me...

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/