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

From: edward_at_paradigm4.com.au
Date: Tue 09 Apr 2002 - 06:03:48 BST

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... www.solucorp.qc.ca/virtualfs

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
[Next/Previous Months] [Main vserver Project Homepage] [Howto Subscribe/Unsubscribe] [Paul Sladen's vserver stuff]
Generated on Wed 06 Nov 2002 - 07:03:40 GMT by hypermail 2.1.3