linux-ext4 - Re: [PATCH RESEND] implement uid and gid mount options for ext2, ext3 and ext4

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] [day] [month] [year] [list]

Date:	Fri, 11 May 2012 20:18:35 +0300
From:	Boaz Harrosh <bharrosh@...asas.com>
To:	"Ted Ts'o" <tytso@....edu>, Rob Landley <rob@...dley.net>,
	Ludwig Nussel <ludwig.nussel@...e.de>,
	<linux-kernel@...r.kernel.org>, <linux-fsdevel@...r.kernel.org>,
	Jan Kara <jack@...e.cz>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Andreas Dilger <adilger.kernel@...ger.ca>, open list:
	EXT2 FILE SYSTEM <linux-ext4@...r.kernel.org>, ; open list:
	DOCUMENTATION <linux-doc@...r.kernel.org>, ;
Subject: Re: [PATCH RESEND] implement uid and gid mount options for ext2,
 ext3 and ext4

On 05/11/2012 07:46 PM, Ted Ts'o wrote:

> On Fri, May 11, 2012 at 09:25:37AM -0500, Rob Landley wrote:
>> Well it's certainly a point of view. Luckily, FAT already _has_ the
>> workaround we're discussing.  The objections were mainly "can't the VFS
>> do this for us?" and the answer, upon closer inspection, turned out to
>> be "not easily, no, the VFS takes option flags instead of parsing string
>> options so doesn't have some necessary infrastructure".
> 
> The only reasonable use case I can imagine for this feature is one
> where someone wants to use a removable storage device (which could be
> a USB thumb drive to a USB HDD to a SSD in a USB 3.0 enclosure) as an
> interchange device between Unix systems which do not have compatible
> uid/gid spaces.


How is that ext* special? You said "Unix systems" there are lots more
FSs more common to "Unix" systems

> 
> So perhaps the right approach is that we should have an ext2/3/4
> read-only feature flag which enforces a default of nosuid and all
> files to be read-only and world-readable.  There would be mount
> options which could modify this default behaviour so that the files
> could be writeable by a particular uid or gid, and another mount
> option which would change the permission bits seen for that file
> system from 0755/0644 for directories/files to 0700/0600.
> 
> Basically, the idea is we should mark the file system in an explicit
> way that it is intended for interchange across incompatible uid/gid
> spaces, with defaults which minimize security risk.  The fact that all
> files become world-readable is potentially a risk, but if the user is
> willing to put their private files on a removeable media that could
> easily be dropped in a parking lot, or otherwise stolen or lost,
> that's a potential risk that they've implicitly accepted in any case;
> we might as well make it be explicit.


They can make that explicit by formatting as vfat or ntfs, fully
interchangeable not only on "Unix".

Or by doing the proper copy when filling up the media in the
first place.

As a maintainer of ext4 filesystem which is the official system for
Linux in many distrows, still. Please resists any such crap.
User "convenience-vs-security was never a geol of Unix.

> 
> 							- Ted


Please, for your own peace of mind, in an historical perspective,
don't do this

Boaz

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