[9fans] What's up with $home? And a security question.

[Stuart Morrow]

I'd like to dedicate this email to all the programs that don't know
how to expand environment variables.

See*, $path is no longer in the environment (more or less): it's a
union of all the relevant executables at a known place: /bin.

What's a good reason for your home to be in the environment instead of
the namespace? I can see no problem with letting "me" (say) be a
reserved name so that "/usr/me" can be assumed to always point to the
home you want. ""'s denote literal values here by the way. I'm
talking about /usr/me being a bind to /usr/stuart.

You'd lose your home after certain types of rforks but then the same
is true for a home in the environment.

* - that's my trick for avoiding having to put a capital letter in a
command- or other case sensitive token-name just because it's at the
start of a sentence. That pisses me off in computer documentation so
much.

My other question is: what's the security implications of cpu? You
get to do processes on the remote box, but then they also get to have
filesystem access on yours. Does this not worry anyone? Security is
really the hard thing for me to understand in Plan 9.

Stuart

[andrey mirtchovski]

i think you're misunderstanding what private namespaces do, but rather
than explain why nobody else can see your 'local filesystem' when
you've cpu-ed somewhere, i'll simply suggest that you use con(1) and
rx(1) instead of the cpu command. et viola ;)

[Stuart Morrow]

Post by andrey mirtchovski
i think you're misunderstanding what private namespaces do,

Fuck, yes. Sorry. The idea seemed so perfect in my mind, and so
"obvious" that it didn't seem necessary to actually test it.

Post by andrey mirtchovski
but rather than explain why nobody else can see your 'local filesystem' when
you've cpu-ed somewhere

I should say I'm thinking of cases where the listener for cpu has been
modified or replaced by a malicious one that knows how to do that
stuff. Export its /mnt/term outside of its private namespace for
other programs to see.

[andrey mirtchovski]

if the plan9 kernel has been compromised the privacy of namespaces
goes out the window. pwned systems can't be trusted. just like
everywhere else.

by the way, as to your original inquiry regarding /usr/me, note that
/tmp on all plan9 installations already works that way -- it's
/usr/$user/tmp bound to /tmp for each independent user, so no two
users have to step on each other's toes (for comparison, try to get
root to do anything to a file in /tmp not owned by it on a "modern"
linux system). creating an empty /usr/me and binding your home dir
there at login is just about the least amount of abuse you can cause
with user binds and private namespaces.

by the way, $home is /env/home in reality. the shell is just being
nice and accommodating with our preconceptions.

[Stuart Morrow]

I know that about /tmp. I know devenv too. By the way, have you ever
noticed that the *env libc functions only allow accesses to env files
with names of length 100 - strlen("/env/") - sizeof '\0', while rc
allows names of up to 256 characters? I'm not too concerned about
that one, just saying it's inconsistent. Rio is hardcoded for a
maximum of 100 windows and I don't think anyone's ever had a problem.

A more realistic one is: rc doesn't go out to /env every time a
variable is accessed. If they're changed underfoot the only way rc
can see them is if you start up a new rc (like the rc under EXAMPLES
in pipefile(1))

What's the reason for this, just speed? It seems weird to me that a
Plan 9 program would do something "intelligent" like that (and
therefore less predictable, like ls's that do isatty on /fd/1).

[Federico G. Benavento]

Post by Stuart Morrow
A more realistic one is: rc doesn't go out to /env every time a
variable is accessed. If they're changed underfoot the only way rc
can see them is if you start up a new rc (like the rc under EXAMPLES
in pipefile(1))

I'm failing to see how that man page is relevant to this, the env variables
issue is related to the rfork(2) flag as well.

---
Federico G. Benavento
***@gmail.com

[Stuart Morrow]

Sorry. What I meant was that rc's already-open file descriptors for
the pipefile'd file aren't affected by the bind, so for an rc to be
affected you need to run a new one. I saw this as being analogous to
how it sees environment variables.

I'm not interested in environment variables anyway, it's just that I
was "accused" of not knowing how they work for a moment.

(The reason "accused" is in quotes is that I can't think of a better
word right now - Andrey is the nicest person on 9fans.)

Stuart

[andrey mirtchovski]

Post by Stuart Morrow
(The reason "accused" is in quotes is that I can't think of a better
word right now - Andrey is the nicest person on 9fans.)

gee, thanks! mind if i quote this from now on?

[Stuart Morrow]

So I read in New Scientist one time that being awake for more than a
certain amount of hours is the same as being lightly drunk.

I shouldn't be on the Internet at all really right now.

[Bruce Ellis]

drink

Post by Stuart Morrow
So I read in New Scientist one time that being awake for more than a
certain amount of hours is the same as being lightly drunk.
I shouldn't be on the Internet at all really right now.

[Matthew Veety]

I almost agree with Bruce. Best course of action is alcoholism.

drink

Post by Stuart Morrow
So I read in New Scientist one time that being awake for more than a
certain amount of hours is the same as being lightly drunk.
I shouldn't be on the Internet at all really right now.

[Bruce Ellis]

i was thinkimg more of combating lack of sleep by using strongdrink(3) -
which eventually calls sleep(2). its on the strchr(3) page just before
strumpet.

[steve]

quick,

just agree with him...
you haven't met mr Hyde-chovski have you?

:-)

-Steve

Post by andrey mirtchovski

Post by Stuart Morrow
(The reason "accused" is in quotes is that I can't think of a better
word right now - Andrey is the nicest person on 9fans.)

gee, thanks! mind if i quote this from now on?

[c***@gmx.de]

cpu and exportfs accept a pattern file (-P) option.

with this, you can make cpu export only the namespace parts that
you want to give the cpu server access to.

the difficulty lies in how to decide what you want to export and
still keep cpu usefull. if you really assume a compromized cpu
server, then you cant really export anything but /dev/cons.
(and even then, he can trick you and make the cpu session look
like it errored out, but you'r really on the cpu server and he
will then try to capture your keystrokes to get the password).

i would be interested to hear from someone who thought about this
and made up some good conventions that work.

for now, i would suggest not to cpu into machines that you
do not trust. but its hard to know who you can trust and even
then, machines might have been hacked without the knowledge
of the owner.

--
cinap

[Erik Quanstrom]

When do you expect environment variables to change underfoot?

- erik

Post by Stuart Morrow
I know that about /tmp. I know devenv too. By the way, have you ever
noticed that the *env libc functions only allow accesses to env files
with names of length 100 - strlen("/env/") - sizeof '\0', while rc
allows names of up to 256 characters? I'm not too concerned about
that one, just saying it's inconsistent. Rio is hardcoded for a
maximum of 100 windows and I don't think anyone's ever had a problem.
A more realistic one is: rc doesn't go out to /env every time a
variable is accessed. If they're changed underfoot the only way rc
can see them is if you start up a new rc (like the rc under EXAMPLES
in pipefile(1))
What's the reason for this, just speed? It seems weird to me that a
Plan 9 program would do something "intelligent" like that (and
therefore less predictable, like ls's that do isatty on /fd/1).

[Stuart Morrow]

Post by Erik Quanstrom
When do you expect environment variables to change underfoot?

I wouldn't. Just because something stupid _can_ happen doesn't mean
it _should_ (you can tab through form fields instead of using the
mouse, but then you lose the ability to type a tab...)

But I guessed someone else might make use of the possibility - rc's
version of rfork knows about the environment flag to rfork() for a
reason, does it not?

All that environment stuff was sort of peripheral to my main question
anyway; I don't care.

Stuart

[a***@9srv.net]

Cinap mostly covered this, but yeah: if you don't trust the
system you're connecting to, cpu isn't really safe[1]. But
then, neither is anything else: even the simplest service
(say, telnet) can be trivially bugged with things like key
loggers if the remote side's untrustworthy.

If you've not read it, you (and everyone else in CS) should
read "Reflections on Trusting"[1], by Ken Thompson,
describing how he bugged the login program and then
made it roughly undetectable. Things like cpu's -P can
help in a sense, but at some point it comes down to
trusting the humans on the remote end.

[1] http://cm.bell-labs.com/who/ken/trust.html

[Bruce Ellis]

if you can't trust a cpu server don't use it. applies to carbon based
life-forms too.

Post by a***@9srv.net
Cinap mostly covered this, but yeah: if you don't trust the
system you're connecting to, cpu isn't really safe[1]. But
then, neither is anything else: even the simplest service
(say, telnet) can be trivially bugged with things like key
loggers if the remote side's untrustworthy.
If you've not read it, you (and everyone else in CS) should
read "Reflections on Trusting"[1], by Ken Thompson,
describing how he bugged the login program and then
made it roughly undetectable. Things like cpu's -P can
help in a sense, but at some point it comes down to
trusting the humans on the remote end.
[1] http://cm.bell-labs.com/who/ken/trust.html

[Charles Forsyth]

"My other question is: what's the security implications of cpu? You
get to do processes on the remote box, but then they also get to have
filesystem access on yours. "

If you don't entirely trust the cpu server, you *should* export a name
space from your terminal,
limit the processes on the cpu server to just that name space, be careful
what's in that space, including how
you've set permissions, and which user is doing the export. That way, your
terminal (which is under
your control, allowing for SMI, BIOS, UEFI, bugs ...) acts as the reference
monitor to your files. It's also easy to make a 9P filter that ensures
read-only access on an arbitrary 9P connection, so that even if permissions
are wrong, permanent
damage is prevented. It's just a few dozen lines, much of that boilerplate.
I say "terminal" above,
but it applies to any device or your own servers that connect to the
untrusted server.

Ordinarily, the cpu server has access to files and devices at /mnt/term,
but you control that access at the terminal.
On the cpu server itself, however, for the cpu server to access your files
directly from the file server, when you
first mount /srv/boot to form the root of a name space on the cpu server,
you normally give the server implicit permission to speak for you to the
file server
in all subsequent transactions from that mount point, because it is
multiplexing the requests of many users
on that same connnection, and you trust that it won't (say) deviously or
carelessly allow another
user's process to access a fid that you've Tauth'd and Tattach'd, giving
full access as you to all your files,
perhaps long after you've disconnected.