re: [vserver] pam_capability module

About this list Date view Thread view Subject view Author view Attachment view

Date: Tue Apr 09 2002 - 01:03:48 EDT

On Monday, 8 April 2002 at 22:42, Jacques Gelinas wrote:

> I have designed a package called aclfsd as part of the virtualfs project. aclfsd
> provide a very fine grain access to file system and network resources. Using
> ACL, you can tell who can bind to which port for example. Wonder if this
> has a future...

As far as I understand it, it provides the alternative to glibc so it relies
on non-modified binaries that are not statically linked, which is ok for some network services.

I'd like to see something more universal that that, though.


There is an authorization server ( could be a kernel module with syscall/ioctl interface ) which is
tied to a database, listing all restricted objects ( files/directories/ports/protocols/syscalls/etc ),
allowed methods (e.g.write/read/open/listen/connect/chmod etc) ,and their corresponding

All applications initially don't have access to any resource.
They request permissions for particular object from the auth server,
providing their credentials and ( optionally ) stating for how long they need this resource.

Auth server checks the credentials, current policies and possibly grants a "ticket" allowing
access to a resource. "Credentials" may include md5sum+inode+attrs of the executable
and/or some "passwords" or whatever. There may be more than one reference to the same
object/method but with different credentials, thus giving longer/shorter lasting tickets
to different programs.

each task structure would contain a reference to a hashed array of tickets issued for
the current task. All tickets would have their expiration dates, after which they are no longer
valid and get deleted from the array.

There may be a "full access to everything" object in the database, which would grant
infinite ticket to access everything, thus simulating the present "power of root".

This is sort of getting into LIDS/selinux territory but possibly more generic
and I haven't seen the idea of an expiring tickets per task anywhere else.

I think having a bucket of tickets tied to each task may speed up
things because auth server wouldn't need to be consulted each time
a program needs to open a file/create a connection etc.

Just my $0.02


About this list Date view Thread view Subject view Author view Attachment view

This archive was generated by hypermail 2.1.4 : Mon Aug 19 2002 - 12:01:01 EDT