linux-kernel - Re: [PATCH][RFC] Simple tamper-proof device filesystem.

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:	Wed, 09 Jan 2008 15:26:31 +0900
From:	Tetsuo Handa <penguin-kernel@...ove.sakura.ne.jp>
To:	Valdis.Kletnieks@...edu
Cc:	linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org,
	serue@...ibm.com
Subject: Re: [PATCH][RFC] Simple tamper-proof device filesystem.

Hello.

Valdis.Kletnieks@...edu wrote:
> Good summary - probably should add that to the patch, drop it into
> Documentation/syaoran-config.txt or similar...
I see.

> Modification while reading *is* an issue, but can probably be worked around
> with some clever locking.  The race condition I was thinking of was if you
> had the mount and the policy load be 2 separate events, you could see:
> 
> (a) issue mount request
>                         (b) do something malicious in /dev while..
> (c) load the policy that would have prevented (b).
> 
> This is partly why SELinux has init load the policy *very* early on, before
> any other userspace have had a chance to run and do things that would have
> been prevented by policy.
So, you suggested to load policy before mount() request so that
this filesystem can prevent attackers from doing something malicious
by minimizing (i.e. implement as non-blocking operation) the latency
between the userland process's call of mount() and the nodes become visible
to userland process.

I didn't take such cases into account.
My assumed usage of this filesystem is that run a script with

 #!/bin/sh
 mount -t syaoran -o accept=/etc/ccs/syaoran.conf none /dev
 exec /sbin/init "$@"

by passing "init=/path/to/this/script" to the kernel command line
so that /sbin/init can create /dev/initlog on this filesystem.
If you mount this filesystem after /sbin/init starts,
it will shadow /dev/initctl opened by /sbin/init .

> Which basically ends up meaning that anybody who can trick the mount into
> happening can reset the permitted list and create (for example) a mode 666
> entry for a hard drive, and go scribbling around at will.  Note that you
> don't seem to do any sanity checking on the path (for instance, that each
> component is owned by root, and not world-writable) - so anybody who finds
> a way to get the mount to happen can supply their own list in /home/joeuser/blat
> or /tmp/surprise-mount-list  or wherever.
I assume that being able to reach this location means the caller of mount() is root.
But, the patches to allow mount() by non-root is in progress? http://lkml.org/lkml/2008/1/8/131
May be I should add some sanity checking on the path.

Thank you.
--
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/