* [9fans] Factotum vs SASL @ 2014-11-17 5:03 Enrico Weigelt, metux IT consult 2014-11-17 5:57 ` Lyndon Nerenberg ` (2 more replies) 0 siblings, 3 replies; 25+ messages in thread From: Enrico Weigelt, metux IT consult @ 2014-11-17 5:03 UTC (permalink / raw) To: 9f >> Fans of the OS Plan 9 from Bell Labs Hi folks, I've got the impression that there're some similarities between SASL (saslauthd) and Factotum - at least at the point that both are offloading actual authentication handshakes to a separate service. But I have to admit that I didn't have done a deeper analysis of these two. Could anybody with deeper insight perhaps give some detailed comparison between them ? greetings, -- Enrico Weigelt, metux IT consulting +49-151-27565287 ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [9fans] Factotum vs SASL 2014-11-17 5:03 [9fans] Factotum vs SASL Enrico Weigelt, metux IT consult @ 2014-11-17 5:57 ` Lyndon Nerenberg 2014-11-17 6:29 ` lucio 2014-11-18 8:22 ` Skip Tavakkolian 2 siblings, 0 replies; 25+ messages in thread From: Lyndon Nerenberg @ 2014-11-17 5:57 UTC (permalink / raw) To: lyndon > I've got the impression that there're some similarities between SASL > (saslauthd) and Factotum - at least at the point that both are > offloading actual authentication handshakes to a separate service. > But I have to admit that I didn't have done a deeper analysis of > these two. > > Could anybody with deeper insight perhaps give some detailed > comparison between them ? No, they aren't the same thing. saslauthd was written to provide privilege separation for the CMU IMAP server. The CMU mail store processes (imapd, popd) would run under a unique uid, which owned all the files in the message store. To do plaintext authentication using the UNIX /etc/passwd database, if the host used shadow password files, you had to have an effective uid of 0 to be able to read the encrypted password field. Rather than have imapd run as root, and then drop privileges down to the mail store uid, the code requiring uid=0 was isolated into a separate process: saslauthd. When imapd needed to do authenticate a plaintext login request against the shadow password file, it would contact saslauthd over a named socket, send it the plaintext userid and password, then wait for a pass/fail response to come back. The protocol over the named socket is private to the Cyrus code. So, saslauthd doesn't speak SASL, it just proxies certain system requests that require escalated security permissions to invoke. It did grow to include a few additional mechanisms (dce, kerberos, ldap) that benefited from its ability to keep a temporary cache of valid credentials, thus reducing the number of calls out to the external services. factotum is a different beast, best explained by the security paper: http://plan9.bell-labs.com/sys/doc/auth.pdf ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [9fans] Factotum vs SASL 2014-11-17 5:03 [9fans] Factotum vs SASL Enrico Weigelt, metux IT consult 2014-11-17 5:57 ` Lyndon Nerenberg @ 2014-11-17 6:29 ` lucio 2014-11-17 13:58 ` erik quanstrom 2014-11-18 8:22 ` Skip Tavakkolian 2 siblings, 1 reply; 25+ messages in thread From: lucio @ 2014-11-17 6:29 UTC (permalink / raw) To: 9fans > Could anybody with deeper insight perhaps give some detailed > comparison between them ? Factotum (Russ may correct me) is modelled on SSH's agent. The SASL type functionality resides in the servers that use factotum, so I'd say the differences are quite significant. There is a paper on Plan 9 security that makes very interesting reading. Lucio. ------------------------------------------------------------------------------------- This email has been scanned by the MxScan Email Security System. ------------------------------------------------------------------------------------- ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [9fans] Factotum vs SASL 2014-11-17 6:29 ` lucio @ 2014-11-17 13:58 ` erik quanstrom 2014-11-17 14:14 ` lucio 0 siblings, 1 reply; 25+ messages in thread From: erik quanstrom @ 2014-11-17 13:58 UTC (permalink / raw) To: 9fans > Factotum (Russ may correct me) is modelled on SSH's agent. The SASL > type functionality resides in the servers that use factotum, so I'd > say the differences are quite significant. > > There is a paper on Plan 9 security that makes very interesting > reading. do you have a reference for this claim? factotum both caches keys and certs (as does ssh-agent), as well as functions as a delegation agent (as i understand sasl does -- haven't used it). so it's basically just the union of roles. - erik ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [9fans] Factotum vs SASL 2014-11-17 13:58 ` erik quanstrom @ 2014-11-17 14:14 ` lucio 0 siblings, 0 replies; 25+ messages in thread From: lucio @ 2014-11-17 14:14 UTC (permalink / raw) To: 9fans > do you have a reference for this claim? The claim that Russ first produced a utility called agent, or that the server logic resides in servers? I may have summarised the protocol poorly, but factotum is an intermediary, neither client seeking authentication, nor server validating credentials. In this respect, it does not compare with the functionality provided by SASL. Lucio. ------------------------------------------------------------------------------------- This email has been scanned by the MxScan Email Security System. ------------------------------------------------------------------------------------- ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [9fans] Factotum vs SASL 2014-11-17 5:03 [9fans] Factotum vs SASL Enrico Weigelt, metux IT consult 2014-11-17 5:57 ` Lyndon Nerenberg 2014-11-17 6:29 ` lucio @ 2014-11-18 8:22 ` Skip Tavakkolian 2014-11-29 19:46 ` Enrico Weigelt, metux IT consult 2 siblings, 1 reply; 25+ messages in thread From: Skip Tavakkolian @ 2014-11-18 8:22 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs [-- Attachment #1: Type: text/plain, Size: 1282 bytes --] to do a comparative analysis of the functions it makes sense to know one side very well. i found it easier to understand factotum and compare the others to factotum. to me SASL is more like the functions of factotum's rpc and proto files. Window's Local Security Authority (LSA) combined with Security Support Provider Interface (SSPI) and the corresponding protocol DDL's, is more comparable to factotum's credentials caching, rpc/proto/needkey, etc fs interface and how it negotiates change of identity of a verified process using cap(3). on Linux, for a server, SASL+setuid program+PAM is sort-of like factotum and SASL+app is sort of like factotum for a client. On Sun, Nov 16, 2014 at 9:03 PM, Enrico Weigelt, metux IT consult < enrico.weigelt@gr13.net> wrote: > Hi folks, > > I've got the impression that there're some similarities between SASL > (saslauthd) and Factotum - at least at the point that both are > offloading actual authentication handshakes to a separate service. > But I have to admit that I didn't have done a deeper analysis of > these two. > > Could anybody with deeper insight perhaps give some detailed > comparison between them ? > > > greetings, > -- > Enrico Weigelt, > metux IT consulting > +49-151-27565287 > > [-- Attachment #2: Type: text/html, Size: 1706 bytes --] ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [9fans] Factotum vs SASL 2014-11-18 8:22 ` Skip Tavakkolian @ 2014-11-29 19:46 ` Enrico Weigelt, metux IT consult 2014-11-29 19:46 ` erik quanstrom ` (2 more replies) 0 siblings, 3 replies; 25+ messages in thread From: Enrico Weigelt, metux IT consult @ 2014-11-29 19:46 UTC (permalink / raw) To: 9fans On 18.11.2014 09:22, Skip Tavakkolian wrote: <snip> thanks folks ... seems I need to think through all of this more deeply. If I'm not completely mistaken, factotum can also handle various authentication protocols, and may be the only one who really knows the actual secrets. One scenario I'm thinking about is replacing the password-stores in certain browsers by an factotum (maybe it could also be useful for cert handling ?) A really cool feature, IMHO, would be able to connect my local factotum to remote ones easily, so I'll get a similar feature like eg. lastpass is doing for the web. For example, somebody like to give me access to some remote application, but for some reason can't add my pubkey there (eg. it doesn't even support such things), but doesn't want to give me cleartext passwords, he could set things up in his (publically accessible) factotum instance, which then handles all the auth stuff for that application. By the way, that leads me to another topic, which is annoying me for quite some time: policykit. For those, who have been spared of it: It's an invention of the freedesktop folks (or should I call them "Lennartists" ? ;-o), some kind of proxy, which routes certain dbus calls (based on certain policies) between several users (and root). This way, eg. unprivileged users can still be given access to system level stuff, like network-manager. And that's exactly the point which regularily hit me (eg. some day my primary account suddenly wasn't able to choose wireless networks anymore, and even the old fashioned way via unix groups didn't help either). So, I'm thinking about a cleaner solution - obviously not dbus, but 9P. If i understand it correctly, in 9P, the server is in charge of handling all the access control. So, I can't just write some simple 9P server, mount it anywhere and magically expect it working just by file ownerships (by the way: do they have any practical meaning at all ?). Obviously, the server needs to know who the calling user is and whether he shall be allowed to access certain items - more precisely whether he is in the right role right now. And these things could be depending on other parameters (defined by other parties), eg. when reboot shall only be allowed when logged-in locally, and no other blocking parts (eg. important tasks) currently running. Pretty clear, that these things shouldn't be implemented in each single service separately, and not every service that might have an influence here shall have to talk to everybody else. So, how would a Plan9 solution for these usecases look like ? In fact, I intend to rewrite network-manager to some 9p-based solution, so I'd like to discuss this carefully before starting to lennert up something stupid. cu -- Enrico Weigelt, metux IT consulting +49-151-27565287 ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [9fans] Factotum vs SASL 2014-11-29 19:46 ` Enrico Weigelt, metux IT consult @ 2014-11-29 19:46 ` erik quanstrom 2014-11-29 21:20 ` Enrico Weigelt, metux IT consult 2014-12-02 20:32 ` Skip Tavakkolian 2015-01-01 14:55 ` Teodoro Santoni 2 siblings, 1 reply; 25+ messages in thread From: erik quanstrom @ 2014-11-29 19:46 UTC (permalink / raw) To: 9fans > So, how would a Plan9 solution for these usecases look like ? plan 9 doesn't pretend that the hostowner doesn't fully control the box, so it doesn't attempt to prevent the hostowner from e.g. turning wireless on and off. - erik ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [9fans] Factotum vs SASL 2014-11-29 19:46 ` erik quanstrom @ 2014-11-29 21:20 ` Enrico Weigelt, metux IT consult 2014-11-29 21:23 ` erik quanstrom 0 siblings, 1 reply; 25+ messages in thread From: Enrico Weigelt, metux IT consult @ 2014-11-29 21:20 UTC (permalink / raw) To: 9fans On 29.11.2014 20:46, erik quanstrom wrote: Hi, >> So, how would a Plan9 solution for these usecases look like ? > > plan 9 doesn't pretend that the hostowner doesn't fully control the box, > so it doesn't attempt to prevent the hostowner from e.g. turning wireless > on and off. In my scenario, I'm (more precisely: the account I'm using) not the hostowner, just a plain user - in Unix terms: non-root). But that account has the special privileges of controlling the network connections. Other accounts may only choose from a predefined list of connections. The network itself is controlled by some separate service (eg. network manager - which eg. comes quite handy for travelers, etc). Now we need to decide which accounts may control it or just see some status. A traditional unix/linux approach (for local-only) would be handling that via groups and file permissions for the command sockets. The decision then would be done on login time, as the uids and gids are set here. For a plan9-alike approach, I could imagine something where the factotums handle everything, so the service finally just sees an pseudo-user or role, and the host-factotum does the translation, based on some table (similar to /etc/group). For the network-manager example, there could be roles like "network-admin", "network-ctrl", "network-stat". Maybe we could even extend the factotum protocol, so it directly supports roles. hmm, seems that all needs some deeper thoughts ... cu -- Enrico Weigelt, metux IT consulting +49-151-27565287 ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [9fans] Factotum vs SASL 2014-11-29 21:20 ` Enrico Weigelt, metux IT consult @ 2014-11-29 21:23 ` erik quanstrom 2014-12-01 6:28 ` Enrico Weigelt, metux IT consult 0 siblings, 1 reply; 25+ messages in thread From: erik quanstrom @ 2014-11-29 21:23 UTC (permalink / raw) To: 9fans > In my scenario, I'm (more precisely: the account I'm using) not the > hostowner, just a plain user - in Unix terms: non-root). But that > account has the special privileges of controlling the network > connections. Other accounts may only choose from a predefined list > of connections. if you've logged into a plan 9 terminal, then you *are* the hostowner. this is a non-problem. "in Unix terms" doesn't work here. root != hostowner. they are very different concepts. > The network itself is controlled by some separate service (eg. network > manager - which eg. comes quite handy for travelers, etc). Now we need > to decide which accounts may control it or just see some status. again, this is not how a plan 9 box would work. when you log into the machine, you own all the h/w. you can do what you want. > A traditional unix/linux approach (for local-only) would be handling > that via groups and file permissions for the command sockets. The > decision then would be done on login time, as the uids and gids are > set here. again, ... > For a plan9-alike approach, I could imagine something where the > factotums handle everything, so the service finally just sees an > pseudo-user or role, and the host-factotum does the translation, > based on some table (similar to /etc/group). For the network-manager > example, there could be roles like "network-admin", "network-ctrl", > "network-stat". Maybe we could even extend the factotum protocol, > so it directly supports roles. no factotum need apply. :-) - erik ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [9fans] Factotum vs SASL 2014-11-29 21:23 ` erik quanstrom @ 2014-12-01 6:28 ` Enrico Weigelt, metux IT consult 2014-12-01 7:00 ` lucio 2014-12-01 12:14 ` Stuart Morrow 0 siblings, 2 replies; 25+ messages in thread From: Enrico Weigelt, metux IT consult @ 2014-12-01 6:28 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs On 29.11.2014 22:23, erik quanstrom wrote: >> In my scenario, I'm (more precisely: the account I'm using) not the >> hostowner, just a plain user - in Unix terms: non-root). But that >> account has the special privileges of controlling the network >> connections. Other accounts may only choose from a predefined list >> of connections. > > if you've logged into a plan 9 terminal, then you *are* the hostowner. > this is a non-problem. So, what about multiuser environments, where the guy in front of the console is just an arbitrary user, who shouldn't be allowed to access everything on the machine (nor disturb other users) ? > "in Unix terms" doesn't work here. root != hostowner. they are very > different concepts. hmm, so, what exactly does the term "hostowner" mean here ? I've understood it as the user, who gets full access to the machine, eg. can do anything with local disks, etc. When I'm talking about non-root (in unix terminology), I'm refering to normal unprivileged users, who do not have any administrative capabilities, but just *might* be sitting directly on the console. >> The network itself is controlled by some separate service (eg. network >> manager - which eg. comes quite handy for travelers, etc). Now we need >> to decide which accounts may control it or just see some status. > > again, this is not how a plan 9 box would work. when you log into the > machine, you own all the h/w. you can do what you want. Okay, that's a scenario I absolutely do NOT want. The guy in front of the console should authenticate as a normal user and then only be allowed to access his own environment (no direct control over hw, etc). So, we're maybe just lacking similar to gettys/login do on unix ? cu -- Enrico Weigelt, metux IT consulting +49-151-27565287 ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [9fans] Factotum vs SASL 2014-12-01 6:28 ` Enrico Weigelt, metux IT consult @ 2014-12-01 7:00 ` lucio 2014-12-01 10:38 ` tlaronde 2014-12-01 12:14 ` Stuart Morrow 1 sibling, 1 reply; 25+ messages in thread From: lucio @ 2014-12-01 7:00 UTC (permalink / raw) To: 9fans > The guy in front of the console should authenticate as a normal user > and then only be allowed to access his own environment (no direct > control over hw, etc). The guy is not in front of the "console", he has physical and therefore unrestricted access to all the resources in the terminal. A CPU or file server is used to offer limited access to restricted resources. The terminal user is meant not to have physical access to such devices. It's no use bucking against that paradigm, it is fundamental to Plan 9's design. Lucio. PS: An auth server is meant to be kept under lock and key, separate from the open network. That does not normally happen, but it is designed to be possible. ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [9fans] Factotum vs SASL 2014-12-01 7:00 ` lucio @ 2014-12-01 10:38 ` tlaronde 2014-12-01 10:45 ` lucio 2014-12-02 4:00 ` Enrico Weigelt, metux IT consult 0 siblings, 2 replies; 25+ messages in thread From: tlaronde @ 2014-12-01 10:38 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs On Mon, Dec 01, 2014 at 09:00:46AM +0200, lucio@proxima.alt.za wrote: > > The guy in front of the console should authenticate as a normal user > > and then only be allowed to access his own environment (no direct > > control over hw, etc). > > The guy is not in front of the "console", he has physical and > therefore unrestricted access to all the resources in the terminal. But, IMHO, this is precisely the difference between Unix and Plan9. In Unix, the console or X11 are dumb terminals. There are only no-computing-capabilities devices to interact; they are no terminals as in Plan9. This is why X11 has put the network in the wrong place. The X11 "server" is just a remote graphic card; it is mimicking with graphical devices what has been done with text devices (tty). In X11, all processing, including handling the graphical menus, the display, is done by the client. While on Plan9, the processing of the data can be done in a CPU tightly coupled with a file server, while the handling of what is displayed (menus for example) can be done on the terminal. In Unix, consoles and X display are just remote devices to interact, while the processing node they are connected to can be out of reach. -- Thierry Laronde <tlaronde +AT+ polynum +dot+ com> http://www.kergis.com/ http://www.arts-po.fr/ Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [9fans] Factotum vs SASL 2014-12-01 10:38 ` tlaronde @ 2014-12-01 10:45 ` lucio 2014-12-02 4:00 ` Enrico Weigelt, metux IT consult 1 sibling, 0 replies; 25+ messages in thread From: lucio @ 2014-12-01 10:45 UTC (permalink / raw) To: 9fans > But, IMHO, this is precisely the difference between Unix and Plan9. The important difference is that in Unix the "terminal", specially graphics terminals like X servers, have to be trusted to be in good hands - which cannot be enforced. When you look at NFS, for example, a trusted network node can totally subvert security if the trust cannot be ensured. Plan 9 gets around all these issues by putting security where it belongs and not giving a false sense of security by means of sobscure protocols and other ineffectual means. Lucio. ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [9fans] Factotum vs SASL 2014-12-01 10:38 ` tlaronde 2014-12-01 10:45 ` lucio @ 2014-12-02 4:00 ` Enrico Weigelt, metux IT consult 2014-12-02 4:08 ` erik quanstrom 2014-12-02 9:50 ` Richard Miller 1 sibling, 2 replies; 25+ messages in thread From: Enrico Weigelt, metux IT consult @ 2014-12-02 4:00 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs On 01.12.2014 11:38, tlaronde@polynum.com wrote: Hi, > But, IMHO, this is precisely the difference between Unix and Plan9. > > In Unix, the console or X11 are dumb terminals. There are only > no-computing-capabilities devices to interact; they are no terminals as > in Plan9. Okay, than that's perhaps what I'm missing yet. To mimic the usual Unix behaviour, I would need some getty/login-alike program, which asks for login credentials and then starts up things like shell or gui (some window-manager-/DE-alike program) as the corresponding, which then is _not_ the hostowner. If I understood it correctly, hostowner factotum can authenticate other users and startup proceses under their UID, right ? So, in my scenario, hostowner would act as kind-of-root, just being responsible to bring up certain fundamental servers, start the login program, which in turn asks for credentials, and starts this user's shell with certain filesystems (services) mounted in. A bit similar to an local xcpu or ssh connection, just with local console services (/dev/cons, /dev/draw, etc) mounted (bot not all the raw kernel devices) > This is why X11 has put the network in the wrong place. The X11 "server" > is just a remote graphic card; it is mimicking with graphical devices > what has been done with text devices (tty). In X11, all processing, > including handling the graphical menus, the display, is done by > the client. Well, it's like an (pretty complex) devdraw with multiple windows, isn't it ? To get back to my original intention: I'm looking for proper ways for access control of certain privileged operations on GNU/Linux / Unix machines where users (even the guy on front of the keyboard) are usually unprivileged. I'd like to replace the ugly dbus/polkit stuff by something plan9'ish. After thinking through this for a while, my idea is adding some kind of temporary users/keys to the (hostowner) factotum, which allows an session controller (eg. the login program) to dynamically give some session permissons for certain privileged services. It could go like this: * on login a new key is generated, which is handed over to the user session (maybe via env ?). symetric key should be sufficient here. * for the services which that user/session shall have access to, this key is added in the corresponding factotum instances (eg. hostowner factotum for machine control stuff, but maybe also other instances for services running under different users, eg. mail servers, etc) * this user can now connect to these services, and the factotum instances already know the proper keys, so authentication runs smoothly. cu -- Enrico Weigelt, metux IT consulting +49-151-27565287 ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [9fans] Factotum vs SASL 2014-12-02 4:00 ` Enrico Weigelt, metux IT consult @ 2014-12-02 4:08 ` erik quanstrom 2014-12-02 15:40 ` plannine 2014-12-02 9:50 ` Richard Miller 1 sibling, 1 reply; 25+ messages in thread From: erik quanstrom @ 2014-12-02 4:08 UTC (permalink / raw) To: 9fans > > But, IMHO, this is precisely the difference between Unix and Plan9. > > > > In Unix, the console or X11 are dumb terminals. There are only > > no-computing-capabilities devices to interact; they are no terminals as > > in Plan9. > > Okay, than that's perhaps what I'm missing yet. > > To mimic the usual Unix behaviour, I would need some getty/login-alike > program, which asks for login credentials and then starts up things > like shell or gui (some window-manager-/DE-alike program) as the > corresponding, which then is _not_ the hostowner. has it occured to you to try the system out as is? nobody else has asked for it to be more unix like in the same way. perhaps there's good reason for it to be the way it is. actually, i'll make you a deal, i'll try to answer your questions the best i know how, but you have to try the system and use it a bit before asking any more. fair? - erik ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [9fans] Factotum vs SASL 2014-12-02 4:08 ` erik quanstrom @ 2014-12-02 15:40 ` plannine 2014-12-02 16:33 ` Wes Kussmaul ` (2 more replies) 0 siblings, 3 replies; 25+ messages in thread From: plannine @ 2014-12-02 15:40 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs On Mon, Dec 01, 2014 at 08:08:04PM -0800, erik quanstrom wrote: > On Sat, 29 Nov 2014 20:46:08 +0100, Enrico Weigelt, metux IT consult wrote: >> So, how would a Plan9 solution for these usecases look like ? >> >> In fact, I intend to rewrite network-manager to some 9p-based solution, >> so I'd like to discuss this carefully before starting to lennert up >> something stupid. > > has it occured to you to try the system out as is? nobody else has > asked for it to be more unix like in the same way. perhaps there's > good reason for it to be the way it is. To be fair, he's not talking about using Plan 9, just leveraging something factotum-like under Linux. I think he should be commended for spreading the 9love in the face of rampant Lennartism, quixotic though it may be. ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [9fans] Factotum vs SASL 2014-12-02 15:40 ` plannine @ 2014-12-02 16:33 ` Wes Kussmaul 2014-12-02 20:32 ` Skip Tavakkolian 2014-12-02 22:20 ` Enrico Weigelt, metux IT consult 2 siblings, 0 replies; 25+ messages in thread From: Wes Kussmaul @ 2014-12-02 16:33 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs On 12/02/2014 10:40 AM, plannine@sigint.cs.purdue.edu wrote: > On Mon, Dec 01, 2014 at 08:08:04PM -0800, erik quanstrom wrote: >> On Sat, 29 Nov 2014 20:46:08 +0100, Enrico Weigelt, metux IT consult wrote: >>> So, how would a Plan9 solution for these usecases look like ? >>> >>> In fact, I intend to rewrite network-manager to some 9p-based solution, >>> so I'd like to discuss this carefully before starting to lennert up >>> something stupid. >> has it occured to you to try the system out as is? nobody else has >> asked for it to be more unix like in the same way. perhaps there's >> good reason for it to be the way it is. > To be fair, he's not talking about using Plan 9, just leveraging something > factotum-like under Linux. I think he should be commended for spreading > the 9love in the face of rampant Lennartism, quixotic though it may be. Lennartism is about breaking with orthodoxy. This is entirely in keeping with it. -- Wes Kussmaul The Authenticity Institute “Try this fruit, and by the way if a bunch of people collectively calling themselves Arthur Andersen signs something it’s the same as if a person named Arthur Andersen signed it.” - The Serpent ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [9fans] Factotum vs SASL 2014-12-02 15:40 ` plannine 2014-12-02 16:33 ` Wes Kussmaul @ 2014-12-02 20:32 ` Skip Tavakkolian 2014-12-02 22:20 ` Enrico Weigelt, metux IT consult 2 siblings, 0 replies; 25+ messages in thread From: Skip Tavakkolian @ 2014-12-02 20:32 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs [-- Attachment #1: Type: text/plain, Size: 935 bytes --] 9love is tough love. On Tue, Dec 2, 2014 at 7:40 AM, <plannine@sigint.cs.purdue.edu> wrote: > On Mon, Dec 01, 2014 at 08:08:04PM -0800, erik quanstrom wrote: > > On Sat, 29 Nov 2014 20:46:08 +0100, Enrico Weigelt, metux IT consult > wrote: > >> So, how would a Plan9 solution for these usecases look like ? > >> > >> In fact, I intend to rewrite network-manager to some 9p-based solution, > >> so I'd like to discuss this carefully before starting to lennert up > >> something stupid. > > > > has it occured to you to try the system out as is? nobody else has > > asked for it to be more unix like in the same way. perhaps there's > > good reason for it to be the way it is. > > To be fair, he's not talking about using Plan 9, just leveraging something > factotum-like under Linux. I think he should be commended for spreading > the 9love in the face of rampant Lennartism, quixotic though it may be. > > [-- Attachment #2: Type: text/html, Size: 1403 bytes --] ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [9fans] Factotum vs SASL 2014-12-02 15:40 ` plannine 2014-12-02 16:33 ` Wes Kussmaul 2014-12-02 20:32 ` Skip Tavakkolian @ 2014-12-02 22:20 ` Enrico Weigelt, metux IT consult 2 siblings, 0 replies; 25+ messages in thread From: Enrico Weigelt, metux IT consult @ 2014-12-02 22:20 UTC (permalink / raw) To: 9fans On 02.12.2014 16:40, plannine@sigint.cs.purdue.edu wrote: > To be fair, he's not talking about using Plan 9, just leveraging something > factotum-like under Linux. Exactly. I wanna get rid of dbus and polkit, replace it by something 9P-based. Before hacking up something on my own, I'm just looking how Plan9 handles such things. And once I'm starting to hack up something, I'd prefer (at least most of) it being usable in both worlds. > I think he should be commended for spreading the 9love in the face of > rampant Lennartism, quixotic though it may be. Interesting to see that the term "Lennartism" is used more and more in these days. I'm using it for quite a while, but still unsure whether I may claim the copyright for it ;-) hmm, waiting for the day when it gets its own wikipedia article ;-o cu -- Enrico Weigelt, metux IT consulting +49-151-27565287 ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [9fans] Factotum vs SASL 2014-12-02 4:00 ` Enrico Weigelt, metux IT consult 2014-12-02 4:08 ` erik quanstrom @ 2014-12-02 9:50 ` Richard Miller 2014-12-02 22:15 ` Enrico Weigelt, metux IT consult 1 sibling, 1 reply; 25+ messages in thread From: Richard Miller @ 2014-12-02 9:50 UTC (permalink / raw) To: 9fans > To mimic the usual Unix behaviour, I would need some getty/login-alike > program, which asks for login credentials and then starts up things > like shell or gui (some window-manager-/DE-alike program) as the > corresponding, which then is _not_ the hostowner. For this sort of functionality the computer needs to be running as a plan 9 cpu server, not a terminal in which by definition hostowner controls everything. Somewhere in /contrib there is a patch which makes a few changes to the cpu kernel to allow a login on the console by a user different from hostowner, who then becomes termowner with permissions over some but not all of the local hardware (eg keyboard and mouse but not disk). It's not hard to do. But it's only pretend security if the user has physical access to the machine. The "plan 9 way" is to keep the cpu server in a locked box and get another computer to be a terminal. A raspberry pi doesn't cost much. ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [9fans] Factotum vs SASL 2014-12-02 9:50 ` Richard Miller @ 2014-12-02 22:15 ` Enrico Weigelt, metux IT consult 0 siblings, 0 replies; 25+ messages in thread From: Enrico Weigelt, metux IT consult @ 2014-12-02 22:15 UTC (permalink / raw) To: 9fans On 02.12.2014 10:50, Richard Miller wrote: > For this sort of functionality the computer needs to be running as > a plan 9 cpu server, not a terminal in which by definition hostowner > controls everything. > > Somewhere in /contrib there is a patch which makes a few changes to > the cpu kernel to allow a login on the console by a user different > from hostowner, who then becomes termowner with permissions over > some but not all of the local hardware (eg keyboard and mouse but > not disk). It's not hard to do. Okay, that seems to go in the direction, I'm looking for. To get the traditional unix behaviour, we'd also need some virtual terminal multiplexer (which allows switching between VTs with different sessions), supporting multiple framebuffers/GPUs, keyboards, etc (eg. multiseat environments) - just giving the logged-in users only these virtual devices. Shouldn't be that hard to implement. Anyways, for now I'm not so much focused on doing that on real Plan9 system, instead using its concepts/tools (9P, factotum, ...) on a GNU/Linux system. > But it's only pretend security if the user has physical access > to the machine. Of course, you could still replace the disks, etc .. but that's an entirely different area. > The "plan 9 way" is to keep the cpu server in a locked box and > get another computer to be a terminal. A raspberry pi doesn't > cost much. Well, not very suited for mobile purposes (notebook, etc) :P cu -- Enrico Weigelt, metux IT consulting +49-151-27565287 ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [9fans] Factotum vs SASL 2014-12-01 6:28 ` Enrico Weigelt, metux IT consult 2014-12-01 7:00 ` lucio @ 2014-12-01 12:14 ` Stuart Morrow 1 sibling, 0 replies; 25+ messages in thread From: Stuart Morrow @ 2014-12-01 12:14 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs > The guy in front of the console should authenticate as a normal user But you do authenticate to Plan 9 as a normal user. On one node you're the hostowner, but to the *system* you authenticate as a normal user. One guy on here lately was actually attaching to his fileserver as none. A "system" is more than one of something, computers in this case. > only be allowed to access his own environment (no direct control over hw, etc). The hardware is part of his environment. > So, what about multiuser environments, where the guy in front of the > console is just an arbitrary user, who shouldn't be allowed to access > everything on the machine (nor disturb other users) ? Plan 9 is _decidedly_ multi-user. I don't really understand the question. Which console? Stuart ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [9fans] Factotum vs SASL 2014-11-29 19:46 ` Enrico Weigelt, metux IT consult 2014-11-29 19:46 ` erik quanstrom @ 2014-12-02 20:32 ` Skip Tavakkolian 2015-01-01 14:55 ` Teodoro Santoni 2 siblings, 0 replies; 25+ messages in thread From: Skip Tavakkolian @ 2014-12-02 20:32 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs [-- Attachment #1: Type: text/plain, Size: 5001 bytes --] if i understand correctly, the basic issues you're trying to solve (beyond authentication), are "delegation" and "authorization". because you're targeting non-plan9 environments, my comments will be focused on those environments. any decent IT with heterogeneous OS environments will have a Kerberos+LDAP (most likely embodied in ActiveDirectory) setup to do this. all sharable resources (services) will be located on servers which can authenticate and authorize users. the rest of my comments are inline: On Sat, Nov 29, 2014 at 11:46 AM, Enrico Weigelt, metux IT consult < enrico.weigelt@gr13.net> wrote: > On 18.11.2014 09:22, Skip Tavakkolian wrote: > > <snip> > > thanks folks ... seems I need to think through all of this more deeply. > > If I'm not completely mistaken, factotum can also handle various > authentication protocols, and may be the only one who really knows > the actual secrets. > > One scenario I'm thinking about is replacing the password-stores in > certain browsers by an factotum (maybe it could also be useful for > cert handling ?) > > A really cool feature, IMHO, would be able to connect my local factotum > to remote ones easily, so I'll get a similar feature like eg. lastpass > is doing for the web. For example, somebody like to give me access to > some remote application, but for some reason can't add my pubkey there > (eg. it doesn't even support such things), but doesn't want to give me > cleartext passwords, he could set things up in his (publically > accessible) factotum instance, which then handles all the auth stuff > for that application. > > delegation would require some sort of initial trust relationship. for example, Kerberos includes the ability to setup trust relationships between different realms. once trust is established, a user vouched for by a KDC in one realm can be authenticated and authorized to receive service in another realm. what you've described above would be like having two realms (yours and the other person's) each having a KDC (factotum) that handles a single identity. btw, Plan 9's authentication in similar to Kerberos. auth server is the KDC, and factotum is the client side (but factotum can also talk other protocols and can keep secrets). because all things are files in Plan 9, delegation between parties in the same realm can be accomplished by importing factotum's file system. cross-realm delegation might be possible with some changes but in practice it is more convenient to give factotum the credentials for all authdom's and let it deal with them. > By the way, that leads me to another topic, which is annoying me > for quite some time: policykit. > > For those, who have been spared of it: > > It's an invention of the freedesktop folks (or should I call them > "Lennartists" ? ;-o), some kind of proxy, which routes certain dbus > calls (based on certain policies) between several users (and root). > This way, eg. unprivileged users can still be given access to system > level stuff, like network-manager. And that's exactly the point which > regularily hit me (eg. some day my primary account suddenly wasn't > able to choose wireless networks anymore, and even the old fashioned > way via unix groups didn't help either). > > So, I'm thinking about a cleaner solution - obviously not dbus, but 9P. > > If i understand it correctly, in 9P, the server is in charge of handling > all the access control. So, I can't just write some simple 9P server, > mount it anywhere and magically expect it working just by file > ownerships (by the way: do they have any practical meaning at all ?). > > Obviously, the server needs to know who the calling user is and whether > he shall be allowed to access certain items - more precisely whether he > is in the right role right now. And these things could be depending on > other parameters (defined by other parties), eg. when reboot shall only > be allowed when logged-in locally, and no other blocking parts (eg. > important tasks) currently running. > as pointed out above, a shared trusted authority between the user and the service has to exist. once authenticated, authorization can then be handled by other means (e.g. unix or ldap group membership, etc). examples of this in plan9 are things like consolefs' /lib/ndb/consoledb (and because the root filesystem is served from the fileserver there's no need for ldap). > > Pretty clear, that these things shouldn't be implemented in each single > service separately, and not every service that might have an influence > here shall have to talk to everybody else. > > So, how would a Plan9 solution for these usecases look like ? > > In fact, I intend to rewrite network-manager to some 9p-based solution, > so I'd like to discuss this carefully before starting to lennert up > something stupid. > > > cu > > > > -- > Enrico Weigelt, > metux IT consulting > +49-151-27565287 > > [-- Attachment #2: Type: text/html, Size: 6226 bytes --] ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [9fans] Factotum vs SASL 2014-11-29 19:46 ` Enrico Weigelt, metux IT consult 2014-11-29 19:46 ` erik quanstrom 2014-12-02 20:32 ` Skip Tavakkolian @ 2015-01-01 14:55 ` Teodoro Santoni 2 siblings, 0 replies; 25+ messages in thread From: Teodoro Santoni @ 2015-01-01 14:55 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs Good afternoon, On Sat, Nov 29, 2014 at 08:46:08PM +0100, Enrico Weigelt, metux IT consult wrote: <snip> > A really cool feature, IMHO, would be able to connect my local factotum > to remote ones easily, so I'll get a similar feature like eg. lastpass > is doing for the web. For example, somebody like to give me access to > some remote application, but for some reason can't add my pubkey there > (eg. it doesn't even support such things), but doesn't want to give me > cleartext passwords, he could set things up in his (publically > accessible) factotum instance, which then handles all the auth stuff > for that application. > > By the way, that leads me to another topic, which is annoying me > for quite some time: policykit. > > For those, who have been spared of it: > > It's an invention of the freedesktop folks (or should I call them > "Lennartists" ? ;-o), some kind of proxy, which routes certain dbus > calls (based on certain policies) between several users (and root). > This way, eg. unprivileged users can still be given access to system > level stuff, like network-manager. And that's exactly the point which > regularily hit me (eg. some day my primary account suddenly wasn't > able to choose wireless networks anymore, and even the old fashioned > way via unix groups didn't help either). In both ways you should change the background on which the security would run. For network applications, a web browser must stay out of the project or rely on weaker security measures (auth with factotum, then the browser is authorized visiting some https site for signing on). Policykit and consolekit are crazy nonsense by design, strictly UNIX-speaking. If the user isn't wheel or root, but has to acceed network (both wireless or ethernet), graphics, certain areas instead of others, the adminstrator has to give h{im,er} access at login to everything is required to {,s}he. If, to do so, you can't use the programs you loved to limit privileges in SSH, and you want a single-sign-on to join wifi networks, printers, external drives, opening webbrowser and whatnot, the GUI components should be easily hackable to roll out the user experience required. And thinking about X11 today and the fuss about waylands and mirs... The whole thing is fucked up, imho. Your project is eating or exploiting to user level, at the end of this mini-essay, 85% of the operating system now. Like the classic X server, systemd+wayland or upstart/systemd+mir. It's not a bad thing! Lennartism is just a Will Hunting approach. Mixed with a bag full of shit. The way to go is writing a x server like you would write a TeX environment or a compiler toolchain, which will lead you rolling out a systemd better designed that doesn't make its way to pid 1. It's a lot of work. Are you sure you wouldn't like to try p9? Happy gregorian first of the year, -- Teodoro Santoni ^ permalink raw reply [flat|nested] 25+ messages in thread
end of thread, other threads:[~2015-01-01 14:55 UTC | newest] Thread overview: 25+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2014-11-17 5:03 [9fans] Factotum vs SASL Enrico Weigelt, metux IT consult 2014-11-17 5:57 ` Lyndon Nerenberg 2014-11-17 6:29 ` lucio 2014-11-17 13:58 ` erik quanstrom 2014-11-17 14:14 ` lucio 2014-11-18 8:22 ` Skip Tavakkolian 2014-11-29 19:46 ` Enrico Weigelt, metux IT consult 2014-11-29 19:46 ` erik quanstrom 2014-11-29 21:20 ` Enrico Weigelt, metux IT consult 2014-11-29 21:23 ` erik quanstrom 2014-12-01 6:28 ` Enrico Weigelt, metux IT consult 2014-12-01 7:00 ` lucio 2014-12-01 10:38 ` tlaronde 2014-12-01 10:45 ` lucio 2014-12-02 4:00 ` Enrico Weigelt, metux IT consult 2014-12-02 4:08 ` erik quanstrom 2014-12-02 15:40 ` plannine 2014-12-02 16:33 ` Wes Kussmaul 2014-12-02 20:32 ` Skip Tavakkolian 2014-12-02 22:20 ` Enrico Weigelt, metux IT consult 2014-12-02 9:50 ` Richard Miller 2014-12-02 22:15 ` Enrico Weigelt, metux IT consult 2014-12-01 12:14 ` Stuart Morrow 2014-12-02 20:32 ` Skip Tavakkolian 2015-01-01 14:55 ` Teodoro Santoni
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).