[9fans] linux reinvents factotum, secstore ...
erik quanstrom
http://lwn.net/Articles/344117
- erik
Daniel Lyons
On Aug 6, 2009, at 12:13 PM, erik quanstrom wrote:
> poorly. massive, overengineered, and yet lacking:
>
> http://lwn.net/Articles/344117
Ugh.
A brief apology on their behalf, though. I have been trying to
understand the workings of factotum, secstore, auth/keyfs and whatnot
for a while and I'm just now starting to get the feeling that I might
have a grasp on how all these things work together in concert to do
their jobs.
There is a propensity to develop software starting from the interface
working backwards to the functionality. When enough people reduplicate
a functionality, they decide to move the functionality out. This is
what you're going to get when you evolve software rather than
architect it. One of the things I have been impressed with in Plan 9
is that generally each layer of abstraction is comprehensive. On Linux
there is a tendency to have to keep adding more layers upon the
layers. This security framework, for example, relies on D-Bus for
communication. The appearance of hal, the "hardware abstraction layer"
a few years ago struck me too. Isn't that what the OS is supposed to
provide? Maybe it would have been feasible to add whatever it adds if
more of the drivers were in user space rather than kernel space.
It's easy for me to object to what they're coming up with but it would
be hard for me to describe in detail how exactly factotum + all the
other stuff encompass it, and I don't think that the paper we have on
factotum or the section in nemo's book are sufficient either. As a
devil's advocate, in my Mac keychain I have 13 keys related to file
shares and 22 WEP keys. I have my SSH key on 24 machines. Then I have
270 web form passwords or internet passwords in my keychain. Does
factotum handle web passwords? I'm presuming not but I don't really
know because I generally surf with Safari or Firefox outside Plan 9.
I'm not complaining about the browser situation, I'm just saying, it
seems to me that the average user probably has more website usernames
and passwords than everything else combined. That's certainly the case
with me. Could factotum be adapt to integrate with a browser and store
web form secrets? If so that would be a compelling objection, since it
looks like Firefox isn't going to start using their security framework
anytime soon. And who can blame them? It already has a ton of
dependencies and porting issues and this can only exacerbate it.
It might raise our profile a bit if someone who has a comprehensive
understanding of the security framework in Plan 9 would write a
rebuttal to this announcement, something along the lines of "Plan 9:
An Integrated Approach to Grid Computing" by Andrey Mirtchovski, Rob
Simmonds and Ron Minnich. That paper works largely as a refutation of
the complexity of the Globus Toolkit. It would also be helpful to
people like myself who are recent adopters of Plan 9 and don't have a
comprehensive understanding of the security architecture—perhaps
because we've been poisoned by systems like Mac OS X Keychain and SSH.
—
Daniel Lyons
erik quanstrom
> factotum handle web passwords?
yes, it does. abaco and hget already use factotum
for http passwords.
> with me. Could factotum be adapt to integrate with a browser and store
> web form secrets? If so that would be a compelling objection, since it
> looks like Firefox isn't going to start using their security framework
> anytime soon. And who can blame them? It already has a ton of
> dependencies and porting issues and this can only exacerbate it.
sure. you could integrate factotum and firefox.
- erik
Roman Shaposhnik
> poorly. massive, overengineered, and yet lacking:
>
> http://lwn.net/Articles/344117
This looks like a case in desperate need of Peter Gutmann's Wave
Therapy:
http://diswww.mit.edu/bloom-picayune/crypto/14238
"Whenever someone thinks that they can replace SSL/SSH with something
much
better that they designed this morning over coffee, their computer
speakers
should generate some sort of penis-shaped sound wave and plunge it
repeatedly into their skulls until they achieve enlightenment."
Thanks,
Roman.
Roman Shaposhnik
> It's easy for me to object to what they're coming up with but it
> would be hard for me to describe in detail how exactly factotum +
> all the other stuff encompass it, and I don't think that the paper
> we have on factotum or the section in nemo's book are sufficient
> either. As a devil's advocate, in my Mac keychain I have 13 keys
> related to file shares and 22 WEP keys. I have my SSH key on 24
> machines. Then I have 270 web form passwords or internet passwords
> in my keychain. Does factotum handle web passwords? I'm presuming
> not but I don't really know because I generally surf with Safari or
> Firefox outside Plan 9. I'm not complaining about the browser
> situation, I'm just saying, it seems to me that the average user
> probably has more website usernames and passwords than everything
> else combined. That's certainly the case with me. Could factotum be
> adapt to integrate with a browser and store web form secrets? If so
> that would be a compelling objection, since it looks like Firefox
> isn't going to start using their security framework anytime soon.
> And who can blame them? It already has a ton of dependencies and
> porting issues and this can only exacerbate it.
These are reasonable questions (and many of them have "yes" as the
answer ;-)) but I have a more
fundamental objection here: the desktop is just NOT the place for such
a functionality to originate from. The very
concept of a fixed desktop that resides on a physical piece of
hardware that you own feels so 20th century
to me. One way or the other the online identity issue is going to be
settled. For contenders, though, I'd
rather look at: factotum or things like OAuth.
I don't think there's a reasonable conversation to be had with folks
struggling to provide solutions
for taking the pain out of managing plain text passwords. The pain is
there for a reason.
Thanks,
Roman.
Daniel Lyons
I agree, and I think this is one of the most attractive things to me
about Plan 9.
> I don't think there's a reasonable conversation to be had with folks
> struggling to provide solutions
> for taking the pain out of managing plain text passwords. The pain
> is there for a reason.
I couldn't agree more. One of the first things that piqued my interest
in Plan 9 was finding out that 9p's authentication system works a lot
like Kerberos. I am very annoyed by security theater, which is one
reason I don't object at all to the host-owner security model Plan 9
uses.
—
Daniel Lyons
erik quanstrom
> answer ;-)) but I have a more
> fundamental objection here: the desktop is just NOT the place for such
> a functionality to originate from. The very
> concept of a fixed desktop that resides on a physical piece of
> hardware that you own feels so 20th century
> to me. One way or the other the online identity issue is going to be
> settled. For contenders, though, I'd
> rather look at: factotum or things like OAuth.
X11 way back when, for all its faults, was more network
centric than openview or anything that came after.
- erik
ron minnich
used to implement a protocol for extracting the needed secrets. "
some things never change. But no, I guess we should not be surprised.
ron
Ethan Grammatikidis
X11 isn't a desktop, it tries very hard not to define a look and feel, but it has to include inter-app communications to support the supposedly desirable drag & drop as well as any copy/paste beyond plain text. In fact my big beef with dbus is that everything is all hot-all-over about dbus when it needs to be using X IPC.
--
Ethan Grammatikidis
Those who are slower at parsing information must
necessarily be faster at problem-solving.
Daniel Lyons
On Aug 7, 2009, at 7:06 AM, Ethan Grammatikidis wrote:
> X11 isn't a desktop, it tries very hard not to define a look and
> feel, but it has to include inter-app communications to support the
> supposedly desirable drag & drop as well as any copy/paste beyond
> plain text. In fact my big beef with dbus is that everything is all
> hot-all-over about dbus when it needs to be using X IPC.
My beef is that they were hot-all-over CORBA not too long ago. I
expect in another three years nobody will be using D-Bus, they'll be
using some new layer that sits on top of it... ad nauseam. Outside
Plan 9 I don't see anyone solving two problems with one technology;
instead, they're just solving one problem and introducing a new one.
—
Daniel Lyons
ron minnich
> My beef is that they were hot-all-over CORBA not too long ago. I expect in
> another three years nobody will be using D-Bus, they'll be using some new
> layer that sits on top of it... ad nauseam. Outside Plan 9 I don't see
> anyone solving two problems with one technology; instead, they're just
> solving one problem and introducing a new one.
actually, corba is still in there if you use GNOME.
ron
Daniel Lyons
I think you get what I'm saying.
—
Daniel Lyons
David Leimbach
—
Daniel Lyons
Uriel
> Yeah they were hot on CORBA, and KDE folks were doing DCOP, which was
> derived from some X11 ICE thing... Neither of them was that great, and
> somehow they've both come back to DBUS.
> I don't honestly know the rhyme or reason for any of it. Anyone who thought
> CORBA was the answer didn't seem to understand the question.
The problem with CORBA is that it doesn't use XML, fortunately DBUS fixes that.
uriel