> > - The flag can be set by any user
> Fair. There are reasons why we don't allow this at the moment, though
> they may be going away soon.
Yes, I think this flag should protect the information from being
disclosed. The user is still responsible for keeping a backup, though.
> > - The owner may not change
> chattr +i $FILE
Yes, but this would prevent the key from being upgraded/changed. Basically
this rule is rather unneccessary, but won't hurt.
> > - The file can not be read
> > - The file can be executed by the owner
> > - The file can not be written to.
> chmod 0100 $FILE
This does not prevent root from reading it while the securelevel is 2. But
this is a definite must.
> > - If the flag is set while the file is open for writing, do not allow
> > further opening or reading, and let the write()s proceed.
> You've already stated that the flag bans writing.
Not for currently open exclusive handles. This is required for
transferring the key from one file to another securely without a race
condition.
> The second half of that really requires a revoke(2) call.
No problem with that, but the write handle I have must stay open.
> > The last rule is meant for upgrading the software: You ask (with your
> > passphrase) that the module appends the secret key to file X. It then
> > opens that file in append/exclusive mode, sets the flag, then writes
> > the key.
> I thought these were executables?
Yes, but they contain the key. If I were to upgrade the crypto routines, I
need to create a new file, write out the routines, write out the key and
close the file with whatever structures are needed. And while the key is
written, all read access must already be forbidden, or we have a race
condition here.
Simon
PGP public key available from ftp://phobos.fs.tum.de/pub/pgp/geier.asc
Fingerprint: 10 62 F6 F5 C0 5D 9E D8 47 05 1B 8A 22 E5 4E C1
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/