linux-ext4 - Re: [Project Quota]file owner could change its project ID?

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: <20191020222529.GA6799@mit.edu>
Date:   Sun, 20 Oct 2019 18:25:29 -0400
From:   "Theodore Y. Ts'o" <tytso@....edu>
To:     Andreas Dilger <adilger@...ger.ca>
Cc:     "Darrick J. Wong" <darrick.wong@...cle.com>,
        Wang Shilong <wangshilong1991@...il.com>,
        linux-xfs@...r.kernel.org, linux-fsdevel@...r.kernel.org,
        Ext4 Developers List <linux-ext4@...r.kernel.org>,
        Li Xi <lixi@....com>, Wang Shilong <wshilong@....com>
Subject: Re: [Project Quota]file owner could change its project ID?

On Sun, Oct 20, 2019 at 02:19:19PM -0600, Andreas Dilger wrote:
> > We could also solve the problem by adding an LSM hook called when
> > there is an attempt to set the project ID, and for people who really
> > want this, they can create a stackable LSM which enforces whatever
> > behavior they want.
> 
> So, rather than add a few-line change that decides whether the user
> is allowed to change the projid for a file, we would instead add *more*
> lines to add a hook, then have to write and load an LSM that is called
> each time?  That seems backward to me.

I'm just not sure we've necessarily gotten the semantics right.  For
example, I could easily see someone else coming out of the woodwork
saying that The Right Model (tm) is one where users belong to a number
of projects (much like supplementary group ID's) and you should be
able to set the project of any file that you own to a project.

Or perhaps the policy is that you can only change the project ID if
the project ID has a non-zero project quota.  etc.

> > If we think this going to be an speciality request, this might be the
> > better way to go.
> 
> I don't see how this is more "speciality" than regular quota enforcement?
> Just like we impose limits on users and groups, it makes sense to impose
> a limit on a project, instead of just tracking it and then having to add
> extra machinery to impose the limit externally.

We *do* have regular quota enforcement.  The question here has nothing
to do with how quota tracking or enforcement work.  The question is
about what are the authorization checks and policy surrounding when
the project ID can modified.

Right now the policy is "the owner of the file can set the project ID
to any integer if it is issued from the initial user namespace;
otherwise, no changes to the project ID or the PROJINHERIT flag is
allowed".

Making it be "only root in the inital user namespace is allowed change
project ID or PROJINHERIT flag" is certain an alternate policy.  Are
we sure those are the only two possible policies that users might ask
for?

					- Ted