[9fans] p9p/linux factotum port
Enrico Weigelt
Hi folks,
is anyone already working on an factotum port to p9p or native Linux ?
I've just wrote a patch to Linux kernel which allows changing
another process' privileges (uid, etc). The /dev/caphash and
/dev/capuse devices (IMHO) can be simulated from userspace.
cu
--
---------------------------------------------------------------------
Enrico Weigelt == metux IT service - http://www.metux.de/
---------------------------------------------------------------------
Please visit the OpenSource QM Taskforce:
http://wiki.metux.de/public/OpenSource_QM_Taskforce
Patches / Fixes for a lot dozens of packages in dozens of versions:
http://patches.metux.de/
---------------------------------------------------------------------
a...@9srv.net
wait, what?
: sh;ls -l /9/bin/factotum
-rwxr-xr-x 1 anthony admin 312148 Mar 1 13:23 /9/bin/factotum
// I've just wrote a patch to Linux kernel which allows changing
// another process' privileges (uid, etc).
is this related to last year's work by Ashwin Ganti, presented at
IPW9 2007?
http://plan9.bell-labs.com/iwp9/papers/13.p9auth.pdf
Anthony
Brian L. Stuart
P9P already has factotum.
BLS
erik quanstrom
>
> is anyone already working on an factotum port to p9p or native Linux ?
>
> I've just wrote a patch to Linux kernel which allows changing
> another process' privileges (uid, etc). The /dev/caphash and
> /dev/capuse devices (IMHO) can be simulated from userspace.
>
factotum has been running for years on linux, though it doesn't
bother interacting with the kernel or pam.
- erik
Eric Van Hensbergen
>
> Hi folks,
>
> is anyone already working on an factotum port to p9p or native Linux ?
>
> I've just wrote a patch to Linux kernel which allows changing
> another process' privileges (uid, etc). The /dev/caphash and
> /dev/capuse devices (IMHO) can be simulated from userspace.
>
Kernel versions of these devices have been done by Ashwin Ganti.
There wasn iwp9 paper about it.
-eric
ron minnich
oh, your command completion is broken?
ron
Roman Shaposhnik
Any particular (security?) reason for not having a PAM-aware factotum
or is it just lack of interest?
Thanks,
Roman.
Enrico Weigelt
> http://plan9.bell-labs.com/iwp9/papers/13.p9auth.pdf
cool, I wasn't aware of this. never ever seen a patch for
the cap devices. does anyone have link ?
My decision for the *uid files (instead of cap devices) was
because:
a) more flexibilty (not only limited to factotum stuff)
b) the kernel doesn't know of usernames.
So, IMHO, the cap handling should be done in userland.
erik quanstrom
> Any particular (security?) reason for not having a PAM-aware factotum
> or is it just lack of interest?
>
if i understand p9p correctly, it's object is to get along with
the system, not replace bits of it.
Roman Shaposhnik
I see. Speaking of replacing bits: I'm sure I'm not the only one
who has the trouble of remembering passwords for the gazillions
of websites I have accounts on. So I'm just wondering how difficult
would it be to write a Firefox plugin that would talk to
factotum and treat my passwords as clear-key authentication?
Or would it be a bad idea to begin with?
Thanks,
Roman.
Charles Forsyth
and whose fault is that?
Enrico Weigelt
> The device driver is in:http://gsoc.cat-v.org/hg/lincapdevice/
> The authentication server port is in:
> http://gsoc.cat-v.org/hg/p9pauthsrv/
Great, I'll have a look at it :)
> > My decision for the *uid files (instead of cap devices) was because:
> > a) more flexibilty (not only limited to factotum stuff)
> > b) the kernel doesn't know of usernames.
>
> That is one of the future improvements that I had listed in the
> paper. "It would also be nice to have a user space mapping daemon
> that maps the string user names and the integeruser ids. This
> daemon would be contacted by the kernel to resolve the user names
> it gets after parsing the capabilities written to the device
> (by theprocess and the hostowner's factotum)".
Yeah, I already though about this way before. But I actually
don't like this approach (kernel calling userland) not very much.
There are too many ways to things get wrong (deadlocks, etc).
Another approach could be pushing the uid<->name table through
an special file. This would be much simpler/stable, but then
we'll loose the the ability for fully dynamic/external account
management (eg. NIS or DB-driven), and on systems w/ many
accounts we'll waste a lot of memory :(
Nevertheless we'll need an userland daemon at some point.
So I chose to keep the kernel change as small as possible
(my patch is quite small - most of it are some generic helpers)
and also quite universal (can also be used for a lot of other
things like debugging). My plan is to serve the cap* devices
entirely from userland (via sockets).
> I think NFS solves this in a similar way?
That's very different. NFS itself doesn't know of usernames,
just UIDs. But it has an mapping service, which looks up
the username for some given UID and ask the remote side which
UID this name corresponds there (actual mapping is uid->uid).
This thing is quite unstable, and I don't like to go this
way again.
> For the port I worked around by adding usernames as string
> equivalents of uids (like "1001") which is ugly but can be
For that to work, the server has to understand this. I have
my doubts that native Plan9 will do ;-o
> > So, IMHO, the cap handling should be done in userland.
> Well, I feel it is more secure to have the kernel manage the
> capabilities and do the actual identity change. We trust
> the kernel (it is part of the TCB)
Well, on Linux, you'll also have to trust some parts of the
userland, at least things like modprobe ;-P
Of course this should be minimized, but in solutions there
will be an userland daemon which must be trusted. You mapping
service could be abused quite the same as my cap service.
I don't see any way out of this, as long as the kernel isn't
aware of usernames completely by itself (and this would require
a major break w/ Unix philospophy).