[9fans] Factotum vs SASL

[9fans] Factotum vs SASL

[Enrico Weigelt, metux IT consult]

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

[Lyndon Nerenberg]

> 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

[lucio]

> 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.
-------------------------------------------------------------------------------------

Re: [9fans] Factotum vs SASL

[erik quanstrom]

> 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

[lucio]

> 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.
-------------------------------------------------------------------------------------

Re: [9fans] Factotum vs SASL

[Skip Tavakkolian]

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

Re: [9fans] Factotum vs SASL

[Enrico Weigelt, metux IT consult]

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

[erik quanstrom]

> 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

[Enrico Weigelt, metux IT consult]

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

[erik quanstrom]

> 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

[Enrico Weigelt, metux IT consult]

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

Re: [9fans] Factotum vs SASL

[lucio]

> 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

[tlaronde]

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

Re: [9fans] Factotum vs SASL

[lucio]

> 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

[Enrico Weigelt, metux IT consult]

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

Re: [9fans] Factotum vs SASL

[erik quanstrom]

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

[plannine]

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

[Wes Kussmaul]

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

Re: [9fans] Factotum vs SASL

[Skip Tavakkolian]

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

Re: [9fans] Factotum vs SASL

[Enrico Weigelt, metux IT consult]

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

Re: [9fans] Factotum vs SASL

[Richard Miller]

> 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

[Enrico Weigelt, metux IT consult]

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

[Stuart Morrow]

> 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

[Skip Tavakkolian]

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

Re: [9fans] Factotum vs SASL

[Teodoro Santoni]

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