> Random PIDs > Eliminates race conditions > Say you have a root daemon that forks then the child drops privileges. If you can beat the child you can inherit root privileges Can someone explain this? I don't see what this has to do with the randomness of pids.
Seems an extra layer in defence in depth, making it harder to attack a process between the time it is forked and the time it has dropped privileges by making it harder to find it.
Slightly off topic, but does anybody know why the OpenBSD community has started using Comic Sans in all their material? Is it some kind of inside joke? I don't find it neither good nor wrong, but there must be some reason behind it.
There was another discussion about it recently on HN, which linked to this:
Slightly off topic, but does anybody know why the OpenBSD community has started using Comic Sans in all their material? Is it some kind of inside joke? I don't find it neither good nor wrong, but there must be some reason behind it.
I remember Bob Beck saying it was one of the three fonts that works with MagicPoint and the one that is most readable on projector.
Slightly off topic, but does anybody know why the OpenBSD community has started using Comic Sans in all their material? Is it some kind of inside joke? I don't find it neither good nor wrong, but there must be some reason behind it.
I think it's just the OpenBSD crew having fun by watching people cringe.
Slightly off topic, but does anybody know why the OpenBSD community has started using Comic Sans in all their material? Is it some kind of inside joke? I don't find it neither good nor wrong, but there must be some reason behind it.
I think it's more fun to consider the widespread "hate" of comic sans, and considering whether it is really "bad" or just band-wagoning.
> Proactive security ●64-bit long long time_t (NetBSD technically did it first) The best kind of first. Joking aside -- why is so much OpenBSD advocacy backhanded like this ? Do the writers not think that OpenBSD can stand on it's own ?
Actually this is not quite right.
Pkgsrc pushes fixes upstream for all breakage, including the 64bit long long time_t. We just weren't born on third base thinking we scored a triple.
> Proactive security ●64-bit long long time_t (NetBSD technically did it first) The best kind of first. Joking aside -- why is so much OpenBSD advocacy backhanded like this ? Do the writers not think that OpenBSD can stand on it's own ?
And if they didn't mention it others would be here complaining that NetBSD did it first and OpenBSD is just trying to take credit.
And they will copy UBC, uvm locks, WAPBL, device abstraction layer. Just diff their kernel source to 4.3BSD and compare how close they are still. Their kernel is still stuck in the 80s.
> Random PIDs > Eliminates race conditions > Say you have a root daemon that forks then the child drops privileges. If you can beat the child you can inherit root privileges Can someone explain this? I don't see what this has to do with the randomness of pids.
Being the most secure OS, these days, is like being valedictorian of summer school.
The reality is as soon as you install a dynamic language behind a webserver all their memory tricks are for not.
They are still focusing on exploitation from 2002.
> Random PIDs > Eliminates race conditions > Say you have a root daemon that forks then the child drops privileges. If you can beat the child you can inherit root privileges Can someone explain this? I don't see what this has to do with the randomness of pids.
Something like after the parent forks, the child opens a file called "/tmp/log.$$" with its PID in the name as root. If you can guess the PID of the child, you could create a link with that name, pointing at a file of your choice that is owned by root, such as "/etc/passwd". Then, you need to make the child do something predictable to that file, such as ensuring that the user supplied data being logged contains text like "\npwn::0:0::/:/bin/sh\n" giving you a valid password file entry for "pwn" with no password and root privileges.