Re: Is randomizing UID/GUID would make sense?
On Fri, 21 Apr 2017 22:39:39 +1000 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 1 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.
Re: Is randomizing UID/GUID would make sense?
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 + (UTC) Christian Weisgerber wrote: > On 2017-04-19, Philip Guenther 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. >
Re: Is randomizing UID/GUID would make sense?
On 2017-04-19, Philip Guenther 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 na...@mips.inka.de
Re: Is randomizing UID/GUID would make sense?
On Tue, Apr 18, 2017 at 10:12 PM, 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
Re: Is randomizing UID/GUID would make sense?
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" 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
Re: Is randomizing UID/GUID would make sense?
> > 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
Re: Is randomizing UID/GUID would make sense?
On Sun, 16 Apr 2017 12:01:48 + (UTC)
Stuart Henderson wrote:
> On 2017-04-15,
> 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.
Re: Is randomizing UID/GUID would make sense?
On 2017-04-15, 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.
Re: Is randomizing UID/GUID would make sense?
On Sat, 15 Apr 2017 23:16:18 -0600 "Theo de Raadt" wrote: > > Responding to multiple messages: > > > > On Fri, 20 Jan 2017 08:43:46 +0100 > > "minek van" 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 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.
Re: Is randomizing UID/GUID would make sense?
> Responding to multiple messages: > > On Fri, 20 Jan 2017 08:43:46 +0100 > "minek van" 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 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.
Re: Is randomizing UID/GUID would make sense?
Responding to multiple messages: On Fri, 20 Jan 2017 08:43:46 +0100 "minek van" 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 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
Re: Is randomizing UID/GUID would make sense?
On Mon, Jan 23, 2017 at 11:00 AM, Martin Schröder 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 and...@fabbro.org
Re: Is randomizing UID/GUID would make sense?
2017-01-23 15:37 GMT+01:00 andrew fabbro : > On Fri, Jan 20, 2017 at 3:44 AM, Martin Schröder wrote: >> 2017-01-20 8:43 GMT+01:00 minek van : >> > 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
Re: Is randomizing UID/GUID would make sense?
On Fri, Jan 20, 2017 at 3:44 AM, Martin Schröder wrote: > 2017-01-20 8:43 GMT+01:00 minek van : > > 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 and...@fabbro.org
Re: Is randomizing UID/GUID would make sense?
2017-01-20 8:43 GMT+01:00 minek van : > 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.
Is randomizing UID/GUID would make sense?
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!
