* Re: [RFC PATCH v3 04/12] x86/sgx: Require userspace to define enclave pages' protection bits
From: Andy Lutomirski @ 2019-08-04 22:20 UTC (permalink / raw)
To: Jarkko Sakkinen
Cc: Andy Lutomirski, Sean Christopherson, Schaufler, Casey,
James Morris, linux-sgx, Dave Hansen, Cedric Xing, Jethro Beekman,
Dr . Greg Wettstein, Stephen Smalley, LSM List
In-Reply-To: <20190801163839.wvcnq57hity4wwrk@linux.intel.com>
On Thu, Aug 1, 2019 at 9:38 AM Jarkko Sakkinen
<jarkko.sakkinen@linux.intel.com> wrote:
>
> On Mon, Jul 15, 2019 at 03:29:23PM -0700, Andy Lutomirski wrote:
> > I would say it differently: regardless of exactly how /dev/sgx/enclave
> > is wired up under the hood, we want a way that a process can be
> > granted permission to usefully run enclaves without being granted
> > permission to execute whatever bytes of code it wants. Preferably
> > without requiring LSMs to maintain some form of enclave signature
> > whitelist.
>
> Would it be better to have a signer whitelist instead or some
> combination? E.g. you could whiteliste either by signer or
> enclave signature.
>
I'm not sure, and also don't really think we need to commit to an
answer right now. I do think that the eventual solution should be
more flexible than just whitelisting the signers. In particular, it
should be possible to make secure enclaves, open-source or otherwise,
that are reproducibly buildable. This more or less requires that the
signing private key not be a secret, which means that no one would
want to whitelist the signing key. The enclave would be trusted, and
would seal data, on the basis of its MRENCLAVE, and the policy, if
any, would want to whitelist the MRENCLAVE or perhaps the whole
SIGSTRUCT.
But my overall point is that it should be possible to have a conherent
policy that allows any enclave whatsoever to run but that still
respects EXECMEM and such.
^ permalink raw reply
* Re: [PATCH v2 bpf-next 1/4] bpf: unprivileged BPF access via /dev/bpf
From: Andy Lutomirski @ 2019-08-04 22:16 UTC (permalink / raw)
To: Song Liu
Cc: Andy Lutomirski, Kees Cook, Networking, bpf, Alexei Starovoitov,
Daniel Borkmann, Kernel Team, Lorenz Bauer, Jann Horn, Greg KH,
Linux API, LSM List
In-Reply-To: <5A2FCD7E-7F54-41E5-BFAE-BB9494E74F2D@fb.com>
On Fri, Aug 2, 2019 at 12:22 AM Song Liu <songliubraving@fb.com> wrote:
>
> Hi Andy,
>
>> I actually agree CAP_BPF_ADMIN makes sense. The hard part is to make
> >> existing tools (setcap, getcap, etc.) and libraries aware of the new CAP.
> >
> > It's been done before -- it's not that hard. IMO the main tricky bit
> > would be try be somewhat careful about defining exactly what
> > CAP_BPF_ADMIN does.
>
> Agreed. I think defining CAP_BPF_ADMIN could be a good topic for the
> Plumbers conference.
>
> OTOH, I don't think we have to wait for CAP_BPF_ADMIN to allow daemons
> like systemd to do sys_bpf() without root.
I don't understand the use case here. Are you talking about systemd
--user? As far as I know, a user is expected to be able to fully
control their systemd --user process, so giving it unrestricted bpf
access is very close to giving it superuser access, and this doesn't
sound like a good idea. I think that, if systemd --user needs bpf(),
it either needs real unprivileged bpf() or it needs a privileged
helper (SUID or a daemon) to intermediate this access.
>
> >
> >>> I don't see why you need to invent a whole new mechanism for this.
> >>> The entire cgroup ecosystem outside bpf() does just fine using the
> >>> write permission on files in cgroupfs to control access. Why can't
> >>> bpf() do the same thing?
> >>
> >> It is easier to use write permission for BPF_PROG_ATTACH. But it is
> >> not easy to do the same for other bpf commands: BPF_PROG_LOAD and
> >> BPF_MAP_*. A lot of these commands don't have target concept. Maybe
> >> we should have target concept for all these commands. But that is a
> >> much bigger project. OTOH, "all or nothing" model allows all these
> >> commands at once.
> >
> > For BPF_PROG_LOAD, I admit I've never understood why permission is
> > required at all. I think that CAP_SYS_ADMIN or similar should be
> > needed to get is_priv in the verifier, but I think that should mainly
> > be useful for tracing, and that requires lots of privilege anyway.
> > BPF_MAP_* is probably the trickiest part. One solution would be some
> > kind of bpffs, but I'm sure other solutions are possible.
>
> Improving permission management of cgroup_bpf is another good topic to
> discuss. However, it is also an overkill for current use case.
>
I looked at the code some more, and I don't think this is so hard
after all. As I understand it, all of the map..by_id stuff is, to
some extent, deprecated in favor of persistent maps. As I see it, the
map..by_id calls should require privilege forever, although I can
imagine ways to scope that privilege to a namespace if the maps
themselves were to be scoped to a namespace.
Instead, unprivileged tools would use the persistent map interface
roughly like this:
$ bpftool map create /sys/fs/bpf/my_dir/filename type hash key 8 value
8 entries 64 name mapname
This would require that the caller have either CAP_DAC_OVERRIDE or
that the caller have permission to create files in /sys/fs/bpf/my_dir
(using the same rules as for any filesystem), and the resulting map
would end up owned by the creating user and have mode 0600 (or maybe
0666, or maybe a new bpf_attr parameter) modified by umask. Then all
the various capable() checks that are currently involved in accessing
a persistent map would instead check FMODE_READ or FMODE_WRITE on the
map file as appropriate.
Half of this stuff already works. I just set my system up like this:
$ ls -l /sys/fs/bpf
total 0
drwxr-xr-x. 3 luto luto 0 Aug 4 15:10 luto
$ mkdir /sys/fs/bpf/luto/test
$ ls -l /sys/fs/bpf/luto
total 0
drwxrwxr-x. 2 luto luto 0 Aug 4 15:10 test
I bet that making the bpf() syscalls work appropriately in this
context without privilege would only be a couple of hours of work.
The hard work, creating bpffs and making it function, is already done
:)
P.S. The docs for bpftool create are less than fantastic. The
complete lack of any error message at all when the syscall returns
-EACCES is also not fantastic.
^ permalink raw reply
* Re: [RFC v2 0/6] Introduce TEE based Trusted Keys support
From: Jarkko Sakkinen @ 2019-08-04 20:48 UTC (permalink / raw)
To: Sumit Garg
Cc: keyrings, linux-integrity, linux-security-module, jens.wiklander,
corbet, dhowells, jejb, zohar, jmorris, serge, casey,
ard.biesheuvel, daniel.thompson, linux-doc, linux-kernel,
linux-arm-kernel, tee-dev
In-Reply-To: <1564489420-677-1-git-send-email-sumit.garg@linaro.org>
On Tue, Jul 30, 2019 at 05:53:34PM +0530, Sumit Garg wrote:
> tee: optee: allow kernel pages to register as shm
> tee: enable support to register kernel memory
> tee: add private login method for kernel clients
> KEYS: trusted: Introduce TEE based Trusted Keys
> doc: keys: Document usage of TEE based Trusted Keys
> MAINTAINERS: Add entry for TEE based Trusted Keys
Skimmed through the patches. I think it is better to sort out the
current LKM dependency issue with trusted.ko and get TPM 1.2 and TPM 2.0
trusted keys code consolidated before it makes sense to really go detail
on this.
/Jarkko
^ permalink raw reply
* Re: [GIT PULL] SafeSetID MAINTAINERS file update for v5.3
From: Linus Torvalds @ 2019-08-04 17:47 UTC (permalink / raw)
To: Micah Morton, Konstantin Ryabitsev
Cc: linux-security-module, Linux Kernel Mailing List
In-Reply-To: <CAJ-EccOqmmrf2KPb7Z7NU6bF_4W1XUawLLy=pLekCyFKqusjKQ@mail.gmail.com>
On Thu, Aug 1, 2019 at 11:11 AM Micah Morton <mortonm@chromium.org> wrote:
>
> The following changes since commit 609488bc979f99f805f34e9a32c1e3b71179d10b:
>
> Linux 5.3-rc2 (2019-07-28 12:47:02 -0700)
>
> are available in the Git repository at:
>
> https://github.com/micah-morton/linux.git
> tags/safesetid-maintainers-correction-5.3-rc2
Hmm.
This pull request was apparently not caught by pr-tracker-bot for some
reason, so it didn't get the automated "this has been pulled" message.
I'm not entirely sure why - it was cc'd to lkml, and I see it on lore as
https://lore.kernel.org/lkml/CAJ-EccOqmmrf2KPb7Z7NU6bF_4W1XUawLLy=pLekCyFKqusjKQ@mail.gmail.com/
so the email itself made it through the system. And it has "GIT PULL"
in the subject line, so the pr-tracker-bot should have looked at it.
I see a couple of _potential_ reasons why it might have been overlooked:
- maybe the "--" marker after your explanation made pr-tracker-bot go
"oh, the rest is just a signature"
- the fact that the git link looks more like a regular web thing, and
the branch name is on another line. Does pr-tracker-bot only trigger
on kernel.org things?
- maybe pr-tracker-bot ignores follow-up emails with "Re:" in the subject?
but it could be something else too.
Adding Konstantin to the participants, since he knows the magic.
This is not a big deal, and I have probably missed a lot of other
cases where the pr-tracker-bot doesn't react to pull requests, but I
really like how it gives a heads-up to people about their pulls
without me having to do anything extra, so I generally try to look for
failures when I can.
Konstantin?
Linus
^ permalink raw reply
* Re: [GIT PULL] SafeSetID MAINTAINERS file update for v5.3
From: Linus Torvalds @ 2019-08-04 17:07 UTC (permalink / raw)
To: Micah Morton; +Cc: linux-security-module, Linux Kernel Mailing List
In-Reply-To: <CAJ-EccOqmmrf2KPb7Z7NU6bF_4W1XUawLLy=pLekCyFKqusjKQ@mail.gmail.com>
On Thu, Aug 1, 2019 at 11:11 AM Micah Morton <mortonm@chromium.org> wrote:
>
> Add entry in MAINTAINERS file for SafeSetID LSM.
So I've pulled this now.
However, I have to say that I'm now very nervous about future pulls,
simply because the last one had basically everything that can be wrong
be wrong.
Random rebasing of existing commits, a random merge with no sane merge
message.. All complete no-no's.
So I will have to remember to be careful when pulling from you, and
you need to get into a habit of not doing those things.
One very powerful git tool is "gitk". It's just a good idea to use it
to *visualize* to yourself what it is you actually have. Do something
like
git fetch linus (or "upstream" or "origin" or whatever your
remote branch for my tree is called)
gitk linus/master..
which should show you very clearly what you have that is not in my
tree, and should show any odd merges etc.
Just doing "git diff" doesn't show garbage _history_, it only shows
the differences between the two states. There can be crazy bad history
that doesn't show up in the diff, exactly because you had duplicate
commits or something like that.
Linus
^ permalink raw reply
* Re: [PATCH] KEYS: trusted: allow module init if TPM is inactive or deactivated
From: Mimi Zohar @ 2019-08-04 1:46 UTC (permalink / raw)
To: Jarkko Sakkinen, Tyler Hicks
Cc: Roberto Sassu, jejb, jgg, linux-integrity, linux-security-module,
keyrings, linux-kernel, crazyt2019+lml, nayna, silviu.vlasceanu
In-Reply-To: <aff3502c598fb76a1517795edaacd8c8ea330051.camel@linux.intel.com>
On Sat, 2019-08-03 at 17:44 +0300, Jarkko Sakkinen wrote:
> On Fri, 2019-08-02 at 15:23 -0500, Tyler Hicks wrote:
> > That wasn't the conclusion that I came to. I prefer Robert's proposed
> > change to trusted.ko.
> >
> > How do you propose that this be fixed in eCryptfs?
> >
> > Removing encrypted_key support from eCryptfs is the only way that I can
> > see to fix the bug in eCryptfs. That support has been there since 2011.
> > I'm not sure of the number of users that would be broken by removing
> > encrypted_key support. I don't think the number is high but I can't say
> > that confidently.
>
> Looking at the documentation [1] it is stated that
>
> "Encrypted keys do not depend on a TPM, and are faster, as they use AES
> for encryption/decryption."
>
> Why would you need to remove support for encrypted keys? Isn't it a
> regression in encrypted keys to hard depend on trusted keys given
> what the documentation says?
"Encrypted" key are symmetric keys, which are encrypted/decrypted
either by a "trusted" key or, for development purposes only, a "user"
key.
Mimi
^ permalink raw reply
* Re: [GIT PULL] SELinux fixes for v5.3 (#2)
From: pr-tracker-bot @ 2019-08-03 17:45 UTC (permalink / raw)
To: Paul Moore; +Cc: Linus Torvalds, selinux, linux-security-module, linux-kernel
In-Reply-To: <CAHC9VhQ6X==anxZ435QAdbjiWtGiVA3LQbBbp0vhbzOhW6NvCQ@mail.gmail.com>
The pull request you sent on Thu, 1 Aug 2019 19:01:52 -0400:
> git://git.kernel.org/pub/scm/linux/kernel/git/pcmoore/selinux.git tags/selinux-pr-20190801
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/4f1a6ef1df6f952fc9f22f34d51a6c3d3c4fbe23
Thank you!
--
Deet-doot-dot, I am a bot.
https://korg.wiki.kernel.org/userdoc/prtracker
^ permalink raw reply
* Re: [PATCH] KEYS: trusted: allow module init if TPM is inactive or deactivated
From: Jarkko Sakkinen @ 2019-08-03 14:44 UTC (permalink / raw)
To: Tyler Hicks
Cc: Roberto Sassu, jejb, zohar, jgg, linux-integrity,
linux-security-module, keyrings, linux-kernel, crazyt2019+lml,
nayna, silviu.vlasceanu
In-Reply-To: <20190802202343.GE26616@elm>
On Fri, 2019-08-02 at 15:23 -0500, Tyler Hicks wrote:
> That wasn't the conclusion that I came to. I prefer Robert's proposed
> change to trusted.ko.
>
> How do you propose that this be fixed in eCryptfs?
>
> Removing encrypted_key support from eCryptfs is the only way that I can
> see to fix the bug in eCryptfs. That support has been there since 2011.
> I'm not sure of the number of users that would be broken by removing
> encrypted_key support. I don't think the number is high but I can't say
> that confidently.
Looking at the documentation [1] it is stated that
"Encrypted keys do not depend on a TPM, and are faster, as they use AES
for encryption/decryption."
Why would you need to remove support for encrypted keys? Isn't it a
regression in encrypted keys to hard depend on trusted keys given
what the documentation says?
> Roberto, what was your use case when you added encrypted_key support to
> eCryptfs back then? Are you aware of any users of eCryptfs +
> encrypted_keys?
>
> Jarkko, removing a long-standing feature is potentially more disruptive
> to users than adding a workaround to trusted.ko which already requires a
> similar workaround. I don't think that I agree with you on the proper
> fix here.
There is nothing to disagree or agree. I just try to get the picture
since ecryptfs is relatively alien to me.
[1] https://www.kernel.org/doc/html/v4.13/security/keys/trusted-encrypted.html
/Jarkko
^ permalink raw reply
* Re: [PATCH] KEYS: trusted: allow module init if TPM is inactive or deactivated
From: Tyler Hicks @ 2019-08-02 21:18 UTC (permalink / raw)
To: Mimi Zohar, Roberto Sassu
Cc: Jarkko Sakkinen, James Bottomley, jgg, linux-integrity,
linux-security-module, keyrings, linux-kernel, crazyt2019+lml,
nayna, silviu.vlasceanu
In-Reply-To: <1562689905.28089.52.camel@linux.ibm.com>
On 2019-07-09 12:31:45, Mimi Zohar wrote:
> On Tue, 2019-07-09 at 19:24 +0300, Jarkko Sakkinen wrote:
> > On Mon, Jul 08, 2019 at 01:34:59PM -0700, James Bottomley wrote:
> > > Not a criticism of your patch, but can we please stop doing this.
> > > Single random number sources are horrendously bad practice because it
> > > gives an attacker a single target to subvert. We should ensure the TPM
> > > is plugged into the kernel RNG as a source and then take randomness
> > > from the mixed pool so it's harder for an attacker because they have to
> > > subvert all our sources to predict what came out.
> >
> > It is and I agree.
>
> I still haven't quite figured out why the digests need to be
> initialized to anything other than 0.
After looking into 0b6cf6b97b7ef1fa3c7fefab0cac897a1c4a3400, I have to
agree. I don't see the purpose of using tpm_get_random() in
init_digests().
Roberto, why can't we just initialize the digests with zeroes? It would
fix the bug for eCryptfs and NVDIMM and address the concern that James
had regarding the single random number source.
Tyler
^ permalink raw reply
* Re: [PATCH] KEYS: trusted: allow module init if TPM is inactive or deactivated
From: Tyler Hicks @ 2019-08-02 20:35 UTC (permalink / raw)
To: Jarkko Sakkinen
Cc: Roberto Sassu, jejb, zohar, jgg, linux-integrity,
linux-security-module, keyrings, linux-kernel, crazyt2019+lml,
nayna, silviu.vlasceanu
In-Reply-To: <20190802202343.GE26616@elm>
On 2019-08-02 15:23:43, Tyler Hicks wrote:
> On 2019-08-02 22:42:26, Jarkko Sakkinen wrote:
> > On Fri, Aug 02, 2019 at 09:27:22AM -0500, Tyler Hicks wrote:
> > > On 2019-08-02 10:21:16, Roberto Sassu wrote:
> > > > On 8/1/2019 6:32 PM, Jarkko Sakkinen wrote:
> > > > > On Mon, Jul 15, 2019 at 06:44:28PM +0200, Roberto Sassu wrote:
> > > > > > According to the bug report at https://bugs.archlinux.org/task/62678,
> > > > > > the trusted module is a dependency of the ecryptfs module. We should
> > > > > > load the trusted module even if the TPM is inactive or deactivated.
> > > > > >
> > > > > > Given that commit 782779b60faa ("tpm: Actually fail on TPM errors during
> > > > > > "get random"") changes the return code of tpm_get_random(), the patch
> > > > > > should be modified to ignore the -EIO error. I will send a new version.
> > > > >
> > > > > Do you have information where this dependency comes from?
> > > >
> > > > ecryptfs retrieves the encryption key from encrypted keys (see
> > > > ecryptfs_get_encrypted_key()).
> > >
> > > That has been there for many years with any problems. It was added
> > > in 2011:
> > >
> > > commit 1252cc3b232e582e887623dc5f70979418caaaa2
> > > Author: Roberto Sassu <roberto.sassu@polito.it>
> > > Date: Mon Jun 27 13:45:45 2011 +0200
> > >
> > > eCryptfs: added support for the encrypted key type
> > >
> > > What's recently changed the situation is this patch:
> > >
> > > commit 240730437deb213a58915830884e1a99045624dc
> > > Author: Roberto Sassu <roberto.sassu@huawei.com>
> > > Date: Wed Feb 6 17:24:51 2019 +0100
> > >
> > > KEYS: trusted: explicitly use tpm_chip structure from tpm_default_chip()
> > >
> > > Now eCryptfs has a hard dependency on a TPM chip that's working
> > > as expected even if eCryptfs (or the rest of the system) isn't utilizing
> > > the TPM. If the TPM behaves unexpectedly, you can't access your files.
> > > We need to get this straightened out soon.
> >
> > I agree with this conclusion that eCryptfs needs to be fixed, not
> > another workaround to trusted.ko.
>
> That wasn't the conclusion that I came to. I prefer Robert's proposed
> change to trusted.ko.
>
> How do you propose that this be fixed in eCryptfs?
>
> Removing encrypted_key support from eCryptfs is the only way that I can
> see to fix the bug in eCryptfs. That support has been there since 2011.
> I'm not sure of the number of users that would be broken by removing
> encrypted_key support. I don't think the number is high but I can't say
> that confidently.
AFAICT, this bug doesn't only affect eCryptfs. It also affects Intel
nvdimm support starting with:
commit 4c6926a23b76ea23403976290cd45a7a143f6500
Author: Dave Jiang <dave.jiang@intel.com>
Date: Thu Dec 6 12:40:01 2018 -0800
acpi/nfit, libnvdimm: Add unlock of nvdimm support for Intel DIMMs
So without a workaround in trusted.ko, encrypted_key support will need
to be removed from eCryptfs and nvdimm to address this issue.
Tyler
>
> Roberto, what was your use case when you added encrypted_key support to
> eCryptfs back then? Are you aware of any users of eCryptfs +
> encrypted_keys?
>
> Jarkko, removing a long-standing feature is potentially more disruptive
> to users than adding a workaround to trusted.ko which already requires a
> similar workaround. I don't think that I agree with you on the proper
> fix here.
>
> Tyler
>
> >
> > /Jarkko
^ permalink raw reply
* Re: [PATCH] KEYS: trusted: allow module init if TPM is inactive or deactivated
From: Tyler Hicks @ 2019-08-02 20:23 UTC (permalink / raw)
To: Jarkko Sakkinen
Cc: Roberto Sassu, jejb, zohar, jgg, linux-integrity,
linux-security-module, keyrings, linux-kernel, crazyt2019+lml,
nayna, silviu.vlasceanu
In-Reply-To: <20190802194226.oiztvme5klkmw6fh@linux.intel.com>
On 2019-08-02 22:42:26, Jarkko Sakkinen wrote:
> On Fri, Aug 02, 2019 at 09:27:22AM -0500, Tyler Hicks wrote:
> > On 2019-08-02 10:21:16, Roberto Sassu wrote:
> > > On 8/1/2019 6:32 PM, Jarkko Sakkinen wrote:
> > > > On Mon, Jul 15, 2019 at 06:44:28PM +0200, Roberto Sassu wrote:
> > > > > According to the bug report at https://bugs.archlinux.org/task/62678,
> > > > > the trusted module is a dependency of the ecryptfs module. We should
> > > > > load the trusted module even if the TPM is inactive or deactivated.
> > > > >
> > > > > Given that commit 782779b60faa ("tpm: Actually fail on TPM errors during
> > > > > "get random"") changes the return code of tpm_get_random(), the patch
> > > > > should be modified to ignore the -EIO error. I will send a new version.
> > > >
> > > > Do you have information where this dependency comes from?
> > >
> > > ecryptfs retrieves the encryption key from encrypted keys (see
> > > ecryptfs_get_encrypted_key()).
> >
> > That has been there for many years with any problems. It was added
> > in 2011:
> >
> > commit 1252cc3b232e582e887623dc5f70979418caaaa2
> > Author: Roberto Sassu <roberto.sassu@polito.it>
> > Date: Mon Jun 27 13:45:45 2011 +0200
> >
> > eCryptfs: added support for the encrypted key type
> >
> > What's recently changed the situation is this patch:
> >
> > commit 240730437deb213a58915830884e1a99045624dc
> > Author: Roberto Sassu <roberto.sassu@huawei.com>
> > Date: Wed Feb 6 17:24:51 2019 +0100
> >
> > KEYS: trusted: explicitly use tpm_chip structure from tpm_default_chip()
> >
> > Now eCryptfs has a hard dependency on a TPM chip that's working
> > as expected even if eCryptfs (or the rest of the system) isn't utilizing
> > the TPM. If the TPM behaves unexpectedly, you can't access your files.
> > We need to get this straightened out soon.
>
> I agree with this conclusion that eCryptfs needs to be fixed, not
> another workaround to trusted.ko.
That wasn't the conclusion that I came to. I prefer Robert's proposed
change to trusted.ko.
How do you propose that this be fixed in eCryptfs?
Removing encrypted_key support from eCryptfs is the only way that I can
see to fix the bug in eCryptfs. That support has been there since 2011.
I'm not sure of the number of users that would be broken by removing
encrypted_key support. I don't think the number is high but I can't say
that confidently.
Roberto, what was your use case when you added encrypted_key support to
eCryptfs back then? Are you aware of any users of eCryptfs +
encrypted_keys?
Jarkko, removing a long-standing feature is potentially more disruptive
to users than adding a workaround to trusted.ko which already requires a
similar workaround. I don't think that I agree with you on the proper
fix here.
Tyler
>
> /Jarkko
^ permalink raw reply
* Re: [PATCH] KEYS: trusted: allow module init if TPM is inactive or deactivated
From: Jarkko Sakkinen @ 2019-08-02 19:42 UTC (permalink / raw)
To: Tyler Hicks
Cc: Roberto Sassu, jejb, zohar, jgg, linux-integrity,
linux-security-module, keyrings, linux-kernel, crazyt2019+lml,
nayna, silviu.vlasceanu
In-Reply-To: <20190802142721.GA26616@elm>
On Fri, Aug 02, 2019 at 09:27:22AM -0500, Tyler Hicks wrote:
> On 2019-08-02 10:21:16, Roberto Sassu wrote:
> > On 8/1/2019 6:32 PM, Jarkko Sakkinen wrote:
> > > On Mon, Jul 15, 2019 at 06:44:28PM +0200, Roberto Sassu wrote:
> > > > According to the bug report at https://bugs.archlinux.org/task/62678,
> > > > the trusted module is a dependency of the ecryptfs module. We should
> > > > load the trusted module even if the TPM is inactive or deactivated.
> > > >
> > > > Given that commit 782779b60faa ("tpm: Actually fail on TPM errors during
> > > > "get random"") changes the return code of tpm_get_random(), the patch
> > > > should be modified to ignore the -EIO error. I will send a new version.
> > >
> > > Do you have information where this dependency comes from?
> >
> > ecryptfs retrieves the encryption key from encrypted keys (see
> > ecryptfs_get_encrypted_key()).
>
> That has been there for many years with any problems. It was added
> in 2011:
>
> commit 1252cc3b232e582e887623dc5f70979418caaaa2
> Author: Roberto Sassu <roberto.sassu@polito.it>
> Date: Mon Jun 27 13:45:45 2011 +0200
>
> eCryptfs: added support for the encrypted key type
>
> What's recently changed the situation is this patch:
>
> commit 240730437deb213a58915830884e1a99045624dc
> Author: Roberto Sassu <roberto.sassu@huawei.com>
> Date: Wed Feb 6 17:24:51 2019 +0100
>
> KEYS: trusted: explicitly use tpm_chip structure from tpm_default_chip()
>
> Now eCryptfs has a hard dependency on a TPM chip that's working
> as expected even if eCryptfs (or the rest of the system) isn't utilizing
> the TPM. If the TPM behaves unexpectedly, you can't access your files.
> We need to get this straightened out soon.
I agree with this conclusion that eCryptfs needs to be fixed, not
another workaround to trusted.ko.
/Jarkko
^ permalink raw reply
* Re: [PATCH] KEYS: trusted: allow module init if TPM is inactive or deactivated
From: Jarkko Sakkinen @ 2019-08-02 19:40 UTC (permalink / raw)
To: Roberto Sassu
Cc: jejb, zohar, jgg, linux-integrity, linux-security-module,
keyrings, linux-kernel, crazyt2019+lml, tyhicks, nayna,
silviu.vlasceanu
In-Reply-To: <e50c4cfa-1f0c-6f4d-1910-010a8d874393@huawei.com>
On Fri, Aug 02, 2019 at 10:21:16AM +0200, Roberto Sassu wrote:
> On 8/1/2019 6:32 PM, Jarkko Sakkinen wrote:
> > On Mon, Jul 15, 2019 at 06:44:28PM +0200, Roberto Sassu wrote:
> > > According to the bug report at https://bugs.archlinux.org/task/62678,
> > > the trusted module is a dependency of the ecryptfs module. We should
> > > load the trusted module even if the TPM is inactive or deactivated.
> > >
> > > Given that commit 782779b60faa ("tpm: Actually fail on TPM errors during
> > > "get random"") changes the return code of tpm_get_random(), the patch
> > > should be modified to ignore the -EIO error. I will send a new version.
> >
> > Do you have information where this dependency comes from?
>
> ecryptfs retrieves the encryption key from encrypted keys (see
> ecryptfs_get_encrypted_key()).
So... what is preventing removing this requirement "in the source"?
/Jarkko
^ permalink raw reply
* Re: [RFC/RFT v2 1/2] KEYS: trusted: create trusted keys subsystem
From: Jarkko Sakkinen @ 2019-08-02 19:38 UTC (permalink / raw)
To: Sumit Garg
Cc: keyrings, linux-integrity,
open list:HARDWARE RANDOM NUMBER GENERATOR CORE,
linux-security-module, dhowells, Herbert Xu, davem, jejb,
Mimi Zohar, James Morris, Serge E. Hallyn, Casey Schaufler,
Ard Biesheuvel, Daniel Thompson, Linux Kernel Mailing List,
tee-dev @ lists . linaro . org
In-Reply-To: <CAFA6WYM+FQuXA9Saj5+ffOGsc-shhiF5Uos4g14Qndvu6w97Sg@mail.gmail.com>
On Fri, Aug 02, 2019 at 11:20:09AM +0530, Sumit Garg wrote:
> On Thu, 1 Aug 2019 at 22:54, Jarkko Sakkinen
> <jarkko.sakkinen@linux.intel.com> wrote:
> >
> > On Thu, Jul 18, 2019 at 04:54:45PM +0530, Sumit Garg wrote:
> > > Move existing code to trusted keys subsystem. Also, rename files with
> > > "tpm" as suffix which provides the underlying implementation.
> > >
> > > Suggested-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
> > > Signed-off-by: Sumit Garg <sumit.garg@linaro.org>
> >
> > What about TPM2 trusted keys code?
>
> Isn't TPM2 code located here: "drivers/char/tpm/"? Would you like to
> move that code under trusted keys subsystem only?
Yeah, we need a design decision here. What I care is that they should
be in the same subsystem. I did trusted keys directly to TPM 2.0 subsys
because the subsystem was not too robust back then.
Right now I think it would be feasible to implement TPM2 trusted keys
outside TPM driver since the whole transmit functionality is way more
robust.
/Jarkko
^ permalink raw reply
* Re: [PATCH v2] KEYS: trusted: allow module init if TPM is inactive or deactivated
From: Tyler Hicks @ 2019-08-02 16:15 UTC (permalink / raw)
To: Roberto Sassu
Cc: jarkko.sakkinen, jejb, zohar, jgg, linux-integrity,
linux-security-module, keyrings, linux-kernel, crazyt2019+lml,
nayna, silviu.vlasceanu
In-Reply-To: <8baf1c39-ad04-5cd6-bc67-341e7411db16@huawei.com>
On 2019-08-02 18:11:09, Roberto Sassu wrote:
> On 8/2/2019 5:34 PM, Roberto Sassu wrote:
> > On 8/2/2019 5:30 PM, Tyler Hicks wrote:
> > > On 2019-08-02 17:07:33, Roberto Sassu wrote:
> > > > Commit c78719203fc6 ("KEYS: trusted: allow trusted.ko to
> > > > initialize w/o a
> > > > TPM") allows the trusted module to be loaded even a TPM is not found to
> > > ^ if
> > >
> > > > avoid module dependency problems.
> > > >
> > > > However, trusted module initialization can still fail if the TPM is
> > > > inactive or deactivated. This patch ignores tpm_get_random() errors in
> > > > init_digests() and returns -EFAULT in pcrlock() if the TPM didn't return
> > > > random data.
> > > >
> > > > Signed-off-by: Roberto Sassu <roberto.sassu@huawei.com>
> > >
> > > The code changes look correct to me.
> > >
> > > Reviewed-by: Tyler Hicks <tyhicks@canonical.com>
> > >
> > > For whoever takes this patch through their tree, I think that adding the
> > > following Fixes tag would be useful (as well as cc'ing stable):
> > >
> > > Fixes: 240730437deb ("KEYS: trusted: explicitly use tpm_chip
> > > structure...")
> > >
> > > I think it is also worth leaving a short note, in the commit message,
> > > for backporters that commit 782779b60faa ("tpm: Actually fail on TPM
> > > errors during "get random"") should be included with any backports of
> > > this patch.
> >
> > Right, thanks. I wait for Jarkko's comments and I add both the Fixes tag
> > and the short note in the next version of the patch.
>
> Uhm, I was thinking that maybe it is not necessary to mention commit
> 782779b60faa. This patch would still return 0 even if that commit is not
> backported (TPM_ERR_DISABLED < TPM_MAX_DIGEST_SIZE).
The commit message for 782779b60faa shows 379 being returned when
attempting to get random:
[ 18.092103] tpm tpm0: A TPM error (379) occurred attempting get random
I don't know enough about TPM chips to know how common that is...
Tyler
>
> Roberto
>
> --
> HUAWEI TECHNOLOGIES Duesseldorf GmbH, HRB 56063
> Managing Director: Li Peng, Li Jian, Shi Yanli
^ permalink raw reply
* Re: [PATCH v2] KEYS: trusted: allow module init if TPM is inactive or deactivated
From: Roberto Sassu @ 2019-08-02 16:11 UTC (permalink / raw)
To: Tyler Hicks
Cc: jarkko.sakkinen, jejb, zohar, jgg, linux-integrity,
linux-security-module, keyrings, linux-kernel, crazyt2019+lml,
nayna, silviu.vlasceanu
In-Reply-To: <3222714a-a280-0708-f4c0-5db6d342d8dc@huawei.com>
On 8/2/2019 5:34 PM, Roberto Sassu wrote:
> On 8/2/2019 5:30 PM, Tyler Hicks wrote:
>> On 2019-08-02 17:07:33, Roberto Sassu wrote:
>>> Commit c78719203fc6 ("KEYS: trusted: allow trusted.ko to initialize
>>> w/o a
>>> TPM") allows the trusted module to be loaded even a TPM is not found to
>> ^ if
>>
>>> avoid module dependency problems.
>>>
>>> However, trusted module initialization can still fail if the TPM is
>>> inactive or deactivated. This patch ignores tpm_get_random() errors in
>>> init_digests() and returns -EFAULT in pcrlock() if the TPM didn't return
>>> random data.
>>>
>>> Signed-off-by: Roberto Sassu <roberto.sassu@huawei.com>
>>
>> The code changes look correct to me.
>>
>> Reviewed-by: Tyler Hicks <tyhicks@canonical.com>
>>
>> For whoever takes this patch through their tree, I think that adding the
>> following Fixes tag would be useful (as well as cc'ing stable):
>>
>> Fixes: 240730437deb ("KEYS: trusted: explicitly use tpm_chip
>> structure...")
>>
>> I think it is also worth leaving a short note, in the commit message,
>> for backporters that commit 782779b60faa ("tpm: Actually fail on TPM
>> errors during "get random"") should be included with any backports of
>> this patch.
>
> Right, thanks. I wait for Jarkko's comments and I add both the Fixes tag
> and the short note in the next version of the patch.
Uhm, I was thinking that maybe it is not necessary to mention commit
782779b60faa. This patch would still return 0 even if that commit is not
backported (TPM_ERR_DISABLED < TPM_MAX_DIGEST_SIZE).
Roberto
--
HUAWEI TECHNOLOGIES Duesseldorf GmbH, HRB 56063
Managing Director: Li Peng, Li Jian, Shi Yanli
^ permalink raw reply
* Re: [PATCH v2] KEYS: trusted: allow module init if TPM is inactive or deactivated
From: Roberto Sassu @ 2019-08-02 15:34 UTC (permalink / raw)
To: Tyler Hicks
Cc: jarkko.sakkinen, jejb, zohar, jgg, linux-integrity,
linux-security-module, keyrings, linux-kernel, crazyt2019+lml,
nayna, silviu.vlasceanu
In-Reply-To: <20190802153030.GB26616@elm>
On 8/2/2019 5:30 PM, Tyler Hicks wrote:
> On 2019-08-02 17:07:33, Roberto Sassu wrote:
>> Commit c78719203fc6 ("KEYS: trusted: allow trusted.ko to initialize w/o a
>> TPM") allows the trusted module to be loaded even a TPM is not found to
> ^ if
>
>> avoid module dependency problems.
>>
>> However, trusted module initialization can still fail if the TPM is
>> inactive or deactivated. This patch ignores tpm_get_random() errors in
>> init_digests() and returns -EFAULT in pcrlock() if the TPM didn't return
>> random data.
>>
>> Signed-off-by: Roberto Sassu <roberto.sassu@huawei.com>
>
> The code changes look correct to me.
>
> Reviewed-by: Tyler Hicks <tyhicks@canonical.com>
>
> For whoever takes this patch through their tree, I think that adding the
> following Fixes tag would be useful (as well as cc'ing stable):
>
> Fixes: 240730437deb ("KEYS: trusted: explicitly use tpm_chip structure...")
>
> I think it is also worth leaving a short note, in the commit message,
> for backporters that commit 782779b60faa ("tpm: Actually fail on TPM
> errors during "get random"") should be included with any backports of
> this patch.
Right, thanks. I wait for Jarkko's comments and I add both the Fixes tag
and the short note in the next version of the patch.
Roberto
--
HUAWEI TECHNOLOGIES Duesseldorf GmbH, HRB 56063
Managing Director: Li Peng, Li Jian, Shi Yanli
^ permalink raw reply
* Re: [PATCH v2] KEYS: trusted: allow module init if TPM is inactive or deactivated
From: Tyler Hicks @ 2019-08-02 15:30 UTC (permalink / raw)
To: Roberto Sassu
Cc: jarkko.sakkinen, jejb, zohar, jgg, linux-integrity,
linux-security-module, keyrings, linux-kernel, crazyt2019+lml,
nayna, silviu.vlasceanu
In-Reply-To: <20190802150733.1972-1-roberto.sassu@huawei.com>
On 2019-08-02 17:07:33, Roberto Sassu wrote:
> Commit c78719203fc6 ("KEYS: trusted: allow trusted.ko to initialize w/o a
> TPM") allows the trusted module to be loaded even a TPM is not found to
^ if
> avoid module dependency problems.
>
> However, trusted module initialization can still fail if the TPM is
> inactive or deactivated. This patch ignores tpm_get_random() errors in
> init_digests() and returns -EFAULT in pcrlock() if the TPM didn't return
> random data.
>
> Signed-off-by: Roberto Sassu <roberto.sassu@huawei.com>
The code changes look correct to me.
Reviewed-by: Tyler Hicks <tyhicks@canonical.com>
For whoever takes this patch through their tree, I think that adding the
following Fixes tag would be useful (as well as cc'ing stable):
Fixes: 240730437deb ("KEYS: trusted: explicitly use tpm_chip structure...")
I think it is also worth leaving a short note, in the commit message,
for backporters that commit 782779b60faa ("tpm: Actually fail on TPM
errors during "get random"") should be included with any backports of
this patch.
Thanks!
Tyler
> ---
> security/keys/trusted.c | 10 ++++++----
> 1 file changed, 6 insertions(+), 4 deletions(-)
>
> diff --git a/security/keys/trusted.c b/security/keys/trusted.c
> index 9a94672e7adc..34f04ffcf2e5 100644
> --- a/security/keys/trusted.c
> +++ b/security/keys/trusted.c
> @@ -389,6 +389,10 @@ static int pcrlock(const int pcrnum)
> if (!capable(CAP_SYS_ADMIN))
> return -EPERM;
>
> + /* This happens if the TPM didn't return random data */
> + if (!digests)
> + return -EFAULT;
> +
> return tpm_pcr_extend(chip, pcrnum, digests) ? -EINVAL : 0;
> }
>
> @@ -1233,10 +1237,8 @@ static int __init init_digests(void)
> int i;
>
> ret = tpm_get_random(chip, digest, TPM_MAX_DIGEST_SIZE);
> - if (ret < 0)
> - return ret;
> - if (ret < TPM_MAX_DIGEST_SIZE)
> - return -EFAULT;
> + if (ret < 0 || ret < TPM_MAX_DIGEST_SIZE)
> + return 0;
>
> digests = kcalloc(chip->nr_allocated_banks, sizeof(*digests),
> GFP_KERNEL);
> --
> 2.17.1
>
^ permalink raw reply
* Thank-You - Demmler Machinery
From: sales @ 2019-08-02 14:25 UTC (permalink / raw)
To: linux-security-module
Thank you for contacting Demmler Machinery. A representative will be in touch with you as soon as possible.
^ permalink raw reply
* [PATCH v2] KEYS: trusted: allow module init if TPM is inactive or deactivated
From: Roberto Sassu @ 2019-08-02 15:07 UTC (permalink / raw)
To: jarkko.sakkinen, jejb, zohar, jgg, tyhicks
Cc: linux-integrity, linux-security-module, keyrings, linux-kernel,
crazyt2019+lml, nayna, silviu.vlasceanu, Roberto Sassu
Commit c78719203fc6 ("KEYS: trusted: allow trusted.ko to initialize w/o a
TPM") allows the trusted module to be loaded even a TPM is not found to
avoid module dependency problems.
However, trusted module initialization can still fail if the TPM is
inactive or deactivated. This patch ignores tpm_get_random() errors in
init_digests() and returns -EFAULT in pcrlock() if the TPM didn't return
random data.
Signed-off-by: Roberto Sassu <roberto.sassu@huawei.com>
---
security/keys/trusted.c | 10 ++++++----
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/security/keys/trusted.c b/security/keys/trusted.c
index 9a94672e7adc..34f04ffcf2e5 100644
--- a/security/keys/trusted.c
+++ b/security/keys/trusted.c
@@ -389,6 +389,10 @@ static int pcrlock(const int pcrnum)
if (!capable(CAP_SYS_ADMIN))
return -EPERM;
+ /* This happens if the TPM didn't return random data */
+ if (!digests)
+ return -EFAULT;
+
return tpm_pcr_extend(chip, pcrnum, digests) ? -EINVAL : 0;
}
@@ -1233,10 +1237,8 @@ static int __init init_digests(void)
int i;
ret = tpm_get_random(chip, digest, TPM_MAX_DIGEST_SIZE);
- if (ret < 0)
- return ret;
- if (ret < TPM_MAX_DIGEST_SIZE)
- return -EFAULT;
+ if (ret < 0 || ret < TPM_MAX_DIGEST_SIZE)
+ return 0;
digests = kcalloc(chip->nr_allocated_banks, sizeof(*digests),
GFP_KERNEL);
--
2.17.1
^ permalink raw reply related
* Re: [PATCH] KEYS: trusted: allow module init if TPM is inactive or deactivated
From: Tyler Hicks @ 2019-08-02 14:27 UTC (permalink / raw)
To: Roberto Sassu, Jarkko Sakkinen
Cc: jejb, zohar, jgg, linux-integrity, linux-security-module,
keyrings, linux-kernel, crazyt2019+lml, nayna, silviu.vlasceanu
In-Reply-To: <e50c4cfa-1f0c-6f4d-1910-010a8d874393@huawei.com>
On 2019-08-02 10:21:16, Roberto Sassu wrote:
> On 8/1/2019 6:32 PM, Jarkko Sakkinen wrote:
> > On Mon, Jul 15, 2019 at 06:44:28PM +0200, Roberto Sassu wrote:
> > > According to the bug report at https://bugs.archlinux.org/task/62678,
> > > the trusted module is a dependency of the ecryptfs module. We should
> > > load the trusted module even if the TPM is inactive or deactivated.
> > >
> > > Given that commit 782779b60faa ("tpm: Actually fail on TPM errors during
> > > "get random"") changes the return code of tpm_get_random(), the patch
> > > should be modified to ignore the -EIO error. I will send a new version.
> >
> > Do you have information where this dependency comes from?
>
> ecryptfs retrieves the encryption key from encrypted keys (see
> ecryptfs_get_encrypted_key()).
That has been there for many years with any problems. It was added
in 2011:
commit 1252cc3b232e582e887623dc5f70979418caaaa2
Author: Roberto Sassu <roberto.sassu@polito.it>
Date: Mon Jun 27 13:45:45 2011 +0200
eCryptfs: added support for the encrypted key type
What's recently changed the situation is this patch:
commit 240730437deb213a58915830884e1a99045624dc
Author: Roberto Sassu <roberto.sassu@huawei.com>
Date: Wed Feb 6 17:24:51 2019 +0100
KEYS: trusted: explicitly use tpm_chip structure from tpm_default_chip()
Now eCryptfs has a hard dependency on a TPM chip that's working
as expected even if eCryptfs (or the rest of the system) isn't utilizing
the TPM. If the TPM behaves unexpectedly, you can't access your files.
We need to get this straightened out soon.
Tyler
>
> Roberto
>
> --
> HUAWEI TECHNOLOGIES Duesseldorf GmbH, HRB 56063
> Managing Director: Li Peng, Li Jian, Shi Yanli
^ permalink raw reply
* Re: [PATCH] KEYS: trusted: allow module init if TPM is inactive or deactivated
From: Roberto Sassu @ 2019-08-02 8:21 UTC (permalink / raw)
To: Jarkko Sakkinen
Cc: jejb, zohar, jgg, linux-integrity, linux-security-module,
keyrings, linux-kernel, crazyt2019+lml, tyhicks, nayna,
silviu.vlasceanu
In-Reply-To: <20190801163215.mfkagoafkxscesne@linux.intel.com>
On 8/1/2019 6:32 PM, Jarkko Sakkinen wrote:
> On Mon, Jul 15, 2019 at 06:44:28PM +0200, Roberto Sassu wrote:
>> According to the bug report at https://bugs.archlinux.org/task/62678,
>> the trusted module is a dependency of the ecryptfs module. We should
>> load the trusted module even if the TPM is inactive or deactivated.
>>
>> Given that commit 782779b60faa ("tpm: Actually fail on TPM errors during
>> "get random"") changes the return code of tpm_get_random(), the patch
>> should be modified to ignore the -EIO error. I will send a new version.
>
> Do you have information where this dependency comes from?
ecryptfs retrieves the encryption key from encrypted keys (see
ecryptfs_get_encrypted_key()).
Roberto
--
HUAWEI TECHNOLOGIES Duesseldorf GmbH, HRB 56063
Managing Director: Li Peng, Li Jian, Shi Yanli
^ permalink raw reply
* Re: [PATCH v2 bpf-next 1/4] bpf: unprivileged BPF access via /dev/bpf
From: Song Liu @ 2019-08-02 7:21 UTC (permalink / raw)
To: Andy Lutomirski
Cc: Kees Cook, Networking, bpf, Alexei Starovoitov, Daniel Borkmann,
Kernel Team, Lorenz Bauer, Jann Horn, Greg KH, Linux API,
LSM List
In-Reply-To: <CALCETrVoZL1YGUxx3kM-d21TWVRKdKw=f2B8aE5wc2zmX1cQ4g@mail.gmail.com>
Hi Andy,
> On Jul 31, 2019, at 12:09 PM, Andy Lutomirski <luto@kernel.org> wrote:
>
> On Wed, Jul 31, 2019 at 1:10 AM Song Liu <songliubraving@fb.com> wrote:
>>
>>
>>
>>> On Jul 30, 2019, at 1:24 PM, Andy Lutomirski <luto@kernel.org> wrote:
>>>
>>> On Mon, Jul 29, 2019 at 10:07 PM Song Liu <songliubraving@fb.com> wrote:
>>>>
>>>> Hi Andy,
>>>>
>>>>> On Jul 27, 2019, at 11:20 AM, Song Liu <songliubraving@fb.com> wrote:
>>>>>
>>>>> Hi Andy,
>>>>>
>>>>>
>>
>> [...]
>>
>>>>>
>>>>
>>>> I would like more comments on this.
>>>>
>>>> Currently, bpf permission is more or less "root or nothing", which we
>>>> would like to change.
>>>>
>>>> The short term goal is to separate bpf from root, in other words, it is
>>>> "all or nothing". Special user space utilities, such as systemd, would
>>>> benefit from this. Once this is implemented, systemd can call sys_bpf()
>>>> when it is not running as root.
>>>
>>> As generally nasty as Linux capabilities are, this sounds like a good
>>> use for CAP_BPF_ADMIN.
>>
>> I actually agree CAP_BPF_ADMIN makes sense. The hard part is to make
>> existing tools (setcap, getcap, etc.) and libraries aware of the new CAP.
>
> It's been done before -- it's not that hard. IMO the main tricky bit
> would be try be somewhat careful about defining exactly what
> CAP_BPF_ADMIN does.
Agreed. I think defining CAP_BPF_ADMIN could be a good topic for the
Plumbers conference.
OTOH, I don't think we have to wait for CAP_BPF_ADMIN to allow daemons
like systemd to do sys_bpf() without root.
>
>>> I don't see why you need to invent a whole new mechanism for this.
>>> The entire cgroup ecosystem outside bpf() does just fine using the
>>> write permission on files in cgroupfs to control access. Why can't
>>> bpf() do the same thing?
>>
>> It is easier to use write permission for BPF_PROG_ATTACH. But it is
>> not easy to do the same for other bpf commands: BPF_PROG_LOAD and
>> BPF_MAP_*. A lot of these commands don't have target concept. Maybe
>> we should have target concept for all these commands. But that is a
>> much bigger project. OTOH, "all or nothing" model allows all these
>> commands at once.
>
> For BPF_PROG_LOAD, I admit I've never understood why permission is
> required at all. I think that CAP_SYS_ADMIN or similar should be
> needed to get is_priv in the verifier, but I think that should mainly
> be useful for tracing, and that requires lots of privilege anyway.
> BPF_MAP_* is probably the trickiest part. One solution would be some
> kind of bpffs, but I'm sure other solutions are possible.
Improving permission management of cgroup_bpf is another good topic to
discuss. However, it is also an overkill for current use case.
Let me get more details about the use case, so that we have a clear
picture about short term and long term goals.
Thanks again for your suggestions.
Song
^ permalink raw reply
* Re: [RFC/RFT v2 1/2] KEYS: trusted: create trusted keys subsystem
From: Sumit Garg @ 2019-08-02 5:50 UTC (permalink / raw)
To: Jarkko Sakkinen
Cc: keyrings, linux-integrity,
open list:HARDWARE RANDOM NUMBER GENERATOR CORE,
linux-security-module, dhowells, Herbert Xu, davem, jejb,
Mimi Zohar, James Morris, Serge E. Hallyn, Casey Schaufler,
Ard Biesheuvel, Daniel Thompson, Linux Kernel Mailing List,
tee-dev @ lists . linaro . org
In-Reply-To: <20190801172310.cldcftfdoh5vyfjg@linux.intel.com>
On Thu, 1 Aug 2019 at 22:54, Jarkko Sakkinen
<jarkko.sakkinen@linux.intel.com> wrote:
>
> On Thu, Jul 18, 2019 at 04:54:45PM +0530, Sumit Garg wrote:
> > Move existing code to trusted keys subsystem. Also, rename files with
> > "tpm" as suffix which provides the underlying implementation.
> >
> > Suggested-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
> > Signed-off-by: Sumit Garg <sumit.garg@linaro.org>
>
> What about TPM2 trusted keys code?
Isn't TPM2 code located here: "drivers/char/tpm/"? Would you like to
move that code under trusted keys subsystem only?
-Sumit
>
> /Jarkko
^ permalink raw reply
* Re: [PATCH] ima: Allow to import the blacklisted cert signed by secondary CA cert
From: Jia Zhang @ 2019-08-02 1:42 UTC (permalink / raw)
To: Mimi Zohar, dhowells, dmitry.kasatkin
Cc: keyrings, linux-security-module, linux-integrity, linux-kernel,
Mark D. Baushke, Petko Manolov
In-Reply-To: <1564700229.11223.9.camel@linux.ibm.com>
On 2019/8/2 上午6:57, Mimi Zohar wrote:
> Hi Jia,
>
> On Thu, 2019-08-01 at 09:23 +0800, Jia Zhang wrote:
>> Similar to .ima, the cert imported to .ima_blacklist is able to be
>> authenticated by a secondary CA cert.
>>
>> Signed-off-by: Jia Zhang <zhang.jia@linux.alibaba.com>
>
> The IMA blacklist, which is defined as experimental for a reason, was
> upstreamed prior to the system blacklist. Any reason you're not using
> the system blacklist? Before making this sort of change, I'd like
> some input from others.
In our trusted cloud service, the IMA private key is controlled by
tenant for some reason. Some unprofessional operations made by tenant
may lead to the leakage of IMA private key. So the need for importing
the blacklisted is necessary，without system/kexec reboot, on the
contrary, the system blacklist needs a kernel rebuild and system/kexec
reboot, without runtime and fine-grained control.
The secondary CA cert has a similar story, but it is not controlled by
tenant. It is always imported during system/kexec boot to serve
importing IMA trusted cert and IMA blacklisted cert.
Jia
>
> thanks,
>
> Mimi
>
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox