linux-kernel - Re: Upstream first policy

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: <ff13bc9a1003081718k1e7964f5ta9e582866dea94ee@mail.gmail.com>
Date:	Tue, 9 Mar 2010 02:18:13 +0100
From:	Luca Barbieri <luca.barbieri@...il.com>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	Al Viro <viro@...iv.linux.org.uk>,
	Alan Cox <alan@...rguk.ukuu.org.uk>,
	Ingo Molnar <mingo@...e.hu>, James Morris <jmorris@...ei.org>,
	linux-kernel@...r.kernel.org, Kyle McMartin <kyle@...artin.ca>,
	Alexander Viro <viro@....linux.org.uk>
Subject: Re: Upstream first policy

I think the point is actually that, ideally, content-based security is
for _reads_, while path-based security is for _writes_:

For example, in the /etc/shadow case:
1. Unprivileged users must not be able to know the _content_ of the
file (or of any copy of it)
2. It doesn't matter at all if anyone modifies a private copy of the
file (with the same content, but not the same path)
3. Unprivileged users must not change the data the /etc/shadow _path_
is associated with
4. It doesn't matter at all if anyone reads a file that happens to be
at /etc/shadow while not containing shadow passwords (with the same
path, but different content)

So I think we should enforce label/inode-based content security on
reads, but we should enforce path/dentry-based security on writes.

In particular, doing a write on a file, and moving a file to that same
path ought to have exactly the same security checks, since the
user-visible effect is the same.

The unix model is broken regarding this, since one will depend on the
write permissions on the file inode, and the other on the directory.
Ideally, both should depend on the write permissions of the _dentry_
(there would need to be a concept of default dentry permissions for a
directory).

The only thing that breaks this are hard links, since they allow to
change the data associated with multiple unknown dentries in a single
operation. However, completely disallowing writes to inodes with
multiple links solves the problem, and shouldn't require fundamental
(or any) userspace changes (of course, this is to be done by the
security module, not by the generic vfs).
--
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/