linux-hotplug.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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



  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).