On Sat, Jan 28, 2006 at 02:03:16PM +0100, Adrian Bunk wrote:
On Sat, Jan 28, 2006 at 11:46:11AM +0100, David Härdeman wrote:
On Sat, Jan 28, 2006 at 01:22:41AM +0100, Adrian Bunk wrote:
...
>If an attacker has enough privileges for attacking the daemon, he should
>usually also have enough privileges for attacking the kernel.
Not necessarily, if you have your ssh-keys in ssh-agent, a compromise of
your account (forgot to lock the screen while going to the bathroom?
did the OOM-condition occur which killed the program which locks the
screen? remote compromise of the system? local compromise?) means that a
large array of attacks are possible against the daemon.
In addition, as stated before, the "backup" account, or whatever user the
daemon which wants to sign stuff with your key is running as, might be
compromised.
Currently, if you want to give the daemon access to the keys via
ssh-agent (or something similar), you have to change the permissions on
the ssh-agent socket to be much less restricted (especially since it's
unlikely that you have permission to change the uid or gid of the socket
to that of the daemon). Alternatively you can provide the backup daemon
with the key directly (via fs, or loaded somehow at startup...etc), but
then a compromise of the daemon means that the attacker has the private
key.
Finally, the in-kernel system also provides a mechanism for the daemon
to request the key when it is needed should it realize that the proper
key is missing/has changed/whatever.
I'm sorry, but I'm still not getting the point:
Which part of this task is technically impossible to implement through a
userspace daemon?
See my latest reply to Trond...putting the keys in the kernel makes them
as secure as they can be without having specialized hardware (e.g.
smartcards).
>The number of different attacks might be lower, but you haven't
>completely solved any problem.
Many of the problems are unsolveable without having specialized hardware
(i.e. a smartcard). The fact that the dsa patch is not a panacea does
not mean that it can't, or that we shouldn't strive to, improve upon the
current situation
I'm still not understanding the big improvements when doing it in the
kernel instead of doing it in a userspace daemon.
You said it yourself above...the number of different attacks is lower
>>In addition, the dsa key code can be used to implement signed binaries
>>and signed modules.
>>...
>
>Checking signatures on modules sounds like a job for module-init-tools
>(if there's any real benefit in signing GPL'ed modules).
No, not really, take a look at http://lwn.net/Articles/92617/ for
details of how signed modules could work (public key is merged into
kernel at build time, private key is used to build modules with embedded
signature, kernel checks module sigs at load-time using the embedded public
key, so checks can't be in module-init-tools).
The only point in this lwn article that is not solvable outside of the
kernel is if distributions want to prevent loading of modules they
haven't authorized.
Ehh...how do you provide the features of signed modules in user-space?
The lwn article outlines how distributions can use this for demanding
money from module vendors. Distributions can do this if they want to,
but this is nothing we should add a single byte of code for.
There are already distributions with the patch in their kernel (Fedora),
so why would they care if signed modules patches are added to the
vanilla kernel or not?
On the other hand, it does add functionality which is useful to some
users even if it is not useful to all.
Regards,
David
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
