On 070622 21:40, Satyam Sharma wrote: > Hi Alexander, Johannes, > > But first: Have you checked the digsig project? It's been doing > (for some time) what your current patchset proposes -- and > it uses public key cryptosystems for the key management, > which is decidedly better than using secret-keyed hashes > (HMAC, XCBC). Also, digsig aims to protect executable > binaries in general, and not just suid / sgid ones. We have not heard about digsig before, thanks for pointing it out. After a short look over the source (correct me if I'm wrong): The most important difference between our project and digsig is that digsig relies on storing signatures inside the ELF file structure. Therefore a handmade binary-loader or just COFF binaries could be used to circumvent digsig. We decided against altering the file itself for that and some other reasons. The limitation to suid/sgid was only due to a limited amount of time we had for implementing our patch. For the future we are planning further uses like setting capabilities only for signed binaries. > Second: Can we have some discussion on the security model / > threat model / trust model / cryptographic key management > scheme of your signing mechanism? [I had read through the > [0/4] mail you had sent yesterday, but found no relevant > discussion on these aspects there.] Our scenario was as follows: Usually system administrators rely on cronjobs checking their binaries for unwanted suid-bits. Because of the obvious problems with this (time between cronjobs, performance) we wrote our patch to replace it. An admin would verify the to-be-installed binaries (e.g. by reading the source, checking the distribution's package signatures), sign them in a central location. He then distributes those signatures along with the installation packages onto his computers. There should only be one key in use at a site the public part of which is compiled into the kernel. Any kind of chain-of-trust should be handled in userspace by signing or not signing with the site-wide key depending on the earlier signatures in the chain. So far for the initial idea. Perhaps it would be useful to have more than one key or some more complex scheme for obtaining the keys and checking their validity. But as all of this would need to be part of the kernel we decided to rather keep it as simple as possible, anything complex is better and more flexibly done in userspace. > From the patchset, it appears you use a *common* secret key > for _all_ signed binaries, and it is set at kernel build-time itself: > [...] > Anyway, this is *totally* insecure and broken. Do you realize anybody > who lays hands on the kernel image can now _trivially_ extract the > should-have-been-a-secret key from it and use it to sign his own > binaries? We do realize that this is really really ugly, broken and nasty and nobody would or should ever want to use it for anything but playing around as it is atm. ;) We only used HMAC because it was already available inside the kernel, for implementing real asymetric cryptography there was simply no time. Of course our next objective is to implement that. Ciao, Alexander Wuerstlein.