* Re: [9fans] What's up with $home? And a security question. [not found] <CABB-WO9gegFWirXjQhAK0g9vNHn=W2+vwC+bTvRcRDw7xs096g@mail.gmail.c> @ 2013-02-24 13:29 ` a 2013-02-25 8:49 ` Bruce Ellis 0 siblings, 1 reply; 19+ messages in thread From: a @ 2013-02-24 13:29 UTC (permalink / raw) To: 9fans 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 ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [9fans] What's up with $home? And a security question. 2013-02-24 13:29 ` [9fans] What's up with $home? And a security question a @ 2013-02-25 8:49 ` Bruce Ellis 2013-02-25 11:56 ` Charles Forsyth 0 siblings, 1 reply; 19+ messages in thread From: Bruce Ellis @ 2013-02-25 8:49 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs [-- Attachment #1: Type: text/plain, Size: 834 bytes --] if you can't trust a cpu server don't use it. applies to carbon based life-forms too. On 25 February 2013 00:29, <a@9srv.net> wrote: > 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 > > > [-- Attachment #2: Type: text/html, Size: 1269 bytes --] ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [9fans] What's up with $home? And a security question. 2013-02-25 8:49 ` Bruce Ellis @ 2013-02-25 11:56 ` Charles Forsyth 0 siblings, 0 replies; 19+ messages in thread From: Charles Forsyth @ 2013-02-25 11:56 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs [-- Attachment #1: Type: text/plain, Size: 1691 bytes --] "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. [-- Attachment #2: Type: text/html, Size: 2024 bytes --] ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [9fans] What's up with $home? And a security question.
@ 2013-02-24 4:27 Erik Quanstrom
2013-02-24 4:53 ` Stuart Morrow
0 siblings, 1 reply; 19+ messages in thread
From: Erik Quanstrom @ 2013-02-24 4:27 UTC (permalink / raw)
To: Fans of the OS Plan 9 from Bell Labs
When do you expect environment variables to change underfoot?
- erik
Stuart Morrow <morrow.stuart@googlemail.com> wrote:
>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).
>
>
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [9fans] What's up with $home? And a security question. 2013-02-24 4:27 Erik Quanstrom @ 2013-02-24 4:53 ` Stuart Morrow 0 siblings, 0 replies; 19+ messages in thread From: Stuart Morrow @ 2013-02-24 4:53 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs On 24/02/2013, Erik Quanstrom <quanstro@quanstro.net> wrote: > 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 ^ permalink raw reply [flat|nested] 19+ messages in thread
* [9fans] What's up with $home? And a security question. @ 2013-02-24 2:49 Stuart Morrow 2013-02-24 3:05 ` andrey mirtchovski 0 siblings, 1 reply; 19+ messages in thread From: Stuart Morrow @ 2013-02-24 2:49 UTC (permalink / raw) To: 9fans 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 ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [9fans] What's up with $home? And a security question. 2013-02-24 2:49 Stuart Morrow @ 2013-02-24 3:05 ` andrey mirtchovski 2013-02-24 3:43 ` Stuart Morrow 0 siblings, 1 reply; 19+ messages in thread From: andrey mirtchovski @ 2013-02-24 3:05 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs 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 ;) ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [9fans] What's up with $home? And a security question. 2013-02-24 3:05 ` andrey mirtchovski @ 2013-02-24 3:43 ` Stuart Morrow 2013-02-24 3:53 ` andrey mirtchovski 2013-02-24 4:33 ` cinap_lenrek 0 siblings, 2 replies; 19+ messages in thread From: Stuart Morrow @ 2013-02-24 3:43 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs On 24/02/2013, andrey mirtchovski <mirtchovski@gmail.com> wrote: > 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. > 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. ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [9fans] What's up with $home? And a security question. 2013-02-24 3:43 ` Stuart Morrow @ 2013-02-24 3:53 ` andrey mirtchovski 2013-02-24 4:19 ` Stuart Morrow 2013-02-24 4:33 ` cinap_lenrek 1 sibling, 1 reply; 19+ messages in thread From: andrey mirtchovski @ 2013-02-24 3:53 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs 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. ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [9fans] What's up with $home? And a security question. 2013-02-24 3:53 ` andrey mirtchovski @ 2013-02-24 4:19 ` Stuart Morrow 2013-02-24 4:45 ` Federico G. Benavento 0 siblings, 1 reply; 19+ messages in thread From: Stuart Morrow @ 2013-02-24 4:19 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs 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). ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [9fans] What's up with $home? And a security question. 2013-02-24 4:19 ` Stuart Morrow @ 2013-02-24 4:45 ` Federico G. Benavento 2013-02-24 5:06 ` Stuart Morrow 0 siblings, 1 reply; 19+ messages in thread From: Federico G. Benavento @ 2013-02-24 4:45 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs On Feb 24, 2013, at 1:19 AM, Stuart Morrow <morrow.stuart@googlemail.com> wrote: > 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 benavento@gmail.com ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [9fans] What's up with $home? And a security question. 2013-02-24 4:45 ` Federico G. Benavento @ 2013-02-24 5:06 ` Stuart Morrow 2013-02-24 5:10 ` andrey mirtchovski 0 siblings, 1 reply; 19+ messages in thread From: Stuart Morrow @ 2013-02-24 5:06 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs 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 ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [9fans] What's up with $home? And a security question. 2013-02-24 5:06 ` Stuart Morrow @ 2013-02-24 5:10 ` andrey mirtchovski 2013-02-24 5:20 ` Stuart Morrow 2013-02-24 9:31 ` steve 0 siblings, 2 replies; 19+ messages in thread From: andrey mirtchovski @ 2013-02-24 5:10 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs > (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? ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [9fans] What's up with $home? And a security question. 2013-02-24 5:10 ` andrey mirtchovski @ 2013-02-24 5:20 ` Stuart Morrow 2013-02-24 6:24 ` Bruce Ellis 2013-02-24 9:31 ` steve 1 sibling, 1 reply; 19+ messages in thread From: Stuart Morrow @ 2013-02-24 5:20 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs 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. ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [9fans] What's up with $home? And a security question. 2013-02-24 5:20 ` Stuart Morrow @ 2013-02-24 6:24 ` Bruce Ellis 2013-02-24 7:05 ` Matthew Veety 0 siblings, 1 reply; 19+ messages in thread From: Bruce Ellis @ 2013-02-24 6:24 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs [-- Attachment #1: Type: text/plain, Size: 295 bytes --] drink On 24 February 2013 16:20, Stuart Morrow <morrow.stuart@googlemail.com>wrote: > 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. > > [-- Attachment #2: Type: text/html, Size: 612 bytes --] ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [9fans] What's up with $home? And a security question. 2013-02-24 6:24 ` Bruce Ellis @ 2013-02-24 7:05 ` Matthew Veety 2013-02-24 7:14 ` Bruce Ellis 0 siblings, 1 reply; 19+ messages in thread From: Matthew Veety @ 2013-02-24 7:05 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs [-- Attachment #1: Type: text/plain, Size: 445 bytes --] I almost agree with Bruce. Best course of action is alcoholism. On Feb 24, 2013, at 1:24, Bruce Ellis <bruce.ellis@gmail.com> wrote: > drink > > > On 24 February 2013 16:20, Stuart Morrow <morrow.stuart@googlemail.com> wrote: >> 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. > [-- Attachment #2: Type: text/html, Size: 993 bytes --] ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [9fans] What's up with $home? And a security question. 2013-02-24 7:05 ` Matthew Veety @ 2013-02-24 7:14 ` Bruce Ellis 0 siblings, 0 replies; 19+ messages in thread From: Bruce Ellis @ 2013-02-24 7:14 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs [-- Attachment #1: Type: text/plain, Size: 157 bytes --] 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. [-- Attachment #2: Type: text/html, Size: 178 bytes --] ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [9fans] What's up with $home? And a security question. 2013-02-24 5:10 ` andrey mirtchovski 2013-02-24 5:20 ` Stuart Morrow @ 2013-02-24 9:31 ` steve 1 sibling, 0 replies; 19+ messages in thread From: steve @ 2013-02-24 9:31 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs quick, just agree with him... you haven't met mr Hyde-chovski have you? :-) -Steve On 24 Feb 2013, at 05:10, andrey mirtchovski <mirtchovski@gmail.com> wrote: >> (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? ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [9fans] What's up with $home? And a security question. 2013-02-24 3:43 ` Stuart Morrow 2013-02-24 3:53 ` andrey mirtchovski @ 2013-02-24 4:33 ` cinap_lenrek 1 sibling, 0 replies; 19+ messages in thread From: cinap_lenrek @ 2013-02-24 4:33 UTC (permalink / raw) To: 9fans 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 ^ permalink raw reply [flat|nested] 19+ messages in thread
end of thread, other threads:[~2013-02-25 11:56 UTC | newest] Thread overview: 19+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [not found] <CABB-WO9gegFWirXjQhAK0g9vNHn=W2+vwC+bTvRcRDw7xs096g@mail.gmail.c> 2013-02-24 13:29 ` [9fans] What's up with $home? And a security question a 2013-02-25 8:49 ` Bruce Ellis 2013-02-25 11:56 ` Charles Forsyth 2013-02-24 4:27 Erik Quanstrom 2013-02-24 4:53 ` Stuart Morrow -- strict thread matches above, loose matches on Subject: below -- 2013-02-24 2:49 Stuart Morrow 2013-02-24 3:05 ` andrey mirtchovski 2013-02-24 3:43 ` Stuart Morrow 2013-02-24 3:53 ` andrey mirtchovski 2013-02-24 4:19 ` Stuart Morrow 2013-02-24 4:45 ` Federico G. Benavento 2013-02-24 5:06 ` Stuart Morrow 2013-02-24 5:10 ` andrey mirtchovski 2013-02-24 5:20 ` Stuart Morrow 2013-02-24 6:24 ` Bruce Ellis 2013-02-24 7:05 ` Matthew Veety 2013-02-24 7:14 ` Bruce Ellis 2013-02-24 9:31 ` steve 2013-02-24 4:33 ` cinap_lenrek
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).