On Tue, Jul 15, 2003 at 10:09:03PM +0200, Adam Chodorowski wrote:
> Yes, there is. :-) It's a bit of a hassle to set up manually, but Keychain
> fixes that for you quite nicely: http://www.gentoo.org/proj/en/keychain.xml
It's missing the "trusted binary" part. What I'm thinking is:
1. Signatures (SHA1, MD5, whatever) are calculated for trusted binaries
and put in an encrypted database (I would not include ssh in these).
The binaries would probably have to be statically linked. Passwords or
authentication keys to remote systems are also put in this database.
2. login' starts a password daemon and gives it a key/the user's password
to decrypt the above database. This daemon connects to the kernel.
3. When kernel runs a program, it calculates this signature (if some
flag is set, otherwise there might be too big a performance
penalty) from the binary and stores it.
4. When the program wants a password, it issues a special kernel call
to connect to the daemon and the kernel sends the signature along
with this request. If the signature matches one in the database, the
daemon responds with the key/password to connect to the remote system.
To some extent this scheme could be implemented in userland, but the
daemon would have to start the trusted programs which could be limiting
in case of interactively started programs and with a light kernel layer,
a similar scheme could be used to give access to other system resources
as well.
The case of automatic ssh passwords could be handled be allowing programs
trusted with this task to pass rights to the semi-trusted programs they
start. (Or maybe the semi-trusted process should have a trusted process
as its ancestor so that there are no untrusted programs between with the
not-untrusted not-trusted programs consisting only of e.g. xinit, the wm,
shell and xterm.)
Of course, there's still the case that the daemon or the kernel (and thus
the daemon) might be compromised, but I'm willing to take that risk.
Back to the copying problem, in a simple implementation the program that
copies the CVS repository to the remote server would be such a fully
trusted program with the signature stored in the database and scp would
be a semi-trusted program that gets rights from the copying wrapper to
access the database this time (if its signature matches), although it
normally wouldn't have the rights. (In a more complex implementation scp
would not be used.)
And, yes, something like EROS <http://www.eros-os.org/> might be a better
solution.
--
Tuomo
