linux-kernel - Re: [PATCH -V6 00/26] New ACL format for better NFSv4 acl interoperability

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]

Date:	Tue, 13 Sep 2011 14:12:45 -0400
From:	Valdis.Kletnieks@...edu
To:	Casey Schaufler <casey@...aufler-ca.com>
Cc:	"Aneesh Kumar K.V" <aneesh.kumar@...ux.vnet.ibm.com>,
	agruen@...nel.org, bfields@...ldses.org, akpm@...ux-foundation.org,
	dhowells@...hat.com, linux-fsdevel@...r.kernel.org,
	linux-nfs@...r.kernel.org, linux-kernel@...r.kernel.org,
	LSM <linux-security-module@...r.kernel.org>
Subject: Re: [PATCH -V6 00/26] New ACL format for better NFSv4 acl interoperability

(merging two replies)

On Mon, 12 Sep 2011 14:34:04 PDT, Casey Schaufler said:
> > Well, if it was done as an LSM, it would mean that if I wanted to build a
> > system where I have a few hundred terabytes of disk exported via Samba, and I
> > wanted Samba to save the CIFS permission ACL, I couldn't also run Selinux or
> > SMACK or anything like that - unless somebody actually snuck in the "LSMs are
> > stackable" patch while I wasn't looking?

> True, but not an acceptable argument for not doing it as an LSM.
> It is an argument in favor of LSM stacking, and after the Linux
> Security Summit this past week it seems only a matter of time before
> we have that. This could be the compelling use case that we've been
> missing for LSM stacking.

OK, I can certainly agree with that logic..

> So at this point, unless there is another reason why it can't be an
> LSM it should be an LSM.

Well, this issue still:

On Mon, 12 Sep 2011 18:43:51 EDT, "J. Bruce Fields" said:
> On Mon, Sep 12, 2011 at 03:38:24PM -0700, Casey Schaufler wrote:
> > POSIX ACLs require that the file permission bits change when
> > the ACL changes. This interaction violates the strict "additional
> > restriction" model of the LSM.
>
> Oh, OK.  Yes, rich ACLs are the same as POSIX ACLs in this respect.
> When you set an ACL the mode bits are reset to represent an "upper
> bound" on the permissions granted by the ACL.

Can we finess this detail by making the "set an ACL and make needed changes to
the mode bits" part of the VFS's responsibility as part of whatever syscall/
ioctl handling?  After all, the LSM doesn't get involved in the handling of
chmod() other than to say "yes/no this chmod can be issued" -  for instance,
the clearing of setUID/setGID bits when a file is written is done by each
individual filesystem. So there's certianly precident for doing the permission
tweaking in the VFS code. Then we can limit the LSM part to *applying* an
already existing ACL to permission checking.

Or should I go get some more caffeine? ;)


Content of type "application/pgp-signature" skipped