linux-kernel - Re: [RFC PATCH ghak100 V1 1/2] audit: avoid fcaps on MNT

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: <20181120154820.4s6jflcnyu4ha5qn@madcap2.tricolour.ca>
Date:   Tue, 20 Nov 2018 10:48:20 -0500
From:   Richard Guy Briggs <rgb@...hat.com>
To:     Miklos Szeredi <miklos@...redi.hu>
Cc:     linux-kernel@...r.kernel.org, linux-audit@...hat.com,
        Al Viro <viro@...iv.linux.org.uk>,
        linux-fsdevel@...r.kernel.org, Steve Grubb <sgrubb@...hat.com>,
        Eric Paris <eparis@...hat.com>,
        Paul Moore <paul@...l-moore.com>
Subject: Re: [RFC PATCH ghak100 V1 1/2] audit: avoid fcaps on MNT_FORCE

On 2018-11-20 09:17, Miklos Szeredi wrote:
> On Mon, Nov 19, 2018 at 11:59 PM Richard Guy Briggs <rgb@...hat.com> wrote:
> 
> > The simple answer is that the audit PATH record format expects the four
> > cap_f* fields to be there and a best effort is being attempted to fill
> > in that information in an expected way with meaningful values.  Perhaps
> > better to accept that it is unreasonable to expect any fcaps on any
> > umount operation and simply ignore those fields in the PATH record for
> > umount syscall events.
> 
> When there's a mount there are in fact two objects belonging to the
> exact same path, each having completely independent metadata:  the
> mount point and the root of the mount.  For example:
> 
> stat /mnt
> umount /mnt
> stat /mnt
> 
> The first stat will show the root of the mount, the second one will
> show the mount point.
> Which one is the relevant for audit?

It would be the root of the mount, the one that is visible to processes
in that mount namespace.

Obviously, once that mount has been unmounted, it would be the mount
point (no longer in use as such at that point) that is of interest.

On mounting, I'm guessing both would be of interest if the fcaps changed
for that process-visible path in that mount namespace, so this provides
an additional operation that would need recording aside from the case
of a simple attribute change.

> Not saying audit should be doing getxattr on any of them, just trying
> to see more clearly.
> 
> Thanks,
> Miklos

- RGB

--
Richard Guy Briggs <rgb@...hat.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