Messages in this thread | | | Date | Tue, 26 Jun 2007 07:43:34 +0530 | From | "Satyam Sharma" <> | Subject | Re: [PATCH] Check files' signatures before doing suid/sgid [2/4] |
| |
On 6/26/07, Alexander Wuerstlein <snalwuer@cip.informatik.uni-erlangen.de> wrote: > [...] > Nope. I unluckily wrote 'userspace' where I should have said something else: > Chain-of-trust is handled in what I would label 'Adminspace' (Where we do the > signing as in points 1 and 2). There is a very small number of signatures (in > our example one) known to the kernel and only those are trusted, and those are > applied to the binaries by the administrator in your point 2. The kernel does > and should never rely on userspace to tell it which signatures are trustworthy. > Only the administrator may do so by means of the signatures directly compiled > into the kernel. > > So in short: Chain-of-trust is handled by the administrator in his secure > central location.
Ok, so the "trust chain" you're talking about is simply the decision of the admin to compile-in the (verified and trusted) public keys of known trusted entities into the kernel at build time. That is not really scalable, but I guess you might just as well impose such a restriction for sake of simplicity.
[ I initially thought a scenario where a given binary is signed by an entity whose corresponding public key is _not_ present in the kernel, but who does possess a signature -- over its name, id and public key -- by another entity whose corresponding public key _is_ built into the kernel). Then at the time of verification there's really no other alternative to *build* the entire chain at the _point of verification_ (in-kernel) itself ... but this obviously introduces huge and ugly complexities that you'd have a hard time bringing into the kernel :-) That "signature over name, id and public key" could be a _certificate_ (if you care about following standards), and building their chains in-kernel ... well. But if you really want to differentiate between kernel and userspace from security perspective, and want to give such functionality, I don't see any easy way out. ]
> >> 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. > > > > Well, if you're trusting (privileged) userspace already, I'm suddenly not so > > sure as to what new is this patchset bringing to the table in the first place > > ... > > We do not trust any userspace application, see above. > > > could you also describe the attack vectors / threats that you had in mind > > that get blocked with the proposed scheme? > > We focus on attacks where an attacker may alter some executable file, for > example by altering a mounted nfs-share, manipulating disk-content by simply > pulling a disk, mounting it and writing to it, etc. > > This relies on the kernel beeing trustworthy of course, so one would need to > take special measures to protect the kernel-image from beeing similarly > altered. One (somewhat not-so-secure method) would be supplying kernel images > by PXE and forbidding local booting, another measure would be using a TPM > and an appropriate bootloader to check the kernel for unwanted modifications.
Kernel-userspace differentiation from security perspective is always tricky (so this is why I pointed you to the discussions whenever such stuff, such as asymmetric crypto and modsign etc are proposed to be merged). It's definitely not impossible to compromise a _running_ kernel from privileged userspace, if it really wanted to do so ...
Satyam - 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/
| |