Re: [PATCH 01/04] Add multi-precision-integer maths library

[Adrian Bunk <bunk@stusta.de>]

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?


> >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.


> >>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.

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.


> Regards,
> David

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/