Re: [9fans] Factotum vs SASL

[Skip Tavakkolian <skip.tavakkolian@gmail.com>]

[-- 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 --]