From: Mr POSIX <scott@canonical.com>
To: linux-hotplug@vger.kernel.org
Subject: Re: [security] Race condition in udev
Date: Tue, 25 Aug 2009 19:28:38 +0000 [thread overview]
Message-ID: <1251228518.4175.147.camel@quest> (raw)
In-Reply-To: <20090821102407.GA29609@florz.florz.dyndns.org>
On Tue, 2009-08-25 at 20:38 +0200, Florian Zumbiehl wrote:
> Or in more general terms: Well, yeah, there probably are many userspace
> configurations where such permissions would not be a wise thing to use.
> But still, there probably are just as many cases that are perfectly
> safe
>
No, there really isn't.
Let's go back to basics of the UNIX security. model, and most
importantly, how this is *interpreted* by applications.
The model is one of "grant". That is to say, that to be able to perform
any privileged action, you must be granted that privilege.
Even your uid is a "grant" of privilege, it enables you to communicate
and change other processes running under that same uid.
Likewise a gid is a "grant" of privilege.
Therefore there is an assumption that a newly created user, with a
unique uid and gid not used anywhere, has effectively no privilege.
This assumption is used in many places, but most notably when daemons
and services run as a user of their own - or even the "nobody" user.
Your example breaks this assertion. By giving a user or group *less*
privilege than other users, you have effectively granted a privilege to
"nobody" and secure users that genuine users *do not have*.
Put simply, a mask should decrease in value when read from left to right
- 755 is valid, 577 isn't.
Giving a user or group less privilege than "anybody else" is easy to
circumvent, because the basic assumption is that by changing user or
adding a group you are *gaining* privilege. not dropping it - and thus
by switching to a "nobody" user you are *dropping* privilege not gaining
it.
Scott
--
Scott James Remnant
scott@canonical.com
next prev parent reply other threads:[~2009-08-25 19:28 UTC|newest]
Thread overview: 50+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-08-21 10:24 [security] Race condition in udev Florian Zumbiehl
2009-08-21 11:14 ` Kay Sievers
2009-08-21 11:25 ` Florian Zumbiehl
2009-08-21 11:59 ` Kay Sievers
2009-08-22 0:19 ` Florian Zumbiehl
2009-08-22 2:25 ` Bryan Kadzban
2009-08-22 3:11 ` Florian Zumbiehl
2009-08-25 11:32 ` Florian Zumbiehl
2009-08-25 11:58 ` Scott James Remnant
2009-08-25 12:03 ` Kay Sievers
2009-08-25 12:21 ` Florian Zumbiehl
2009-08-25 12:43 ` Scott James Remnant
2009-08-25 12:55 ` Florian Zumbiehl
2009-08-25 13:11 ` Florian Zumbiehl
2009-08-25 13:31 ` Scott James Remnant
2009-08-25 14:22 ` Florian Zumbiehl
2009-08-25 16:08 ` Scott James Remnant
2009-08-25 16:27 ` Florian Zumbiehl
2009-08-25 16:49 ` Scott James Remnant
2009-08-25 17:31 ` Florian Zumbiehl
2009-08-25 17:42 ` Greg KH
2009-08-25 18:04 ` Robby Workman
2009-08-25 18:05 ` Scott James Remnant
2009-08-25 18:11 ` Florian Zumbiehl
2009-08-25 18:17 ` Kay Sievers
2009-08-25 18:20 ` Greg KH
2009-08-25 18:21 ` Greg KH
2009-08-25 18:38 ` Florian Zumbiehl
2009-08-25 18:53 ` Florian Zumbiehl
2009-08-25 19:10 ` Greg KH
2009-08-25 19:28 ` Mr POSIX [this message]
2009-08-25 21:55 ` Florian Zumbiehl
2009-08-26 11:22 ` Scott James Remnant
2009-08-26 17:41 ` Florian Zumbiehl
2009-08-26 21:00 ` Greg KH
2009-08-27 6:54 ` Matthias Schwarzott
2009-08-27 15:09 ` Florian Zumbiehl
2009-08-27 15:13 ` Florian Zumbiehl
2009-08-27 15:22 ` Greg KH
2009-08-27 15:52 ` Florian Zumbiehl
2009-08-27 16:03 ` Florian Zumbiehl
2009-08-28 17:34 ` Florian Zumbiehl
2009-08-29 14:15 ` Kay Sievers
2009-08-29 14:20 ` Florian Zumbiehl
2009-08-29 14:32 ` Kay Sievers
2009-08-29 14:41 ` Florian Zumbiehl
2009-08-29 14:47 ` Kay Sievers
2009-08-29 14:58 ` Florian Zumbiehl
2009-09-04 19:12 ` Florian Zumbiehl
2009-09-04 19:16 ` Florian Zumbiehl
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=1251228518.4175.147.camel@quest \
--to=scott@canonical.com \
--cc=linux-hotplug@vger.kernel.org \
/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).