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]

Message-ID: <10946.1199855042@turing-police.cc.vt.edu>
Date:	Wed, 09 Jan 2008 00:04:02 -0500
From:	Valdis.Kletnieks@...edu
To:	Tetsuo Handa <penguin-kernel@...ove.SAKURA.ne.jp>
Cc:	linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org,
	serue@...ibm.com
Subject: Re: [PATCH][RFC] Simple tamper-proof device filesystem.

On Tue, 08 Jan 2008 22:50:43 +0900, Tetsuo Handa said:

> Yes. It is a line-by-line processable format defined as:
> 
>   filename permission owner group flags type [ symlink_data | major minor ]
> 
> where flags are bit-wised combinations of
> 
>   *  1: Allow creation of the file.
>   *  2: Allow deletion of the file.
>   *  4: Allow changing permissions of the file.
>   *  8: Allow changing owner or group of the file.
>   * 16: For internal use. Remembers whether this file is opened or not.
>   * 32: Don't create this file at mount time.
> 
> and here are some example entries:
> 
>   pts     755     0       0       0       d

Good summary - probably should add that to the patch, drop it into
Documentation/syaoran-config.txt or similar...

> > the idea of passing a file to be read by the kernel, but I also understand
> > that if it isn't done before mount, you have a race condition betweet the
> > mount and the load.
> What race condition is possible?
> Are you worrying that the file gets modified while reading?

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.  

>> Does this do what you think it does if run in a chroot process or if
>> some creative person does "accept=../../path/to/bad_data.cfg"?
> sys_open() calls open_pathname() with AT_FDCWD.
> So, it is the same thing as calling
> open("../../path/to/bad_data.cfg", O_RDONLY) from the userland.

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.

>> That printk should be KERN_ERR, I think.
> May be. But I think KERN_WARNING is enough because this is not such emergent error.

OK, I can live with WARNING.  You just want to be sure it's above INFO...

Content of type "application/pgp-signature" skipped