Re: [9fans] factotum vs. SASL+TLS+applications
> The following is all hypothetical. I'm curious about how people > think auth(2)/factotum(4) could be adapted to support the use > case ... > > factotum was intended to handle the authentication dance on behalf > of network apps. But in the case of things like IMAP, it really > just stores the client's login/password, and provides a bit of > helper glue for CRAM-MD5. Similarly for ftpfs. > > I'm curious why upasfs and ftpfs are outliers in only using factotum > as a credential store, but leaving the actual authentication protocol > dance in the clients/servers. The "Security" paper (/sys/doc/auth) > strongly hints that these parts of the application protocols were > meant to be outsourced to factotum. Section 2.2 in particular > argues that the auth modules should be implemented once in factotum, > for consumption by the rest of the system. Probably simple expediency. > > > To require a specific SASL mechanism, add "sasl=scram-md5" (using > "sasl=*" as a default if you need to fall back for some reason). This all sounds fairly reasonable. I think that patches to this effect would be worth integrating. > Of course all of this needs to be glued into auth(2) in a way that > doesn't destroy the existing API. But it does need to handle > factotum replacing the underlying connection to the client/server > with one that has been pushtls()ed by factotum itself. I'm not sure how factotum can have this action at a distance. I think the pushtls is stuck in the client itself -- though, the auth code can probably return the parameters needed for this. -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T8154f8e7b95f1a8c-M16c4ed9e42454938bd4e69b7 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] factotum vs. SASL+TLS+applications
i'd like to see the auth server do more of the work. -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T8154f8e7b95f1a8c-M269a6e45351ce1fc554237ae Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] factotum vs. SASL+TLS+applications
And work under p9p. Me too! Plug in a proper X-based WM and I can get some performance out of my rather dated equipment again. Lucio. On 1/24/20, Lyndon Nerenberg wrote: > The following is all hypothetical. I'm curious about how people > think auth(2)/factotum(4) could be adapted to support the use > case ... > -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T8154f8e7b95f1a8c-M3c39e01d7020050b189dcee5 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
[9fans] factotum vs. SASL+TLS+applications
The following is all hypothetical. I'm curious about how people think auth(2)/factotum(4) could be adapted to support the use case ... factotum was intended to handle the authentication dance on behalf of network apps. But in the case of things like IMAP, it really just stores the client's login/password, and provides a bit of helper glue for CRAM-MD5. Similarly for ftpfs. I'm curious why upasfs and ftpfs are outliers in only using factotum as a credential store, but leaving the actual authentication protocol dance in the clients/servers. The "Security" paper (/sys/doc/auth) strongly hints that these parts of the application protocols were meant to be outsourced to factotum. Section 2.2 in particular argues that the auth modules should be implemented once in factotum, for consumption by the rest of the system. Beyond the layering issue, how upasfs does IMAP authentication has always bugged me. The "/imaps/..." path handles the "native TLS on port 993" case, but upasfs(4) says "... Authentication is delegated to factotum(4)" which is mostly a lie in the "/imap/..." case. Given a connection to port 143, upasfs will negotiate a simple cleartext login, while blithely ignoring the server's advertised security policy. Specifically, it ignores the LOGINDISABLED and STARTTLS capability advertisments, and there's no way to require STARTTLS, even in the absence of the capability (e.g. work around MITM downgrade attacks). And the supported SASL mechanisms are woefully out of date. Obviously none of this is factotum's fault. But getting this right is a bit tricky, which strongly argues for implementing this, once and correctly, in a single location. I've looked at pushing this into factotum before. The current big fail is the flat 'proto=XXX' part of the factotum key namespace. This doesn't scale with SASL. E.g. for some protocol 'imap' we end up with: proto=imap Plain old IMAP LOGIN (and SASL PLAIN) proto=imap-cram-md5 SASL CRAM-MD5 proto=imap-scram-md5SASL SCRAM-MD5 [...] plus all the '+tls' variants. And yet it's going to be the same passphrase underlying all of these. In theory there should only be one factotum entry for each IMAP server/userid instance; it should not be necessary to update your sectore just because the server's authentication scheme has changed. And there's no reason at all to duplicate factotum records just to handle the '+tls' variants of each of the above. What this really needs is for factotum to gain knowledge of SASL as a general mechanism, apart from any specific application protocol. Then there needs to be a mapping between the application protocol being authenticated and the underlying SASL mechanism drivers. The challenge then becomes how to express this mapping in the factotum records. As an example, let's consider an IMAP (port 143) server. The default policy should be to use TLS if the server advertises it (STARTTLS), and select the strongest compatible SASL mechanism the server supports (based on re-issuing CAPABILITY after STARTTLS, and honouring LOGINDISABLED). This would have a key lookup like: proto=imap user=lyndon server=orthanc.ca !password=notlikely To require a successful STARTTLS even if the capability is not advertised, add "tls=required" to the record. To require a specific SASL mechanism, add "sasl=scram-md5" (using "sasl=*" as a default if you need to fall back for some reason). Of course all of this needs to be glued into auth(2) in a way that doesn't destroy the existing API. But it does need to handle factotum replacing the underlying connection to the client/server with one that has been pushtls()ed by factotum itself. --lyndon -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T8154f8e7b95f1a8c-M10a72106b236119ee526b90a Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] Factotum vs SASL
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
Re: [9fans] Factotum vs SASL
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.
Re: [9fans] Factotum vs SASL
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.
Re: [9fans] Factotum vs SASL
On 12/02/2014 10:40 AM, plann...@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
Re: [9fans] Factotum vs SASL
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.weig...@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
Re: [9fans] Factotum vs SASL
9love is tough love. On Tue, Dec 2, 2014 at 7:40 AM, plann...@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.
Re: [9fans] Factotum vs SASL
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
Re: [9fans] Factotum vs SASL
On 02.12.2014 16:40, plann...@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
Re: [9fans] Factotum vs SASL
On Mon, Dec 01, 2014 at 09:00:46AM +0200, lu...@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
Re: [9fans] Factotum vs SASL
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.
Re: [9fans] Factotum vs SASL
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
Re: [9fans] Factotum vs SASL
On 01.12.2014 11:38, tlaro...@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
Re: [9fans] Factotum vs SASL
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
Re: [9fans] Factotum vs SASL
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.
Re: [9fans] Factotum vs SASL
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
Re: [9fans] Factotum vs SASL
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
Re: [9fans] Factotum vs SASL
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
Re: [9fans] Factotum vs SASL
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
Re: [9fans] Factotum vs SASL
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.weig...@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
Re: [9fans] Factotum vs SASL
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
Re: [9fans] Factotum vs SASL
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. -
[9fans] Factotum vs SASL
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
Re: [9fans] Factotum vs SASL
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
Re: [9fans] Factotum vs SASL
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. -