[9fans] p9p/linux factotum port

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

Re: [9fans] p9p/linux factotum port

[erik quanstrom]

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

factotum has been running for years on linux, though it doesn't
bother interacting with the kernel or pam.

- erik

Re: [9fans] p9p/linux factotum port

[Brian L. Stuart]

> is anyone already working on an factotum port to p9p or native Linux ?

P9P already has factotum.

BLS

Re: [9fans] p9p/linux factotum port

[a]

// is anyone already working on an factotum port to p9p or native Linux ?

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

Re: [9fans] p9p/linux factotum port

[Eric Van Hensbergen]

On Tue, May 6, 2008 at 2:49 PM, Enrico Weigelt <weigelt@metux.de> wrote:
>
>  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

Re: [9fans] p9p/linux factotum port

[ron minnich]

fac^T^T

oh, your command completion is broken?

ron

Re: [9fans] p9p/linux factotum port

[Roman Shaposhnik]

On Tue, 2008-05-06 at 15:55 -0400, erik quanstrom wrote:
> > 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.
> >
>
> factotum has been running for years on linux, though it doesn't
> bother interacting with the kernel or pam.

Any particular (security?) reason for not having a PAM-aware factotum
or is it just lack of interest?

Thanks,
Roman.

Re: [9fans] p9p/linux factotum port

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

Re: [9fans] p9p/linux factotum port

[Enrico Weigelt]

* a@9srv.net <a@9srv.net> wrote:

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


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

Re: [9fans] p9p/linux factotum port

[Roman Shaposhnik]

On Tue, 2008-05-06 at 16:19 -0400, erik quanstrom wrote:
> >
> > 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.

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.

Re: [9fans] p9p/linux factotum port

[Charles Forsyth]

> b) the kernel doesn't know of usernames.

and whose fault is that?

Re: [9fans] p9p/linux factotum port

[Ashwin Ganti]

On Tue, May 6, 2008 at 1:22 PM, Enrico Weigelt <weigelt@metux.de> wrote:
> * a@9srv.net <a@9srv.net> wrote:
>
>  > 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 ?

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/
Although I still have to work on some feedback from Russ to get it
polished so that it can be made part of p9p.

>
>  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 integer
user ids. This daemon would be contacted by the kernel to resolve the
user names it
gets after parsing the capabilities written to the device files (by the
process and the host
owner's factotum)". I think NFS solves this in a similar way?

For the port I worked around by adding usernames as string equivalents
of uids (like "1001") which is ugly but can be avoided with this
daemon.
Check out the paper for details.

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

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

Re: [9fans] p9p/linux factotum port

[Enrico Weigelt]

* Ashwin Ganti <ashwin.ganti@gmail.com> wrote:

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


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