Is randomizing UID/GUID would make sense?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
16 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Is randomizing UID/GUID would make sense?

minek van
Hello!

I can see that the default users and when creating new ones have their UID/GUID incremented by 1.

Could it bring more security if the UIDs/GUIDs would be random?

Or it wouldn't bring any additional security?

Or something would be broken with random UIDs/GUIDs, ex.: NFS? Would it only do pain?

Thanks for any comments!

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Is randomizing UID/GUID would make sense?

Martin Schröder
2017-01-20 8:43 GMT+01:00 minek van <[hidden email]>:
> Could it bring more security if the UIDs/GUIDs would be random?

Why? What's the attack you want to defend against?

> Or something would be broken with random UIDs/GUIDs, ex.: NFS? Would it only do pain?

Yes.

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Is randomizing UID/GUID would make sense?

andrew fabbro
On Fri, Jan 20, 2017 at 3:44 AM, Martin Schröder <[hidden email]> wrote:

> 2017-01-20 8:43 GMT+01:00 minek van <[hidden email]>:
> > Could it bring more security if the UIDs/GUIDs would be random?
>
> Why? What's the attack you want to defend against?
>

I suppose there's some information leakage in the sense that any given
OpenBSD server is much more likely to have a UID of 1005 than a UID of
10005.  And the first dozen or two lines in /etc/passwd are the same for
every OpenBSD installation.

But is there an arena where an attacker could make effective use of this
information?

If you wanted a different UID/GID for all the service accounts (everything
>0) you're going to have a significantly more complicated
installer...indeed, the whole tarball distro method would need to be
examined.

Random UID/GIDs for user accounts are something an admin could already do
without needing to change anything - just pick random numbers for the
adduser flags.

> Or something would be broken with random UIDs/GUIDs, ex.: NFS? Would it
> only do pain?
>
> Yes.


Not sure about that...it would certainly be a headache to change UIDs/GIDs
if you already have them in place, but for setting up a new server/new
accounts, nfs doesn't care what number you are (well, 0 excepted).  Whether
the algorithm is "last used +1" or arc4random, you have the same
sync/directory problems regardless.  That's for user accounts...service
accounts might need a bit more thought.

So in summary, if you want random UID/GID for user accounts, that's a
one-liner shell script - go for it!  But if you want random UID/GID for
service accounts, I think there would need to be a lot more justification
for what would be a lot more work.

--
andrew fabbro
[hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Is randomizing UID/GUID would make sense?

Martin Schröder
2017-01-23 15:37 GMT+01:00 andrew fabbro <[hidden email]>:
> On Fri, Jan 20, 2017 at 3:44 AM, Martin Schröder <[hidden email]>
wrote:

>> 2017-01-20 8:43 GMT+01:00 minek van <[hidden email]>:
>> > Or something would be broken with random UIDs/GUIDs, ex.: NFS? Would it
>> > only do pain?
>>
>> Yes.
>
> Not sure about that...it would certainly be a headache to change UIDs/GIDs
> if you already have them in place, but for setting up a new server/new
> accounts, nfs doesn't care what number you are (well, 0 excepted).  Whether
> the algorithm is "last used +1" or arc4random, you have the same
> sync/directory problems regardless.  That's for user accounts...service
> accounts might need a bit more thought.

And what if my UID/GUIDs are random on every host and server? Would
nfs handle that?

Best
   Martin

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Is randomizing UID/GUID would make sense?

andrew fabbro
On Mon, Jan 23, 2017 at 11:00 AM, Martin Schröder <[hidden email]> wrote:

> And what if my UID/GUIDs are random on every host and server? Would
> nfs handle that?
>

Sure.  Why not?

But then, I'm only talking about UID/GID selection.  I'm assuming that
jsmith is UID 2000 on every system, regardless of how he got the number.

Now if someone meant using *different* UID/GID on every system and they're
not synchronized...right, that'd be a nightmare.

The OP was just talking about changing from "last +1" to arc4random.
Synchronizing UID/GID across servers (if you're not using a directory of
some sort) is the same headache regardless of how you pick them.

If the OP meant every server has different, unique randomized UID/GIDs then
that's a separate craziness.


--
andrew fabbro
[hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Is randomizing UID/GUID would make sense?

bytevolcano
Responding to multiple messages:

On Fri, 20 Jan 2017 08:43:46 +0100
"minek van" <[hidden email]> wrote:
> I can see that the default users and when creating new ones have
> their UID/GUID incremented by 1.
>
> Could it bring more security if the UIDs/GUIDs would be random?

On Mon, 23 Jan 2017 11:51:29 -0500
andrew fabbro <[hidden email]> wrote:
> The OP was just talking about changing from "last +1" to arc4random.
> Synchronizing UID/GID across servers (if you're not using a directory
> of some sort) is the same headache regardless of how you pick them.
>
> If the OP meant every server has different, unique randomized
> UID/GIDs then that's a separate craziness.

I can see this randomisation making systems management a bit more
difficult as a non-random GUID/UID setup can be used to do things like:

GID 0 = wheel
GID 1-999 = privsep users, daemons, system
GID 1000-32765 = ordinary logins
GID 32766 = nogroup
GID 32767 = nobody

Because the separation is clear and not so random, you can also set up
GIDs/UIDs (1000-32765) permanently across a site where they need to be
static, in the case of logged-in users. Very necessary for backups.

However, the users 1-999 may change depending on what order you install
packages in.

OpenBSD still randomizes PIDs, but I don't see the point these days:
https://security.stackexchange.com/questions/88692/do-randomized-pids-bring-more-security/89961

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Is randomizing UID/GUID would make sense?

Theo de Raadt-2
> Responding to multiple messages:
>
> On Fri, 20 Jan 2017 08:43:46 +0100
> "minek van" <[hidden email]> wrote:
> > I can see that the default users and when creating new ones have
> > their UID/GUID incremented by 1.
> >
> > Could it bring more security if the UIDs/GUIDs would be random?
>
> On Mon, 23 Jan 2017 11:51:29 -0500
> andrew fabbro <[hidden email]> wrote:
> > The OP was just talking about changing from "last +1" to arc4random.
> > Synchronizing UID/GID across servers (if you're not using a directory
> > of some sort) is the same headache regardless of how you pick them.
> >
> > If the OP meant every server has different, unique randomized
> > UID/GIDs then that's a separate craziness.
>
> I can see this randomisation making systems management a bit more
> difficult as a non-random GUID/UID setup can be used to do things like:
>
> GID 0 = wheel
> GID 1-999 = privsep users, daemons, system
> GID 1000-32765 = ordinary logins
> GID 32766 = nogroup
> GID 32767 = nobody
>
> Because the separation is clear and not so random, you can also set up
> GIDs/UIDs (1000-32765) permanently across a site where they need to be
> static, in the case of logged-in users. Very necessary for backups.
>
> However, the users 1-999 may change depending on what order you install
> packages in.
>
> OpenBSD still randomizes PIDs, but I don't see the point these days:
> https://security.stackexchange.com/questions/88692/do-randomized-pids-bring-more-security/89961


Sorry you lost me.

I can't tell if you are supporting a useless idea, or declaring that a
useless idea is not worth supporting.

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Is randomizing UID/GUID would make sense?

bytevolcano
On Sat, 15 Apr 2017 23:16:18 -0600
"Theo de Raadt" <[hidden email]> wrote:

> > Responding to multiple messages:
> >
> > On Fri, 20 Jan 2017 08:43:46 +0100
> > "minek van" <[hidden email]> wrote:  
> > > I can see that the default users and when creating new ones have
> > > their UID/GUID incremented by 1.
> > >
> > > Could it bring more security if the UIDs/GUIDs would be random?  
> >
> > On Mon, 23 Jan 2017 11:51:29 -0500
> > andrew fabbro <[hidden email]> wrote:  
> > > The OP was just talking about changing from "last +1" to
> > > arc4random. Synchronizing UID/GID across servers (if you're not
> > > using a directory of some sort) is the same headache regardless
> > > of how you pick them.
> > >
> > > If the OP meant every server has different, unique randomized
> > > UID/GIDs then that's a separate craziness.  
> >
> > I can see this randomisation making systems management a bit more
> > difficult as a non-random GUID/UID setup can be used to do things
> > like:
> >
> > GID 0 = wheel
> > GID 1-999 = privsep users, daemons, system
> > GID 1000-32765 = ordinary logins
> > GID 32766 = nogroup
> > GID 32767 = nobody
> >
> > Because the separation is clear and not so random, you can also set
> > up GIDs/UIDs (1000-32765) permanently across a site where they need
> > to be static, in the case of logged-in users. Very necessary for
> > backups.
> >
> > However, the users 1-999 may change depending on what order you
> > install packages in.
> >
> > OpenBSD still randomizes PIDs, but I don't see the point these days:
> > https://security.stackexchange.com/questions/88692/do-randomized-pids-bring-more-security/89961 
>
>
> Sorry you lost me.
>
> I can't tell if you are supporting a useless idea, or declaring that a
> useless idea is not worth supporting.
>

The latter. In this case I don't think UIDs/GIDs benefit from being
random for the above reasons.

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Is randomizing UID/GUID would make sense?

Stuart Henderson
In reply to this post by bytevolcano
On 2017-04-15, <[hidden email]> <[hidden email]> wrote:
> OpenBSD still randomizes PIDs, but I don't see the point these days:
> https://security.stackexchange.com/questions/88692/do-randomized-pids-bring-more-security/89961

  'Protect against PID prediction vulnerabilities affecting mostly
   software which use the PID value to generate temporary file names.
   This was a common concern at that time, but today I think it would
   be quite rare to encounter production-level software still not
   using a proper method.'

Between some of the less common software that is still used, and various
sysadmin shell scripts people might have around, I don't think it's all
that unlikely.

  'A PID is not designed to seed a random number generator or generate
   session ID or cookies.'

Correct that it's not designed for that. But we looked into this a lot
when introducing srand_determinstic(3). It's still *very* common to seed
based on pid, time, or a combination of the two, either as the main
method, or as a fallback if /dev/urandom can't be opened (as may happen
as a result of FD exhaustion [possibly attacker-triggered] or in a chroot
jail).

        t = (unsigned char)getpid();
        while (i < size) {
                do {
                        buf[i] = ((unsigned char)rand()) ^ t;
                } while (buf[i] == 0);
                t = buf[i++] << 1;

The srand_deterministic change makes this less of a problem on OpenBSD
for programs using rand(), but sometimes programs have their own PRNG
and aren't seeding it nicely, any extra protection we can give these
seems useful.

  'As a general preventive measure, "If something can be random, make it
   random."'

With OpenBSD's random subsystem it is intentional to have many
consumers. See http://www.openbsd.org/papers/hackfest2014-arc4random/.
The idea is to slice up the chacha20 (formerly arc4) stream as much
as possible.

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Is randomizing UID/GUID would make sense?

bytevolcano
On Sun, 16 Apr 2017 12:01:48 +0000 (UTC)
Stuart Henderson <[hidden email]> wrote:

> On 2017-04-15, <[hidden email]>
> <[hidden email]> wrote:
> > OpenBSD still randomizes PIDs, but I don't see the point these days:
> > https://security.stackexchange.com/questions/88692/do-randomized-pids-bring-more-security/89961 
>
>   'Protect against PID prediction vulnerabilities affecting mostly
>    software which use the PID value to generate temporary file names.
>    This was a common concern at that time, but today I think it would
>    be quite rare to encounter production-level software still not
>    using a proper method.'
>
> Between some of the less common software that is still used, and
> various sysadmin shell scripts people might have around, I don't
> think it's all that unlikely.
>
>   'A PID is not designed to seed a random number generator or generate
>    session ID or cookies.'
>
> Correct that it's not designed for that. But we looked into this a lot
> when introducing srand_determinstic(3).

Are there any applications out there that explicitly require the PRNG
to be deterministic? It doesn't make sense to have that kind of thing
there for minute corner cases, such as if someone decides it's a
brilliant idea to use the contents of a deterministic PRNG as a hash.

> It's still *very* common to
> seed based on pid, time, or a combination of the two, either as the
> main method, or as a fallback if /dev/urandom can't be opened (as may
> happen as a result of FD exhaustion [possibly attacker-triggered] or
> in a chroot jail).
>
>         t = (unsigned char)getpid();
>         while (i < size) {
>                 do {
>                         buf[i] = ((unsigned char)rand()) ^ t;
>                 } while (buf[i] == 0);
>                 t = buf[i++] << 1;
>
> The srand_deterministic change makes this less of a problem on OpenBSD
> for programs using rand(), but sometimes programs have their own PRNG
> and aren't seeding it nicely, any extra protection we can give these
> seems useful.

Surely looking up a pointer to some have O(n) or O(log n) worst case,
since it has to traverse the list? Quite close for a list full of
random PIDs.

Surely this creates a bit more complacency, "Oh the OS generates random
PIDs anyway, let's use that to seed our RNG." Hopefully such practices
is abolished in favour of more robust methods.

Not suggesting the random PIDs are a bad thing, but I am curious as to
how much extra code and cost is needed to implement this over a
"sequential" PID that's just an index to an array.

>
>   'As a general preventive measure, "If something can be random, make
> it random."'
>
> With OpenBSD's random subsystem it is intentional to have many
> consumers. See http://www.openbsd.org/papers/hackfest2014-arc4random/.
> The idea is to slice up the chacha20 (formerly arc4) stream as much
> as possible.
>

I do like the way this is implemented, and it is well integrated within
the system too.

Shame the function was called arc4random() and not sorandom() or
something. Little too late to change it now though I guess.

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Is randomizing UID/GUID would make sense?

Theo de Raadt-2
> > Correct that it's not designed for that. But we looked into this a lot
> > when introducing srand_determinstic(3).
>
> Are there any applications out there that explicitly require the PRNG
> to be deterministic? It doesn't make sense to have that kind of thing
> there for minute corner cases, such as if someone decides it's a
> brilliant idea to use the contents of a deterministic PRNG as a hash.

It's really unfortunate that we aren't running an open source project
and making available all the source for the tool called grep.

So that it can be studied, rather than questioned by an idiot
uninterested in the exercise of selflearning.

Maybe those source files even have commit logs - even better PUBLIC
COMMIT LOGS - which might explain the rationale!  No, that's unlikely.

So let's just yak about it, right?

Rest of your email deleted because what's the point

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Is randomizing UID/GUID would make sense?

bytevolcano
An idiot whose question lacks clarity. My apologies.

Of course software uses it. What I was trying to ask was *why* would software
actually nee a deterministic PRNG, rather than "what software uses it."
In other words, what will break if the PRNG was non-deterministic?

Yes, it may be "standards mandated" in some cases (r1.39, bin/ksh/var.c) or
used by 60 pieces of software, but why would software require a PRNG to be
deterministic?

That is my question, not "what apps and standards need it?" but "what usage
cases require it, and can this be replaced with a deterministic PRNG?"

On Mon, 17 Apr 2017 23:30:04 -0600
"Theo de Raadt" <[hidden email]> wrote:

> It's really unfortunate that we aren't running an open source project
> and making available all the source for the tool called grep.
>
> So that it can be studied, rather than questioned by an idiot
> uninterested in the exercise of selflearning.
>
> Maybe those source files even have commit logs - even better PUBLIC
> COMMIT LOGS - which might explain the rationale!  No, that's unlikely.
>
> So let's just yak about it, right?
>
> Rest of your email deleted because what's the point


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Is randomizing UID/GUID would make sense?

Philip Guenther-2
On Tue, Apr 18, 2017 at 10:12 PM,  <[hidden email]> wrote:
...
> Yes, it may be "standards mandated" in some cases (r1.39, bin/ksh/var.c) or
> used by 60 pieces of software, but why would software require a PRNG to be
> deterministic?
>
> That is my question, not "what apps and standards need it?" but "what usage
> cases require it, and can this be replaced with a deterministic PRNG?"

The classic case is code that wants to offer the ability to reproduce
the sequence, so that the state *before* some interesting state can be
examined.  For example, fuzzers often report the seed that generated a
crash, so you can reenter it and walk the target program into the
crash step by step.  If a program offers a "set the seed" option then
that's a huge hint.  If you think that option doesn't make sense for
some program then that's a concern to take to the developer *of that
program*...

For a broader answer to the "why?", take a look at the patches under
/usr/ports/ which add uses of the *_deterministic() calls.  Some
OpenBSD dev in the past judged that that port wanted it and may have
recorded why they thought so in the patch or the commit message of the
patch.  Lacking that, go look at the ports' sources and see what might
indicate that.


Philip Guenther

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Is randomizing UID/GUID would make sense?

Christian Weisgerber
On 2017-04-19, Philip Guenther <[hidden email]> wrote:

> For a broader answer to the "why?", take a look at the patches under
> /usr/ports/ which add uses of the *_deterministic() calls.

For instance, take graphics/netpbm and look at its multitude of
image manipulation tools that take a -randomseed=integer argument
to ensure that the same result can be obtained on separate invocations.

--
Christian "naddy" Weisgerber                          [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Is randomizing UID/GUID would make sense?

bytevolcano
Thanks for the start points, Christian and Philip.
I would have never thought about those use cases.
I'll definitely look into this further.

On Wed, 19 Apr 2017 13:31:08 +0000 (UTC)
Christian Weisgerber <[hidden email]> wrote:

> On 2017-04-19, Philip Guenther <[hidden email]> wrote:
>
> > For a broader answer to the "why?", take a look at the patches under
> > /usr/ports/ which add uses of the *_deterministic() calls.  
>
> For instance, take graphics/netpbm and look at its multitude of
> image manipulation tools that take a -randomseed=integer argument
> to ensure that the same result can be obtained on separate
> invocations.
>

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Is randomizing UID/GUID would make sense?

Kevin Chadwick-4
On Fri, 21 Apr 2017 22:39:39 +1000
<[hidden email]> wrote:

> Thanks for the start points, Christian and Philip.
> I would have never thought about those use cases.
> I'll definitely look into this further.

I rewrote some code for key generation for particular memory
handling/protection reasons and it certainly provides some extra
confidence to yourself and/or other if you find your implementation and
four others all produce the same 10000 outputs with the same repeatable
but random looking inputs. Usually specific and well chosen test vectors
are available, but not always.

I did have a cry/laugh at the function name of the deterministic
"random" generator in mbedtls though and reminding me of the OpenBSD
commentry on them. Unfortunately I forget the details of what was
particularly alarming/funny though.

Loading...