From: Luca Barbieri <luca.barbieri@gmail.com>
To: Al Viro <viro@zeniv.linux.org.uk>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
Alan Cox <alan@lxorguk.ukuu.org.uk>, Ingo Molnar <mingo@elte.hu>,
James Morris <jmorris@namei.org>,
linux-kernel@vger.kernel.org, Kyle McMartin <kyle@mcmartin.ca>,
Alexander Viro <viro@ftp.linux.org.uk>
Subject: Re: Upstream first policy
Date: Tue, 9 Mar 2010 02:51:55 +0100 [thread overview]
Message-ID: <ff13bc9a1003081751s535fbf71l9d261b303587b23a@mail.gmail.com> (raw)
In-Reply-To: <20100309012552.GR30031@ZenIV.linux.org.uk>
>> 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.
next prev parent reply other threads:[~2010-03-09 1:52 UTC|newest]
Thread overview: 51+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-03-07 21:23 Upstream first policy James Morris
2010-03-07 21:31 ` Linus Torvalds
2010-03-07 21:36 ` Linus Torvalds
2010-03-08 9:46 ` Ingo Molnar
2010-03-08 17:30 ` Alan Cox
2010-03-08 18:08 ` Linus Torvalds
2010-03-08 18:45 ` Al Viro
2010-03-08 18:53 ` Al Viro
2010-03-08 18:59 ` Linus Torvalds
2010-03-08 19:15 ` Linus Torvalds
2010-03-08 19:17 ` Alan Cox
2010-03-08 19:32 ` Linus Torvalds
2010-03-09 0:48 ` Kyle McMartin
2010-03-08 21:20 ` Chris Adams
2010-03-08 19:18 ` Al Viro
2010-03-09 1:18 ` Luca Barbieri
2010-03-09 1:25 ` Al Viro
2010-03-09 1:51 ` Luca Barbieri [this message]
2010-03-09 1:55 ` Al Viro
2010-03-09 2:09 ` Luca Barbieri
2010-03-08 19:08 ` Alan Cox
2010-03-08 19:18 ` Linus Torvalds
2010-03-08 19:27 ` Alan Cox
2010-03-08 19:34 ` Linus Torvalds
2010-03-09 7:29 ` Ingo Molnar
2010-03-09 8:46 ` Dave Airlie
2010-03-09 14:58 ` Ulrich Drepper
2010-03-08 23:02 ` Eric W. Biederman
2010-03-08 23:18 ` Eric Paris
2010-03-09 15:16 ` Florian Mickler
2010-03-09 22:49 ` Alan Cox
2010-03-11 3:52 ` Eric W. Biederman
2010-03-08 22:12 ` Ulrich Drepper
2010-03-08 23:12 ` Eric Paris
2010-03-08 23:21 ` Linus Torvalds
2010-03-08 23:18 ` Rik van Riel
2010-03-08 23:37 ` Linus Torvalds
2010-03-08 23:51 ` Rik van Riel
2010-03-09 0:10 ` Linus Torvalds
2010-03-09 3:26 ` Casey Schaufler
2010-03-09 3:58 ` Linus Torvalds
2010-03-09 13:09 ` Samir Bellabes
2010-03-09 0:15 ` Al Viro
2010-03-09 0:48 ` Al Viro
2010-03-09 1:49 ` Linus Torvalds
2010-03-09 2:05 ` Al Viro
2010-03-09 2:18 ` Linus Torvalds
2010-03-23 13:59 ` Pavel Machek
[not found] <elwcV-406-1@gated-at.bofh.it>
[not found] ` <elHL4-42q-5@gated-at.bofh.it>
[not found] ` <elP5U-6Ku-29@gated-at.bofh.it>
[not found] ` <elPyV-7zE-7@gated-at.bofh.it>
[not found] ` <elQbE-8ll-7@gated-at.bofh.it>
[not found] ` <elQv0-vu-13@gated-at.bofh.it>
[not found] ` <elQEG-Hn-33@gated-at.bofh.it>
2010-03-08 19:40 ` James Kosin
-- strict thread matches above, loose matches on Subject: below --
2010-03-04 18:39 [git pull] drm request 3 Jesse Barnes
2010-03-04 18:51 ` Linus Torvalds
2010-03-04 18:56 ` Jesse Barnes
2010-03-04 19:08 ` Linus Torvalds
2010-03-04 19:25 ` Dave Airlie
2010-03-04 20:01 ` Linus Torvalds
2010-03-04 22:06 ` Dave Airlie
2010-03-05 0:08 ` Linus Torvalds
2010-03-05 0:28 ` Ben Skeggs
2010-03-05 0:41 ` Linus Torvalds
2010-03-05 1:19 ` Upstream first policy Kyle McMartin
2010-03-05 1:28 ` Linus Torvalds
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ff13bc9a1003081751s535fbf71l9d261b303587b23a@mail.gmail.com \
--to=luca.barbieri@gmail.com \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=jmorris@namei.org \
--cc=kyle@mcmartin.ca \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=torvalds@linux-foundation.org \
--cc=viro@ftp.linux.org.uk \
--cc=viro@zeniv.linux.org.uk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).