> can anyone tell me wtf I'm missing in the commands below?
> 
> # mkdir foo
> # cd foo
> # mkdir bin dev
> # cp -p /bin/cat bin
> # cd dev
> # /dev/MAKEDEV std
> # cd ..
> # chroot . /bin/cat /dev/stdin
> cat: /dev/stdin: Device not configured
> 
> The reason I ask is that I need to run tar -czf within a chroot
> environment, but gzip(1) tries to open /dev/stdin and fails (as the
> contrived invocation of cat(1) in the example above).

A few comments.

/dev/stdin is not apart of POSIX.  It is not required that it even
work.  And after a recent security fix, it does not work like people
think it does.

Secondly your process running inside the chroot space is potentially
tainted.  It has a "past" which contains different uid's and gid's or
such, see "man issetugid".  In such a situation of "taintedness", even
POSIX rules does not apply, and OpenBSD asserts a variety of security
measures.  Most are invisible, as in, some are now nearly 10 years old
and noone has ever noticed.  Setuid/setgid programs operate under
greater constraints.

Thirdly, we have recently added some security code to prevent a
problem with /dev/fd/# (and thus /dev/stdin and friends) which could
be a problem.

Regarding our solution, I was positively laughing when I saw that
Secunia and other similar sites/lists called it an OpenBSD-only
problem, when every other operations system has this problem.  Mapping
fd#'s to device filenames is fundamentally a very stupid idea --
people often ignore the consequences of the conveniences they build.
Thus, even though everyone has the problem, only OpenBSD has
prevention for it.  EVERYONE ELSE STILL HAS THE BUG.  (That said, I
did a couple of hours of reading our tree and found no setuid/setgid
programs or daemons which would exercise the bug.  So we basically
removed the backbone of an insecure mechanism, even though we found
nothing which could trigger it.  Some of the convenience had to be
sacrificed since the original designed of /dev/fd and /dev/stdin acted
like an irresponsible retard by not considering the consequences.
Whoever it was, say nearly 20 years ago, they were a very stupid
idiot.)

There were a few minor fallouts from our diffs, in compress/gzip in
particular, but Todd Miller has put some effort into fixing those in
very new code.

For those interested in the actual problem, I will not go further.
Go read the diff and think about what we are trying to do.

Reply via email to