From: Trond Myklebust <trond.myklebust@fys.uio.no>
To: "David Härdeman" <david@2gen.com>
Cc: Adrian Bunk <bunk@stusta.de>,
Christoph Hellwig <hch@infradead.org>,
keyrings@linux-nfs.org, linux-kernel@vger.kernel.org
Subject: Re: [Keyrings] Re: [PATCH 01/04] Add multi-precision-integer maths library
Date: Sun, 29 Jan 2006 16:28:20 -0500 [thread overview]
Message-ID: <1138570100.8711.63.camel@lade.trondhjem.org> (raw)
In-Reply-To: <20060129211310.GA20118@hardeman.nu>
On Sun, 2006-01-29 at 22:13 +0100, David Härdeman wrote:
> If you agree that the kernel keyring is the best place, it shouldn't be
> a big step to also agree that in-kernel signing is "good" since it
> allows you to use the key while it makes it possible for the kernel to
> refuse to divulge the private part...even to the user who added the key
> (i.e. yourself)...
No! I agree that the kernel keyring is a good place to keep keys because
it has been designed with the correct inheritance rules. I do not agree
with the above logic that the kernel is inherently safer than userland.
By the above logic, we should put libpam, openssl, kerberos, all login
programs, kdcs, etc all in the kernel. That will not happen!
> >>>...and what does this statement about "keys being safer in the kernel"
> >>>mean?
> >>
> >> swap-out to disk, ptrace, coredump all become non-issues. And in
> >> combination with some other security features (such as disallowing
> >> modules, read/write of /dev/mem + /dev/kmem, limited permissions via
> >> SELinux, etc), it becomes pretty hard for the attacker to get your
> >> private key even if he/she manages to get access to the root account.
> >
> >Turning off coredump is trivial. All the features that LSM provide apply
> >to userland too (including security_ptrace()), so the SELinux policies
> >are not an argument for putting stuff in the kernel.
> >
> >Only the swap-out to disk is an issue, and that is less of a worry if
> >you use a time-limited proxy in the daemon.
>
> How do you use a "time-limited proxy in the daemon" for your own
> keys/cerificates (e.g. ssh keys)?
I don't have to. Why are you apparently insisting on this weird fallacy
that a keyring can only hold one certificate at a time?
However if you want an example of how I can do this, just look to
kerberos. What is probably the world's most commonly used security
mechanism is entirely based on the concept of time-limited tickets. When
I log in, I get a TGT, which is a time-limited proxy ticket that allows
me to obtain more tickets without having to re-enter my password. This
again allows me to obtain "service tickets", i.e. time-limited proxies
with limited capabilities for any service that requires it.
Cheers,
Trond
next prev parent reply other threads:[~2006-01-29 21:28 UTC|newest]
Thread overview: 49+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-01-26 21:58 [PATCH 00/04] Add DSA key type David Härdeman
2006-01-26 21:58 ` [PATCH 01/04] Add multi-precision-integer maths library David Härdeman
2006-01-27 9:28 ` Christoph Hellwig
2006-01-27 20:07 ` David Howells
2006-01-27 20:41 ` David Härdeman
2006-01-27 22:19 ` [Keyrings] " Trond Myklebust
2006-01-27 23:35 ` Kyle Moffett
2006-01-28 0:27 ` Adrian Bunk
2006-01-28 3:45 ` Trond Myklebust
2006-01-28 7:17 ` Kyle Moffett
2006-01-28 10:39 ` Adrian Bunk
2006-01-28 0:22 ` Adrian Bunk
2006-01-28 10:46 ` David Härdeman
2006-01-28 13:03 ` Adrian Bunk
2006-01-28 17:09 ` David Härdeman
2006-01-28 16:37 ` [Keyrings] " Trond Myklebust
2006-01-28 16:57 ` David Härdeman
2006-01-29 3:20 ` Trond Myklebust
2006-01-29 11:33 ` David Härdeman
2006-01-29 12:29 ` Adrian Bunk
2006-01-29 13:09 ` Arjan van de Ven
2006-01-29 20:05 ` Steve French
2006-01-29 20:52 ` Arjan van de Ven
2006-01-29 21:41 ` Steve French
2006-02-06 12:31 ` David Howells
2006-01-29 23:18 ` Adrian Bunk
2006-01-29 13:18 ` David Härdeman
2006-01-29 23:36 ` Adrian Bunk
2006-01-30 18:09 ` Nix
2006-01-29 16:38 ` Trond Myklebust
2006-01-29 18:49 ` Dax Kelson
2006-01-29 19:10 ` Trond Myklebust
2006-01-29 21:29 ` David Härdeman
2006-01-29 21:46 ` Trond Myklebust
2006-01-29 21:13 ` David Härdeman
2006-01-29 21:28 ` Trond Myklebust [this message]
2006-01-29 22:02 ` David Härdeman
2006-01-29 22:05 ` Trond Myklebust
2006-01-29 22:54 ` Kyle Moffett
2006-01-29 23:07 ` Trond Myklebust
2006-01-29 23:15 ` Adrian Bunk
2006-01-29 21:09 ` Pavel Machek
2006-01-26 21:58 ` [PATCH 03/04] Add encryption ops to the keyctl syscall David Härdeman
2006-01-26 21:58 ` [PATCH 02/04] Add dsa crypto ops David Härdeman
2006-01-26 21:58 ` [PATCH 04/04] Add dsa key type David Härdeman
2006-01-27 1:10 ` [PATCH 00/04] Add DSA " Herbert Xu
2006-01-27 7:18 ` David Härdeman
2006-01-27 20:11 ` David Howells
2006-01-27 23:22 ` Herbert Xu
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1138570100.8711.63.camel@lade.trondhjem.org \
--to=trond.myklebust@fys.uio.no \
--cc=bunk@stusta.de \
--cc=david@2gen.com \
--cc=hch@infradead.org \
--cc=keyrings@linux-nfs.org \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®