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: <ff13bc9a1003081751s535fbf71l9d261b303587b23a@mail.gmail.com>
Date:	Tue, 9 Mar 2010 02:51:55 +0100
From:	Luca Barbieri <luca.barbieri@...il.com>
To:	Al Viro <viro@...iv.linux.org.uk>
Cc:	Linus Torvalds <torvalds@...ux-foundation.org>,
	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

>> 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)
>
> What the hell are you smoking?

I mean, what is interesting for security of reading is the fact that
the file contains shadow passwords (and thus is labeled as "secret" or
with a specific label), not that it is at /etc/shadow.

The same security check would need to apply to an administrator's
backup copy of /etc/shadow, but would not need to apply in the
hypotetical case that /etc/shadow did not contain shadow passwords,
but, say, was empty or contained a pointer to a network server to use.

This is to illustrate the point, not something expected to happen; it
also represents the ideal security model, not necessarily any concrete
one.

So what really is interesting for reads is what the content is (in
practice, what the content label is), not the path.

For writes, it is exactly the opposite: you don't care about writing
to a private copy, but you don't want to let a random file be put on a
system path.
For instance, if I copy /etc/passwd somewhere else, the result should
have the same content label (since it is identical), but I should now
be able to write to it since the path allows me to.
--
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/