> > I donīt see this problem when the kernel handles this problem:
> > - program calls kernel seteuid_auth(authinfo)
> If you're going to do this, either you've got to make some special new
> kernel-to-user communication system, or you may as well make the
> authenticator a kernel module.
Sometimes, the authenticator may have to call other kernel functions
i.e. to check a Kerberos ticket against a K5 server. This is much easier
in user space and IMHO doesnīt belong into the kernel. The kernel module
should have as little functionality as possible.
> > - kernel blocks program and passes authinfo to authenticator
> A normal blocked process is quite killable. If, on the other
> hand, you arrange for temporary immortality, you'd better arrange
> to revoke it at some point if the authenticator is missing or
> confused. *Somebody* has to handle errors, and if the kernel
> has to detect them and unimmortalize the process...
The problem could be solved with a killable blocked process, as well.
Here, the kernel would have to handle a different table for
authenticator
ids and mark an id invalid if the process belonging to the id is killed.
> > - authenticator verifies authinfo and passes back status
> Ah, you did intend a brand new communication method after all.
> Again, better to have a module, or have the authentication
> request be fully userspace. Much simpler and more robust,
> and like I said it's not easy to kill a process and get the
> same PID quickly...
A kernel <-> userspace communication isnīt that brand-new. There are
already several examples like kerneld using a communication like this.
In terms of security, i think all "hard to do"s should be turned into
"impossible"s. Itīs probably easier to make an exclusive communication
between kernel and one application bullet-proof than a communication
between the application and a random second one.
> > The kernel would need to check the authenticator and i.e. signal
> > init if the authenticator dies.
> You want not only a new system call, but a new communication method,
> a new task for init, and error checking for all of the above?
To get a more secure Linux, i think the above would be just one stone
in a Mosaic... We would also need configurable permissions for all kind
of resources like i.e. ACLs for files and sockets, or even ACLs for
certain system calls.
Jochen