linux-kernel - Re: [RFC][1/11][MANUX] Kernel compatibility : ext2

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: <20140415222747.GN4456@thunk.org>
Date:	Tue, 15 Apr 2014 18:27:47 -0400
From:	Theodore Ts'o <tytso@....edu>
To:	Emmanuel Colbus <ecolbus@...ux.info>
Cc:	linux-kernel@...r.kernel.org
Subject: Re: [RFC][1/11][MANUX] Kernel compatibility : ext2

On Tue, Apr 15, 2014 at 11:47:56PM +0200, Emmanuel Colbus wrote:
> 
> By the way, just asking : if this is an NFS version field, is the
> content of this field significant when no NFS has ever been used to
> export this filesystem?

No.  But ext4 may end up changing the value of the i_version field,
from one non-zero value to some other non-zero value field.

> My OS heavily uses chroots for security purposes (these are not true
> Linux-like chroots, but this isn't relevant). One of the issues of
> chroots is that one can escape from them, by simply having one process
> open a fd towards a directory, another one move the directory inside a
> second directory located outside of the first process' chroot, and then
> have the first process perform enough fchdir(fd, ".."); or something of
> the like.

If there a process which is out side of the chroot which is
cooperating to help someone breakout of the chroot, that means you
have a bad actor who is outside of the chroot already.  So why bother
worrying about this case?

The more interesting way to break out of a crhoot, which doesn't
require a 2nd process to help you escape, is to chroot while inside a
chroot:

	www.bpfh.net/simes/computing/chroot-break.html

And if you care about this problem, Linux has a much more general
solution using mount namespaces.  FreeBSD has its own a solution
involving restrictions on chroot:

www.freebsd.org/cgi/man.cgi?query=chroot&sektion=2&apropos=0&manpath=FreeBSD+4.0-RELEASE

> Alright, then. Here's what I plan to do :
> - In the short term, I'm going to continue with what I'm currently doing
> with ext2 filesystems, but warn my users against mounting such a
> filesystem in read-write mode if they're also mounting it with ext4 and
> exporting it with NFS;

The main issue is what is the goal of your creating your own OS?  If
it's for your own edication, that's great.  Have fun, it's a great way
to learn.  If you're going to actually try to market this to other
users, you should make sure you understand how much effort it takes to
support a new file system, let alone a new operating system.  Hurd
tried to go down a path somewhat like yours, and it's taken them
years, and the result from a performance point of view is still pretty
bad.  Keep in mind that ext2 has many limitations, including crash
recovery, performance, and scalability.

If you are planning on creating a production quality OS using ext2 as
its base, it does seem a little naive, though.

Regards,

						- Ted
--
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/