linux-kernel - Re: Thinking outside the box on file systems

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: <20070815133021.GB9412@csclub.uwaterloo.ca>
Date:	Wed, 15 Aug 2007 09:30:21 -0400
From:	lsorense@...lub.uwaterloo.ca (Lennart Sorensen)
To:	Michael Tharp <gxti@...tiallystapled.com>
Cc:	alan <alan@...eserver.org>, Marc Perkel <mperkel@...oo.com>,
	linux-kernel@...r.kernel.org
Subject: Re: Thinking outside the box on file systems

On Wed, Aug 15, 2007 at 09:02:37AM -0400, Michael Tharp wrote:
> This jumped out at me right away. In such a system, an attacker with
> write permissions on a "sticky" directory like /tmp could probe for
> others' files by attempting to create them and recording all cases where
> permission was denied due to an existing, hidden file. But of course,
> this was just an example of something a less UNIX-y permission scheme
> could do, not a key part of such a design.
> 
> Personally, what I'd like to see is a better way of dealing with
> propagation of ownership. Currently, in order to allow "collaboration"
> directories where a directory tree is owned by a certain group and
> anyone in that group can write and create files, one has to change the
> system umask, use a magical bit on the collaboration directory to
> propagate group ownership, and create a group for every user on the
> system in order to keep their personal files safe with the new umask.
> This seems highly flawed. I suggest that propagation of group ownership
> should be the default mode, not a special one, and that the
> group-writable permissions should also be propagated to new files and
> directories. This way, the user's home directory would remain 0755,
> while the collaboration directory could be 0775, without any changing of
> umasks.
> 
> Of course, this would go against tradition, and cause some mayhem in the
> logic responsible for magically determining permissions for new files,
> but since we're talking about thinking outside of the box, I think
> that's excusable :)

Posix ACLs seem to solve most group permissions issues and control of
permission propegation.  It actually works quite well on Linux.  I am
surprised if there aren't lots of people already using it.

Remember that existing software expects a unix style interface, since
they are unix programs.  Anything you invent MUST be compatible with the
standard unix view of things, even if it offers additional options.

--
Len Sorensen
-
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/