Re: [9fans] sendfd() on native Plan 9?
On Sat, 2009-01-03 at 18:57 -0500, Nathaniel W Filardo wrote: > That is, if I cannot refer to an object in my namespace and no > server I can refer to will grant access, then I have achieved isolation of > that object and any process running in my namespace. That sounds like a reasonable expectation. > Users make sense for remote services -- it's an excellent mechanism for > reconnecting a principle with its capabilties (nabable objects and > permissions) on a remote server. Ok. So we are in agreement that the model doesn't need to be changed for anything that gets to you through the #M. That leaves all the other drivers in need for a discussion. In fact, if there's more interest in this area -- this looks like a subject worthy of its own thread: fine tuning of the access permissions to the services provided by kernel drivers. > "OS-level virtualization" is only a meaningful concept because, > traditionally, our kernels were not. I want there to be no distinction > between the security guarantees that can be made when one or many kernels > are in flight. Agreed. Unfortunately, in UNIX "one kernel vs. many kernels" requirements can NOT be easily unified. Thus the need for things like Solaris zones. In Plan9, however, I suspect such unification can be made with a very trivial amount of changes to the core system. That's why I'm interested in this discussion to begin with. In fact, why don't we re-frame this discussion (yet another new thread? ;-)) as "what changes (if any) need to be implemented in Plan9 so that there is no distinction between the security guarantees that can be made when one or many kernels are in flight" If nothing else, that would at least increase the practicality level. > Run with me for a moment to see how this might work without the extra level > of grouping. Let's introduce an fdbind() call which takes a fd and a path, > and binds the fd's chan on the path in the current namespace. This is > essentially an optimization around spawning a billion exportfs processes and > mount()ing the resulting descriptors. And as with any optimizations, can we, please, leave it out of the discussion for a while? Since it is *just* and optimization, we can always discuss it later. > Now, suppose '#s' and '#p' -- the > kernel services -- expose only the current process group (==namespace). If > I want different behavior, when I construct the new namespace, I ensure that > I have open fds to my /proc and /srv and fdbind() these in the new namespace > along with '#s' and '#p'. If desired, the new namespaces' '#s' and '#p' can > be posted (or sendfd()'d; see below) to the parent process, doing the > inverse kind of exposure. Ok. So the idea here boils down to partitioning the namespaces that #s and #p serve based on the process groups (as defined by a shared namespace), right? Then, the key problem really seems to be -- what's the best way of unionizing these disjoint sets. If you're willing to keep the old semantics for #s around (may be under a different name) then exportfs doesn't seem to be too prohibitive, does it? > > That said, the requirement itself makes sense. Although, even with > > sendfd() you have to have a socket connection established before you can > > pass fd's around. Except for the case where such socket connection > > was created using socketpair() the sockets are *named* objects. > > And that should present all the same problems that naming files > > under /srv presents, shouldn't it? > > sendfd() is a little special since it uses "out of band structured ancillary > data" (or something like that?) to do its magic. See below. I wasn't talking about ancillary data, I was talking about the point of rendezvous for two processes. In case of UNIX, for unrelated processes, that point of rendezvous has to be a *named* entity. The fact that you can exchange an unlimited amount of descriptors using it, doesn't solve the /tmp-like issues. You're still dealing with namespace collisions, etc. > I've been imaginging sendfd() to be based on a non-enumerable /srv > replacement, where possession of the file name and able to walk to it > suffices to prove access rights to the posted descriptor. These two form a very nice set of requirements. If I were to paraphrase, what you really need is an srv-like device driven via a clone-like interface. > Let's say the protocol is that this magical device serves a ctl file, > into which one writes a fd number and reads back a long, guaranteed unique, Why does it have to be long and not just a sequential id? > string. This string names a file beside the aforementioned ctl file. > Despite being a global service, this can be safely mounted in every namespace > with no information exposure (non-enumerable). Like /srv, it's even possible > and sane to exportfs this (assuming that the clients are willing to trust the > exportfs process). It's possible to emulate /srv atop this by publishing a > list of file names somewhere
Re: [9fans] sendfd() on native Plan 9?
> i suppose you could accuse me of not wanting to change > anything, but it's hard to be in favor of operating system > feng shui. I'll go along with Erik that the #-space should not be restricted. Not because I disagree that it would lead to a cleaner implementation, but because there is too much reliance on it being the way it is. Perhaps the next iteration of Plan 9 can have the cleaner approach and "cd #|" can be deprecated. That said, roll on any good suggestions on where fundamentals need to be revised. There is no harm in regular spring cleaning. Specially if nothing is lost in the process. ++L
Re: [9fans] sendfd() on native Plan 9?
two emails, one response > My personal opinion (which seems to be shared by Erik) is that it > is a slippery slope that can be avoided. I haven't seen the > arguments to the contrary so far. and > > The above seems like a net gain, doesn't it? > pretty much, and then not so much. the current set of exceptions is already somewhat of a consternation. i think it would be good to reduce, not increase exceptions. bandaids won't do that. and will likely break too many things to be popular. to break things and get away with it, you need to provide a real reason to put up with the annoyance. i suppose you could accuse me of not wanting to change anything, but it's hard to be in favor of operating system feng shui. - erik
Re: [9fans] sendfd() on native Plan 9?
On Sun, 2009-01-04 at 20:23 +0200, lu...@proxima.alt.za wrote: > > i haven't even seen what i think is a compelling > > argument for sendfd yet you're trying to argue > > for second-order problems with a particular > > application of sendfd. > > > Sendfd() seems to me a somewhat more carefully controlled version of > /srv. As it stands, the additional features of sendfd() involving > security are not present in /srv, Guys, lets stop talking about security issues. I don't think there are any that need to be worried about. Nathaniel has identified a couple of real issues with the current implementation of /srv so lets focus on those. > so one can make a case for providing sendfd() > or a moral equivalent ^ incoming... ;-) (Sorry, couldn't resit) Thanks, Roman.
Re: [9fans] sendfd() on native Plan 9?
On Sun, 2009-01-04 at 08:43 +0200, lu...@proxima.alt.za wrote: > > Constructing a namespace without RFNOMNT that does not have #s (say) bound > > is not really securing #s (and its other consumers) against that namespace's > > actions. Constructing a namespace with RFNOMNT and without #s bound does > > at least two bad things: > > -> it makes it impossible to pass fds around between processes in this > > namespace, as there is now no /srv backing. > > -> it prohibits import of additional resources. > > > You could have a superserver process that constructs additional > namespace entries as mkdir()s within its own directory hierarchy, > could you not? That was the solution I was trying to hint at in my original email. I still haven't seen Nathaniel's reply to that. > and suddenly find > /dev/superserver/999/hisnamespace for me to mess to my heart's > content. Like you, I'd then find it annoying that RFNOMNT stops me > from abbreviating this as /n/hisnamespace for practical purposes. RFNOMNT does NOT restrict bind(2). Thus you can always do that even in a fully jailed process. > > The claim is that it might be useful to have namespaces where the mount > > table remained open to additional mounts (etc.) but for which the magic > > shortcut and proxy circumvention mechanism of #X was not available. > > In other words, restrict RFNOMNT (obviously by a totally different > name and possibly mechanism) to the #X exception instead of its > current function. Non? My personal opinion (which seems to be shared by Erik) is that it is a slippery slope that can be avoided. I haven't seen the arguments to the contrary so far. Thanks, Roman.
Re: [9fans] sendfd() on native Plan 9?
> i haven't even seen what i think is a compelling > argument for sendfd yet you're trying to argue > for second-order problems with a particular > application of sendfd. > Sendfd() seems to me a somewhat more carefully controlled version of /srv. As it stands, the additional features of sendfd() involving security are not present in /srv, so one can make a case for providing sendfd() (or a moral equivalent, as was originally suggested) in that vacuum. Enhancing /srv is certainly an option, but the exact semantics aren't clear as sendfd() is quite remote from the Plan 9 style of implementing the analogous functionality. While investigating these semantics, Nathaniel merely identified how the combination of #s and RFNOMNT falls short of the desired objectives. > i would think that in order to justify sendfd one would > need to > - have a reasonable implementation of sendfd and > - a useful application that needs it and can't be > implented correctly without it. > it would be more convincing with a paper > that considers other options and makes the > argument for sendfd. I happen to agree with you, but Nathaniel originally specifically asked how the sendfd() functionality could be achieved within the Plan 9 paradigm. We have since digressed in a somewhat tortuous quest for the exact requirements the Plan 9 design would need to satisfy. We are nowhere near a goal yet, because amongst all the discussion a lot of effort has been expended in defending the Plan 9 way instead of concentrating on how it could be enhanced. Part of the problem is that we do not clearly know which problem is being solved, the objectives are still too vague and too caught up with what sendfd() presently does. Personally, I have a feeling that whittling down the objectives for a sendfd() analogue would reveal that very little within Plan 9 actually needs adjustment (a minor alternative to RFNOMNT, perhaps, or factotum-like extensions to lock certain properties of #s). The point is that this mailing list is a good a place to exchange these ideas and some useful clarifications have already taken place. I believe this discussion may be slow, but it is progressive. If enough people feel strongly about it, perhaps it ought to be taken off-list, but I don't believe it should cease just yet (not that I'm accusing anyone of shooting it down, but my comment may suggest that I am). ++L
Re: [9fans] sendfd() on native Plan 9?
> Constructing a namespace without RFNOMNT that does not have #s (say) bound > is not really securing #s (and its other consumers) against that namespace's > actions. Constructing a namespace with RFNOMNT and without #s bound does > at least two bad things: > -> it makes it impossible to pass fds around between processes in this > namespace, as there is now no /srv backing. > -> it prohibits import of additional resources. i think you've got the cart before the horse. i haven't even seen what i think is a compelling argument for sendfd yet you're trying to argue for second-order problems with a particular application of sendfd. i would think that in order to justify sendfd one would need to - have a reasonable implementation of sendfd and - a useful application that needs it and can't be implented correctly without it. it would be more convincing with a paper that considers other options and makes the argument for sendfd. with that in hand, it then would make sense to talk about second-order problems. - erik
Re: [9fans] sendfd() on native Plan 9?
> >> Another aspect I noticed is that what you seem to need is a > >> finer-grained construction of #p and #s, but being able to construct > >> them one layer further down the hierarchy might suffice. > > > > "one layer further down the hierarchy" ? > > > Well, if you could bind a subset of #s by some selection criterion - > specifically process group, but who's to know what else might be > useful? - say, back onto a local /srv, you may have a sensible > mechanism for jailing processes. But I'm once again speculating > outside my knowledge and experience. why not just avoid /srv and #s alltogether? the jailer could do the mounts before starting the prisoner. this way, no access to #s would be required. - erik
Re: [9fans] sendfd() on native Plan 9?
> RFNOMNT has been brought up repeatedly and, while it's certainly better than > nothing, it is too harsh! It simultaneously: > -> restricts access to kernel devices via # paths > -> prevents any and all additional mount requests. > Well, it does only the latter, the first is just a special case. If you see these as different, I think you may have a slightly distorted picture and although it is accurate at this point, it may prove erroneous later. > Constructing a namespace without RFNOMNT that does not have #s (say) bound > is not really securing #s (and its other consumers) against that namespace's > actions. Constructing a namespace with RFNOMNT and without #s bound does > at least two bad things: > -> it makes it impossible to pass fds around between processes in this > namespace, as there is now no /srv backing. > -> it prohibits import of additional resources. > You could have a superserver process that constructs additional namespace entries as mkdir()s within its own directory hierarchy, could you not? That, if I understand all this rather heady stuff correctly, is largely your sendfd(): I want access to some external namespace by posting its handle (a text string) to the superserver (echo mount 'hisnamespace' > /dev/superserver/ctl) and suddenly find /dev/superserver/999/hisnamespace for me to mess to my heart's content. Like you, I'd then find it annoying that RFNOMNT stops me from abbreviating this as /n/hisnamespace for practical purposes. Again, I'd love to be corrected if the above scenario is based on a misunderstanding. > The claim is that it might be useful to have namespaces where the mount > table remained open to additional mounts (etc.) but for which the magic > shortcut and proxy circumvention mechanism of #X was not available. In other words, restrict RFNOMNT (obviously by a totally different name and possibly mechanism) to the #X exception instead of its current function. Non? Something tells me that there may have to be a different solution, because as Erkik correctly points out, it is not the #-name that makes a difference, that is just a convenient notation. For your proposal to make sense, it must address the properties of the #-space that make it special/different from the rest of the namespace, specifically from the point of view of creating a secure namespace jail. It is that property that needs to be leveraged by an RFCJAIL option, feeling secure that it will not include #| when applied. ++L
Re: [9fans] sendfd() on native Plan 9?
>> Would that satisfy your requirements? Oh, sure, I haven't ever used >> #| directly and I'm a bit ignorant of consequences, but the rest seems >> feasible. > > I suspect #| being an exception wouldn't hurt, though it might be viewed as > a historical wart, being the only one... could #| be made to operate more > like devdup and given a canonical mountpoint? > I'd love to see that, although I respect the Plan 9 developers enough to believe they have given the issue plenty of thought. Still, there have been some instance of expedience (don't ask me, I may have to take this back :-) and perhaps there is another way if one looks beyond the present boundaries. >> Another aspect I noticed is that what you seem to need is a >> finer-grained construction of #p and #s, but being able to construct >> them one layer further down the hierarchy might suffice. > > "one layer further down the hierarchy" ? > Well, if you could bind a subset of #s by some selection criterion - specifically process group, but who's to know what else might be useful? - say, back onto a local /srv, you may have a sensible mechanism for jailing processes. But I'm once again speculating outside my knowledge and experience. >> Just an uneducated opinion, I've had little occasion to study those >> specific devices or the others in any detail. But I am curious of >> where this discussion could lead. > > I too. I have a feeling this is heading precisely where I would have liked to go a year or so ago, namely putting Plan 9 at the bottom of a paravirtualising executive. If that is the case, count me in on any further developments. ++L
Re: [9fans] sendfd() on native Plan 9?
On Sun, Jan 04, 2009 at 12:48:08AM -0500, erik quanstrom wrote: > > > '#p' > > > allows any of my namespaces to debug processess in any other, '#s' is too > > > global, and /net seems to allow any of my processes to manipulate any of > > > my > > > other processes' network connections (though I've not tested in detail to > > > see what's possible.) > > > > So you're saying that (a) a jailed process should not have access to > > the #-devices at all and (b) their equivalent /proc, /srv and /net > > ought to be configured as part of the jail and should not be > > modifiable. > > there is no special exception for #s, #I or #l. these cases are handled > already. RFNOMNT has been brought up repeatedly and, while it's certainly better than nothing, it is too harsh! It simultaneously: -> restricts access to kernel devices via # paths -> prevents any and all additional mount requests. Constructing a namespace without RFNOMNT that does not have #s (say) bound is not really securing #s (and its other consumers) against that namespace's actions. Constructing a namespace with RFNOMNT and without #s bound does at least two bad things: -> it makes it impossible to pass fds around between processes in this namespace, as there is now no /srv backing. -> it prohibits import of additional resources. The claim is that it might be useful to have namespaces where the mount table remained open to additional mounts (etc.) but for which the magic shortcut and proxy circumvention mechanism of #X was not available. --nwf; pgpO9dukRi6Mb.pgp Description: PGP signature
Re: [9fans] sendfd() on native Plan 9?
On Sun, Jan 04, 2009 at 07:19:35AM +0200, lu...@proxima.alt.za wrote: > > '#p' > > allows any of my namespaces to debug processess in any other, '#s' is too > > global, and /net seems to allow any of my processes to manipulate any of my > > other processes' network connections (though I've not tested in detail to > > see what's possible.) > > So you're saying that (a) a jailed process should not have access to > the #-devices at all and (b) their equivalent /proc, /srv and /net > ought to be configured as part of the jail and should not be > modifiable. Sounds about right. I'd say that they can be modifiable if new capabilities are sendfd()'d into the namespace, but yes. > Plan 9 source often short-circuits the possibility that #-something is > not bound to the conventional place (#v comes to mind as a frequent > culprit) but that is a form of laziness that could be corrected by a > careful source audit. In which case it would be possible to treat #X > as another of those security issues that needed special treatment for > Factotum and have a kernel request that puts the #-space out of > bounds. Elsewhere in a different thread, eric grepped for explicit uses of #X paths and found very few. See <3598a04c733942f7f010ad61d83a8...@quanstro.net>. > Would that satisfy your requirements? Oh, sure, I haven't ever used > #| directly and I'm a bit ignorant of consequences, but the rest seems > feasible. I suspect #| being an exception wouldn't hurt, though it might be viewed as a historical wart, being the only one... could #| be made to operate more like devdup and given a canonical mountpoint? > Another aspect I noticed is that what you seem to need is a > finer-grained construction of #p and #s, but being able to construct > them one layer further down the hierarchy might suffice. "one layer further down the hierarchy" ? > Just an uneducated opinion, I've had little occasion to study those > specific devices or the others in any detail. But I am curious of > where this discussion could lead. I too. --nwf; pgp4wC8RbxnBi.pgp Description: PGP signature
Re: [9fans] sendfd() on native Plan 9?
> > '#p' > > allows any of my namespaces to debug processess in any other, '#s' is too > > global, and /net seems to allow any of my processes to manipulate any of my > > other processes' network connections (though I've not tested in detail to > > see what's possible.) > > So you're saying that (a) a jailed process should not have access to > the #-devices at all and (b) their equivalent /proc, /srv and /net > ought to be configured as part of the jail and should not be > modifiable. there is no special exception for #s, #I or #l. these cases are handled already. > Plan 9 source often short-circuits the possibility that #-something is > not bound to the conventional place s/often/always/ there is no exception. one could not bind something onto #X. - erik
Re: [9fans] sendfd() on native Plan 9?
> '#p' > allows any of my namespaces to debug processess in any other, '#s' is too > global, and /net seems to allow any of my processes to manipulate any of my > other processes' network connections (though I've not tested in detail to > see what's possible.) So you're saying that (a) a jailed process should not have access to the #-devices at all and (b) their equivalent /proc, /srv and /net ought to be configured as part of the jail and should not be modifiable. Plan 9 source often short-circuits the possibility that #-something is not bound to the conventional place (#v comes to mind as a frequent culprit) but that is a form of laziness that could be corrected by a careful source audit. In which case it would be possible to treat #X as another of those security issues that needed special treatment for Factotum and have a kernel request that puts the #-space out of bounds. Would that satisfy your requirements? Oh, sure, I haven't ever used #| directly and I'm a bit ignorant of consequences, but the rest seems feasible. Another aspect I noticed is that what you seem to need is a finer-grained construction of #p and #s, but being able to construct them one layer further down the hierarchy might suffice. Just an uneducated opinion, I've had little occasion to study those specific devices or the others in any detail. But I am curious of where this discussion could lead. ++L
Re: [9fans] sendfd() on native Plan 9?
On Sat, Jan 03, 2009 at 01:23:02PM -0800, Roman V. Shaposhnik wrote: > [ I took a liberty to merge two of your emails together for the ease of > commenting ] Thanks. :) > On Thu, 2009-01-01 at 18:57 -0500, Nathaniel W Filardo wrote: > > That is, the claim that "a process spawned without access to your home > > directory cannot get it" is flawed if that process runs as your user. > > (Even if I can't mount it, I can attach a debugger to a process that > > can and make it make system calls for me. You now have to > > intermediate my #p (/proc) service. You have to ensure that I can't > > dial it and authenticate with factotum. It's a mess!) > > It would seem to me that none of the issues that you've mentioned here > are insurmountable. As far as #p and #s are concerned the good news > under Plan9 is that they are supposed to be 'just servers' (the reality > of the situation is a bit more grim -- but I'd would like to discuss > this in the separate thread). As such, if the default implementation > seems too open, you can always harden its security semantics by > providing proxying user-level servers (well, that plus fixing all the > smart-ass apps -- more on that in a separate thread). > > All in all, I don't see the above example as a fundamental obstacle to > what you're trying to accomplish. Agreed. I think the kernel modifications necessary are small and tastefully doable. > > I may be tainted by the capability microkernel koolaid, > > but I don't like the idea that users are the sole security > > domain objects > > How does your ideal world look like? What else, besides users and groups > of users would you like to have as security domain objects? Namespaces are containers, if the objects bound in to the namespace are well behaved. That is, if I cannot refer to an object in my namespace and no server I can refer to will grant access, then I have achieved isolation of that object and any process running in my namespace. Users make sense for remote services -- it's an excellent mechanism for reconnecting a principle with its capabilties (nabable objects and permissions) on a remote server. Perhaps in local cases they make sense as well, but in Plan 9 the only "local" services are kernel provided. Most of these, AFAIK, only differentiate between hostowner and not. The few that leap to mind that have more advanced permissions schemes, '#p', '#s', and the servers backing /net, have, IMHO, dubious models backing them. '#p' allows any of my namespaces to debug processess in any other, '#s' is too global, and /net seems to allow any of my processes to manipulate any of my other processes' network connections (though I've not tested in detail to see what's possible.) Groups are woefully problematic in almost every system I can think of (NIS, LDAP, AFS's PTS) and Plan 9 is no exception. Groups are left to interpretation by the server, and in most cases are ignored. Perhaps SPKI will solve some of this. > > I really dislike that I can build stronger security constructs when > > using multiple kernels rather than just one. Especially in a system > > like Plan 9, where namespaces are cheap and capabilties exist in the > > form of file descriptors. > [] > > That is, I want, essentially, to run multiple Plan 9 systems on one > > Plan 9 kernel without needing to get my whole domain to know about > > multiple instances of my user > > The above two seem to be the most crucial statements in all of this > thread. If I were to interpret them, I would say that what you're really > after is being able to provide an OS-level virtualization solution > under Plan9. "OS-level virtualization" is only a meaningful concept because, traditionally, our kernels were not. I want there to be no distinction between the security guarantees that can be made when one or many kernels are in flight. >[snip] > Now, under Plan9, #1-3 come for free. I'm not sure how #5 is possible > (anybody?). And thus #4 is the only are that needs work. That work, > is really all about teaching things like #s and #p to only disclose > information about processes running within the same "zone". Whether > "same zone" means "same process group" or an extra level of process > grouping is needed remains to be seen. Run with me for a moment to see how this might work without the extra level of grouping. Let's introduce an fdbind() call which takes a fd and a path, and binds the fd's chan on the path in the current namespace. This is essentially an optimization around spawning a billion exportfs processes and mount()ing the resulting descriptors. Now, suppose '#s' and '#p' -- the kernel services -- expose only the current process group (==namespace). If I want different behavior, when I construct the new namespace, I ensure that I have open fds to my /proc and /srv and fdbind() these in the new namespace along with '#s' and '#p'. If desired, the new namespaces' '#s' and '#p' can be posted (or sendfd()'d; see below) to the p
Re: [9fans] sendfd() on native Plan 9?
On Sat, 2009-01-03 at 16:41 -0500, erik quanstrom wrote: > there's also nothing preventing one from implementing a > filtering fs that restricts the directories available in /proc. True. But there are two problems with a filtering fs: 1. Accessing #p would bypass the fs 100% 2. For things like #s the need to proxy the actual data back and forth seems to be really unfortunate. Thanks, Roman.
Re: [9fans] sendfd() on native Plan 9?
>1. Virtualizing root account, so that every Zone can have its own >2. Virtualizing the global UNIX namespace >3. Virtualizing TCP/IP stack >4. Virtualizing drivers providing access to the service provided > by the kernel itself (things like /proc, etc.) >5. Implementing per-Zone quotas on CPU, Memory and I/O consumption > > Now, under Plan9, #1-3 come for free. I'm not sure how #5 is possible > (anybody?). And thus #4 is the only are that needs work. That work, there isn't a root account, but there is still only one eve. also, there can only be one ip stack per physical interface. (this could be fixed by changing two or three lines of code.) there's also nothing preventing one from implementing a filtering fs that restricts the directories available in /proc. i'm not quite sure what the point is. if the problem really is security, then i would the security problems should be fixed. > a channel (either existing or a new one). From the point it connects > *and* passes the auth process, you are constrained by the security > model of 9P. Users and user groups are the only thing that is there. note that in plan 9, groups only exist on the file server. the auth server doesn't know anything about them - erik
Re: [9fans] sendfd() on native Plan 9?
[ I took a liberty to merge two of your emails together for the ease of commenting ] On Thu, 2009-01-01 at 18:57 -0500, Nathaniel W Filardo wrote: > That is, the claim that "a process spawned without access to your home > directory cannot get it" is flawed if that process runs as your user. > (Even if I can't mount it, I can attach a debugger to a process that > can and make it make system calls for me. You now have to > intermediate my #p (/proc) service. You have to ensure that I can't > dial it and authenticate with factotum. It's a mess!) It would seem to me that none of the issues that you've mentioned here are insurmountable. As far as #p and #s are concerned the good news under Plan9 is that they are supposed to be 'just servers' (the reality of the situation is a bit more grim -- but I'd would like to discuss this in the separate thread). As such, if the default implementation seems too open, you can always harden its security semantics by providing proxying user-level servers (well, that plus fixing all the smart-ass apps -- more on that in a separate thread). All in all, I don't see the above example as a fundamental obstacle to what you're trying to accomplish. > I may be tainted by the capability microkernel koolaid, > but I don't like the idea that users are the sole security > domain objects How does your ideal world look like? What else, besides users and groups of users would you like to have as security domain objects? > I really dislike that I can build stronger security constructs when > using multiple kernels rather than just one. Especially in a system > like Plan 9, where namespaces are cheap and capabilties exist in the > form of file descriptors. [] > That is, I want, essentially, to run multiple Plan 9 systems on one > Plan 9 kernel without needing to get my whole domain to know about > multiple instances of my user The above two seem to be the most crucial statements in all of this thread. If I were to interpret them, I would say that what you're really after is being able to provide an OS-level virtualization solution under Plan9. The very same reasons were part of the motivation for implementing Solaris containers/zones for Solaris 10. Now, if one is to look past all the marketing hype and the amount of thrust that was needed to make that particular pig fly, Solaris Zones are all about convincing a group of processes that they run under separate kernels on separate hosts, even though in reality they all could very well share the common "big iron" server. Long story short, it all boiled down to: 1. Virtualizing root account, so that every Zone can have its own 2. Virtualizing the global UNIX namespace 3. Virtualizing TCP/IP stack 4. Virtualizing drivers providing access to the service provided by the kernel itself (things like /proc, etc.) 5. Implementing per-Zone quotas on CPU, Memory and I/O consumption Now, under Plan9, #1-3 come for free. I'm not sure how #5 is possible (anybody?). And thus #4 is the only are that needs work. That work, is really all about teaching things like #s and #p to only disclose information about processes running within the same "zone". Whether "same zone" means "same process group" or an extra level of process grouping is needed remains to be seen. > > > supposing that you have a fully jailed process. if it has a connection > > > to the fileserver, which does do security by user id, the jailed process > > > can still mess with you. say by deleting all your files. > > Yes, exactly. I don't understand the question? The question, as I understood it, was about the practicality of such attack. For every fully jailed process that belongs to the user Foo, the following holds true: either it has no existing channels to the external file servers and no means to create them, or it can obtain a channel (either existing or a new one). From the point it connects *and* passes the auth process, you are constrained by the security model of 9P. Users and user groups are the only thing that is there. > > > i think the real question here is why don't you trust your > > > processes? is it because someone else is running them > > > > That was, essentially, my original question. Nathaniel, could you, > > please answer it? > > I'm looking at a system like 9gridchan What is 9gridchan? > where an essentialy autonomous agent publishes services. How does that publishing happen? If the system is distributed, I'd presume that the publishing happens in a network-friendly manner, thus making the whole discussion around #s pretty much moot. > Further, 9gridchan pollutes the namespace of /srv for everybody > else on the system, and its current naming scheme makes it impossible to run > two 9gridchan agents (w/o modification) even as different users. I have to know more about 9gridchan agents in order to reason about this intelligently. So far it seems to me that your general issue with a global nature of /srv can
Re: [9fans] sendfd() on native Plan 9?
On Thu, Jan 01, 2009 at 02:53:33PM -0800, Roman V. Shaposhnik wrote: > On Tue, 2008-12-30 at 10:31 -0500, erik quanstrom wrote: > > > You have to ensure that I can't dial it and authenticate with > > > factotum. It's a mess!) > > > > how would that attack work? > > > > supposing that you have a fully jailed process. if it has a connection > > to the fileserver, which does do security by user id, the jailed process > > can still mess with you. say by deleting all your files. Yes, exactly. I don't understand the question? > > i think the real question here is why don't you trust your > > processes? is it because someone else is running them > > That was, essentially, my original question. Nathaniel, could you, > please answer it? I'm looking at a system like 9gridchan where an essentialy autonomous agent publishes services. A bug in this server which revealed all of /srv, rather than the parts of /srv it's supposed to, would be tragic. I'd be much, much happier if the bar were raised from server compromise to local kernel compromise. Further, 9gridchan pollutes the namespace of /srv for everybody else on the system, and its current naming scheme makes it impossible to run two 9gridchan agents (w/o modification) even as different users. I also want, I think, an extension to 9gridchan where I can publish a service which relays for other 9gridchan nodes, which essentially means that remote machines are directing the contents of my /srv. (I want this so that I can bounce around NATs or loss of direct connectivity in the 9gridchan mesh... other proposals for solving this problem welcome.) While fixing 9gridchan could solve some of this, the problem is more general. The global unified name space of /srv is reminiscent of the UNIX /tmp nightmare, where processes and users have to guess as to names that won't collide or iterate around create() or, in the worst case, just fail outright (e.g. somebody has posted a file name 'sources' into /srv that isn't a connection to sources). However, /srv is currently the only mechanism (AFAIK) for a fd in a pgrp A to be given to a process in pgrp B. Therefore, if /srv is to be virtualized (made a property of namespaces) ala /tmp, then something like sendfd() seems to be necessary to replace this functionality when required. Does that help answer the question? Am I totally lost in the woods? (It's always possible...). Thanks. --nwf; pgp50EQXkK4xF.pgp Description: PGP signature
Re: [9fans] sendfd() on native Plan 9?
On Tue, 2008-12-30 at 10:31 -0500, erik quanstrom wrote: > > You have to ensure that I can't dial it and authenticate with > > factotum. It's a mess!) > > how would that attack work? > > supposing that you have a fully jailed process. if it has a connection > to the fileserver, which does do security by user id, the jailed process > can still mess with you. say by deleting all your files. > > i think the real question here is why don't you trust your > processes? is it because someone else is running them That was, essentially, my original question. Nathaniel, could you, please answer it? Thanks, Roman.
Re: [9fans] sendfd() on native Plan 9?
> If one buys this argument, then namespaces are not valid security constructs they are not security constructs at all. though ftpd and a few friends use rfork(2) to create a pgrp that doesn't allow attaches. very simple and effictive, but probablly not strong security. > either, and Plan 9 security boundaries are defined solely by user id. on the cpu server and authentication server , this is true. on the file server, group also matters. > That is, the claim that "a process spawned without access to your home > directory > cannot get it" is flawed if that process runs as your user. use RFNOMNT. > (Even if I can't mount it, I can attach a debugger to a process that can and > make it > make system calls for me. You now have to intermediate my #p (/proc) > service. factotum protects against this by making itself undebuggable and unpagable. /sys/src/cmd/auth/factotum/fs.c:/^private also, binding '#p' into the namespace isn't required for everything. combined with rfork(RFNOMNT), nor is providing network services. > You have to ensure that I can't dial it and authenticate with > factotum. It's a mess!) how would that attack work? supposing that you have a fully jailed process. if it has a connection to the fileserver, which does do security by user id, the jailed process can still mess with you. say by deleting all your files. i think the real question here is why don't you trust your processes? is it because someone else is running them > I may be tainted by the capability microkernel koolaid, but I don't like the > idea that users are the sole security domain objects, and I really dislike > that I can build stronger security constructs when using multiple kernels > rather than just one. i don't understand this. this doesn't seem like a compelling reason to turn namespaces into containers. for the reasons you cite, containers are also unattactive solutions to security problems. - erik
Re: [9fans] sendfd() on native Plan 9?
On Tue, Dec 30, 2008 at 2:22 AM, Nathaniel W Filardo wrote: > > If #s can be virtualized -- ala srv^2 or devcapsrv or something else -- then > the system is one step closer to supporting the above. There is some > machinery for sealing off #p that I do not recall in full detail but may > well be sufficient, at least for my desires. > I think this is an interesting direction to explore. Extending private name spaces to private device instances seems to make sense as a logical extension of the system (as long as its useful to someone). We already can have private network stacks, are their other devices which might make sense for similar principles? -eric
Re: [9fans] sendfd() on native Plan 9?
On Sat, Dec 27, 2008 at 12:21:49PM -0800, Roman Shaposhnik wrote: > True. But why that should be a problem in practice? If the process > belongs to a user X that means user X has control over it. Thus the > behavior of accidental consumption of an fd that was meant to be consumed > by some other process can only be attributed to bugs in the code, not > malicious intent. If one buys this argument, then namespaces are not valid security constructs either, and Plan 9 security boundaries are defined solely by user id. That is, the claim that "a process spawned without access to your home directory cannot get it" is flawed if that process runs as your user. (Even if I can't mount it, I can attach a debugger to a process that can and make it make system calls for me. You now have to intermediate my #p (/proc) service. You have to ensure that I can't dial it and authenticate with factotum. It's a mess!) I may be tainted by the capability microkernel koolaid, but I don't like the idea that users are the sole security domain objects, and I really dislike that I can build stronger security constructs when using multiple kernels rather than just one. Especially in a system like Plan 9, where namespaces are cheap and capabilties exist in the form of file descriptors. That is, I want to be able to build processes that cannot access resources that they were not explicitly granted when their namespace was constructed. Currently, #p and #s are rather large, open-ended, potent capabilities to grant, and refusing grant of #p and #s requires some rather careful coding and prevents a number of conveniences, as you might imagine. That is, I want, essentially, to run multiple Plan 9 systems on one Plan 9 kernel without needing to get my whole domain to know about multiple instances of my user (e.g. nwf/browser, nwf/grid, nwf, ...). Or rather, the ability to do that is a sufficient, but not necessary, condition. I can build exactly these resource-restricted namespaces if I devote an entire kernel -- and thereby an entire machine or emulation -- to it. I simply avoid granting that machine my P9 secret and (tada!) even though the uid may be "nwf", that doesn't mean anything. If #s can be virtualized -- ala srv^2 or devcapsrv or something else -- then the system is one step closer to supporting the above. There is some machinery for sealing off #p that I do not recall in full detail but may well be sufficient, at least for my desires. --nwf; pgpnSBhknyqFX.pgp Description: PGP signature
Re: [9fans] sendfd() on native Plan 9?
On Sat, Dec 27, 2008 at 2:27 PM, Roman Shaposhnik wrote: > On Dec 24, 2008, at 5:36 AM, erik quanstrom wrote: > > I was very curious about srv^2 as well, but Eric's blog post is really > too terse for me to appreciate even the general directions of his > proposal. > > I guess if Eric can be, somehow, motivated to discuss it in greater > details that would seem to benefit at least two (three?) members > of this group. > What's in the blog post is all I'm prepared to talk about at this time. The idea is still very high level, I'm going to need some implementation time before I work out many of the details. When I do, I'll update the blog. -eric
Re: [9fans] sendfd() on native Plan 9?
On Dec 24, 2008, at 5:36 AM, erik quanstrom wrote: EricVH's /srv replacement. See http://graverobbers.blogspot.com/2008/12/srv-next-generation-service-registry.html perhaps i don't understand the srv² proposal, to which there are many parts, but part of the problem seems to be finding a service. generally this is mediated by /net/cs. i wonder if thinking of it that way might help? I was very curious about srv^2 as well, but Eric's blog post is really too terse for me to appreciate even the general directions of his proposal. I guess if Eric can be, somehow, motivated to discuss it in greater details that would seem to benefit at least two (three?) members of this group. Thanks, Roman.
Re: [9fans] sendfd() on native Plan 9?
Sorry for coming into this discussion rather late, but... On Dec 23, 2008, at 5:10 PM, Nathaniel W Filardo wrote: On Wed, Dec 24, 2008 at 12:53:06AM +0100, Francisco J Ballesteros wrote: You can post a fd at /srv for others to use /srv is not an ideal answer, though it is the one I feared would be given. /srv allows any process running as a given user to access the posted fd, True. But why that should be a problem in practice? If the process belongs to a user X that means user X has control over it. Thus the behavior of accidental consumption of an fd that was meant to be consumed by some other process can only be attributed to bugs in the code, not malicious intent. Thanks, Roman.
Re: [9fans] sendfd() on native Plan 9?
On Tue, Dec 23, 2008 at 10:01 AM, Nathaniel W Filardo wrote: > Is there any equivalent of sendfd() on native Plan 9? No. Russ
Re: [9fans] sendfd() on native Plan 9?
> EricVH's /srv replacement. See > http://graverobbers.blogspot.com/2008/12/srv-next-generation-service-registry.html perhaps i don't understand the srv² proposal, to which there are many parts, but part of the problem seems to be finding a service. generally this is mediated by /net/cs. i wonder if thinking of it that way might help? > Assuming that the resource can be named in the plumber's namespace? This > works out less well for things like ramfs's that were told where to mount > (-m) and not to use /srv (-s). Or is there something really sneaky going on > here that I don't know? by definition it must be. the rule is this: typeis text datamatches 'Local (.*)' plumb to none plumb start rc -c $1 it executes the mount in the plumber's namespace, which is helpfully shared by rio. (Local in acme is interpteted by acme, not sent to the plumber.) - erik
Re: [9fans] sendfd() on native Plan 9?
On Tue, Dec 23, 2008 at 11:14:16PM -0500, erik quanstrom wrote: > > All of the same comments apply to /srv (though srv^2 is trying to solve > > this). > > not true. import $server / /n/$server will give you access to srv on $server > as /n/$server/srv. Fair, but there's no reason to propose that an exportfs couldn't be the target of a sendfd(), or that the underlying mechanism for sendfd() couldn't be similarly exported (devcapsrv would work just fine, I think... maybe I should just write it and post code?). > what is "srv^2"? EricVH's /srv replacement. See http://graverobbers.blogspot.com/2008/12/srv-next-generation-service-registry.html > > 1) Sending files across namespaces so that I can spawn acme at rio startup > > and plumb to it without having to recreate mounts in its namespace. > > plumb "Local (bind|mount) args" will accomplish this. Assuming that the resource can be named in the plumber's namespace? This works out less well for things like ramfs's that were told where to mount (-m) and not to use /srv (-s). Or is there something really sneaky going on here that I don't know? > > 2) Sending parts of namespaces around locally without needing to run an > > exportfs in that namespace. (i.e. open() a directory && sendfd() that to > > another process who can mount() it.) Among other things, this allows the > > shell (and others) to easily offer the current working directory fd (rather > > than path) to rio for tab completion. > > you can't mount a random directory. OK, fair, it's more of a bind(). The operation does not yet exist, but should be quite easy to add. Perhaps it isn't worth it. > > 3) Some small thought about being able to implement srv^2 entirely in > > userland, and what the primitives would look like. sendfd() or the above > > outlined devcapsrv seems better than the current devsrv to me, but I confess > > I might be mistaken. > > what's the advantage of implementing srv entirely in userland? EricVH made some rumblings off-list about srv^2 being a userland thing, as it's a relatively complex proposal. Further, being able to write it entirely in userland also means that it is a virtualizable service, which /srv is not. > - erik pgpQo8YjYXbQG.pgp Description: PGP signature
Re: [9fans] sendfd() on native Plan 9?
> All of the same comments apply to /srv (though srv^2 is trying to solve > this). not true. import $server / /n/$server will give you access to srv on $server as /n/$server/srv. what is "srv^2"? > 1) Sending files across namespaces so that I can spawn acme at rio startup > and plumb to it without having to recreate mounts in its namespace. plumb "Local (bind|mount) args" will accomplish this. > 2) Sending parts of namespaces around locally without needing to run an > exportfs in that namespace. (i.e. open() a directory && sendfd() that to > another process who can mount() it.) Among other things, this allows the > shell (and others) to easily offer the current working directory fd (rather > than path) to rio for tab completion. you can't mount a random directory. > 3) Some small thought about being able to implement srv^2 entirely in > userland, and what the primitives would look like. sendfd() or the above > outlined devcapsrv seems better than the current devsrv to me, but I confess > I might be mistaken. what's the advantage of implementing srv entirely in userland? - erik
Re: [9fans] sendfd() on native Plan 9?
On Tue, Dec 23, 2008 at 08:39:27PM -0500, erik quanstrom wrote: > > /srv is not an ideal answer, though it is the one I feared would be given. > > /srv allows any process running as a given user to access the posted fd, and > > does not respect namespace or process group boundaries. I want a mechanism > > to pass a file descriptor to one target process so that I can pass an fd > > across namespaces without giving _all_ namespaces access to said fd. > > > > A /srv that 1) was not enumerable, 2) allowed only single opens, and 3) used > > secure identifiers (capabilities, similar to devcap) would suffice, as > > processes could post an fd to recieve an identifier, pass the identifiers to > > another process, and then turn the identifier into an fd. > > on unix, which is not a distributed system, passing fds around makes > a certain amount of sense. in plan 9, i would think that the ideal > answer would need to allow for the unrelated processes running > on seperate machine. i would also think that it would allow the > standard authentication mechanisms to work. fds really don't fit > either one of those criteria. All of the same comments apply to /srv (though srv^2 is trying to solve this). > but we're talking generalities. what's the specific application? 1) Sending files across namespaces so that I can spawn acme at rio startup and plumb to it without having to recreate mounts in its namespace. 2) Sending parts of namespaces around locally without needing to run an exportfs in that namespace. (i.e. open() a directory && sendfd() that to another process who can mount() it.) Among other things, this allows the shell (and others) to easily offer the current working directory fd (rather than path) to rio for tab completion. 3) Some small thought about being able to implement srv^2 entirely in userland, and what the primitives would look like. sendfd() or the above outlined devcapsrv seems better than the current devsrv to me, but I confess I might be mistaken. Thoughts? --nwf; pgp8x6KQGQavE.pgp Description: PGP signature
Re: [9fans] sendfd() on native Plan 9?
> /srv is not an ideal answer, though it is the one I feared would be given. > /srv allows any process running as a given user to access the posted fd, and > does not respect namespace or process group boundaries. I want a mechanism > to pass a file descriptor to one target process so that I can pass an fd > across namespaces without giving _all_ namespaces access to said fd. > > A /srv that 1) was not enumerable, 2) allowed only single opens, and 3) used > secure identifiers (capabilities, similar to devcap) would suffice, as > processes could post an fd to recieve an identifier, pass the identifiers to > another process, and then turn the identifier into an fd. on unix, which is not a distributed system, passing fds around makes a certain amount of sense. in plan 9, i would think that the ideal answer would need to allow for the unrelated processes running on seperate machine. i would also think that it would allow the standard authentication mechanisms to work. fds really don't fit either one of those criteria. but we're talking generalities. what's the specific application? - erik
Re: [9fans] sendfd() on native Plan 9?
On Tue, Dec 23, 2008 at 11:52:51PM +0100, Rodolfo kix Garcia wrote: > Nathaniel, > > I am not 100% sure if my answer will solve your problem, but probably > you can do it using the 9P protocol. > > Look http://plan9.bell-labs.com/magic/man2html/5/0intro, 9P is the way > to comunicate the kernel with the proccess. Probably sendfd is not > needed in Plan 9. I think I understand 9P, but do not see why it removes the need for something like sendfd(). Can you explain further? --nwf; pgpCM2eFthmR7.pgp Description: PGP signature
Re: [9fans] sendfd() on native Plan 9?
On Wed, Dec 24, 2008 at 12:53:06AM +0100, Francisco J Ballesteros wrote: > You can post a fd at /srv for others to use /srv is not an ideal answer, though it is the one I feared would be given. /srv allows any process running as a given user to access the posted fd, and does not respect namespace or process group boundaries. I want a mechanism to pass a file descriptor to one target process so that I can pass an fd across namespaces without giving _all_ namespaces access to said fd. A /srv that 1) was not enumerable, 2) allowed only single opens, and 3) used secure identifiers (capabilities, similar to devcap) would suffice, as processes could post an fd to recieve an identifier, pass the identifiers to another process, and then turn the identifier into an fd. --nwf; pgpihmc2sjbvc.pgp Description: PGP signature
Re: [9fans] sendfd() on native Plan 9?
You can post a fd at /srv for others to use On 12/23/08, Rodolfo kix Garcia wrote: > Nathaniel, > > I am not 100% sure if my answer will solve your problem, but probably > you can do it using the 9P protocol. > > Look http://plan9.bell-labs.com/magic/man2html/5/0intro, 9P is the way > to comunicate the kernel with the proccess. Probably sendfd is not > needed in Plan 9. > > Saludos. > > Nathaniel W Filardo escribió: >> Is there any equivalent of sendfd() on native Plan 9? >> >> Thanks. >> --nwf; >> > > >
Re: [9fans] sendfd() on native Plan 9?
Nathaniel, I am not 100% sure if my answer will solve your problem, but probably you can do it using the 9P protocol. Look http://plan9.bell-labs.com/magic/man2html/5/0intro, 9P is the way to comunicate the kernel with the proccess. Probably sendfd is not needed in Plan 9. Saludos. Nathaniel W Filardo escribió: Is there any equivalent of sendfd() on native Plan 9? Thanks. --nwf;
