Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1214239 > unrolled thread
| Started by | "Luis R. Rodriguez" <mcgrof@suse.com> |
|---|---|
| First post | 2015-08-27 01:30 +0200 |
| Last post | 2015-08-27 21:40 +0200 |
| Articles | 20 on this page of 42 — 11 participants |
Back to article view | Back to linux.kernel
This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by
below is the oldest one visible, not the original post.
Re: Linux Firmware Signing "Luis R. Rodriguez" <mcgrof@suse.com> - 2015-08-27 01:30 +0200
Re: Linux Firmware Signing Paul Moore <paul@paul-moore.com> - 2015-08-27 04:40 +0200
Re: Linux Firmware Signing "Luis R. Rodriguez" <mcgrof@suse.com> - 2015-08-27 21:40 +0200
Re: Linux Firmware Signing Paul Moore <paul@paul-moore.com> - 2015-08-28 01:50 +0200
Re: Linux Firmware Signing David Howells <dhowells@redhat.com> - 2015-08-27 12:40 +0200
Re: Linux Firmware Signing "David Woodhouse" <dwmw2@infradead.org> - 2015-08-27 14:10 +0200
Re: Linux Firmware Signing "Luis R. Rodriguez" <mcgrof@suse.com> - 2015-08-27 23:30 +0200
Re: Linux Firmware Signing Paul Moore <paul@paul-moore.com> - 2015-08-28 02:00 +0200
RE: Linux Firmware Signing "Roberts, William C" <william.c.roberts@intel.com> - 2015-08-28 13:30 +0200
Re: Linux Firmware Signing Paul Moore <paul@paul-moore.com> - 2015-08-29 00:30 +0200
Re: Linux Firmware Signing "Luis R. Rodriguez" <mcgrof@suse.com> - 2015-08-29 04:10 +0200
Re: Linux Firmware Signing Paul Moore <paul@paul-moore.com> - 2015-09-01 05:00 +0200
Re: Linux Firmware Signing Joshua Brindle <brindle@quarksecurity.com> - 2015-09-01 16:20 +0200
RE: Linux Firmware Signing "Roberts, William C" <william.c.roberts@intel.com> - 2015-09-01 22:10 +0200
Re: Linux Firmware Signing Joshua Brindle <brindle@quarksecurity.com> - 2015-09-01 22:50 +0200
Re: Linux Firmware Signing Eric Paris <eparis@redhat.com> - 2015-09-02 00:30 +0200
Re: Linux Firmware Signing "Luis R. Rodriguez" <mcgrof@suse.com> - 2015-08-29 04:00 +0200
Re: Linux Firmware Signing Mimi Zohar <zohar@linux.vnet.ibm.com> - 2015-08-28 02:00 +0200
Re: Linux Firmware Signing "Luis R. Rodriguez" <mcgrof@suse.com> - 2015-08-29 04:20 +0200
Re: Linux Firmware Signing Mimi Zohar <zohar@linux.vnet.ibm.com> - 2015-08-31 16:30 +0200
Re: Linux Firmware Signing David Woodhouse <dwmw2@infradead.org> - 2015-08-31 18:10 +0200
Re: Linux Firmware Signing Mimi Zohar <zohar@linux.vnet.ibm.com> - 2015-08-31 18:50 +0200
Re: Linux Firmware Signing "Luis R. Rodriguez" <mcgrof@suse.com> - 2015-09-02 02:10 +0200
Re: Linux Firmware Signing "Luis R. Rodriguez" <mcgrof@suse.com> - 2015-09-02 01:50 +0200
Re: Linux Firmware Signing Kees Cook <keescook@chromium.org> - 2015-09-02 05:10 +0200
Re: Linux Firmware Signing Mimi Zohar <zohar@linux.vnet.ibm.com> - 2015-09-02 05:50 +0200
Re: Linux Firmware Signing Kees Cook <keescook@chromium.org> - 2015-09-02 17:30 +0200
Re: Linux Firmware Signing Mimi Zohar <zohar@linux.vnet.ibm.com> - 2015-09-02 18:50 +0200
Re: Linux Firmware Signing Austin S Hemmelgarn <ahferroin7@gmail.com> - 2015-09-02 19:40 +0200
Re: Linux Firmware Signing Mimi Zohar <zohar@linux.vnet.ibm.com> - 2015-09-03 02:00 +0200
Re: Linux Firmware Signing "Luis R. Rodriguez" <mcgrof@suse.com> - 2015-09-03 02:20 +0200
Re: Linux Firmware Signing Kees Cook <keescook@chromium.org> - 2015-09-01 22:30 +0200
Re: Linux Firmware Signing "Luis R. Rodriguez" <mcgrof@suse.com> - 2015-09-02 02:10 +0200
Re: Linux Firmware Signing Mimi Zohar <zohar@linux.vnet.ibm.com> - 2015-09-02 05:40 +0200
Re: Linux Firmware Signing "Luis R. Rodriguez" <mcgrof@suse.com> - 2015-09-02 20:50 +0200
Re: Linux Firmware Signing Kees Cook <keescook@chromium.org> - 2015-09-02 23:00 +0200
Re: Linux Firmware Signing "Luis R. Rodriguez" <mcgrof@suse.com> - 2015-09-02 23:40 +0200
Re: Linux Firmware Signing Kees Cook <keescook@chromium.org> - 2015-09-03 23:20 +0200
Re: Linux Firmware Signing Mimi Zohar <zohar@linux.vnet.ibm.com> - 2015-09-03 02:10 +0200
Re: Linux Firmware Signing "Luis R. Rodriguez" <mcgrof@suse.com> - 2015-09-03 02:30 +0200
Re: Linux Firmware Signing Mimi Zohar <zohar@linux.vnet.ibm.com> - 2015-09-03 05:10 +0200
Re: Linux Firmware Signing "Luis R. Rodriguez" <mcgrof@suse.com> - 2015-08-27 21:40 +0200
Page 2 of 3 — ← Prev page 1 [2] 3 Next page →
| From | David Woodhouse <dwmw2@infradead.org> |
|---|---|
| Date | 2015-08-31 18:10 +0200 |
| Message-ID | <q3zOH-4hj-39@gated-at.bofh.it> |
| In reply to | #1216222 |
[Multipart message — attachments visible in raw view] — view raw
On Mon, 2015-08-31 at 10:18 -0400, Mimi Zohar wrote: > I'm not real happy about it, but since we can't break the existing ABI > of loading data into the kernel via a buffer, a stop gap method of > signing and verifying a buffer would be needed. Actually I think we can. The usermode helper is already being phased out. -- dwmw2
[toc] | [prev] | [next] | [standalone]
| From | Mimi Zohar <zohar@linux.vnet.ibm.com> |
|---|---|
| Date | 2015-08-31 18:50 +0200 |
| Message-ID | <q3Arq-50w-39@gated-at.bofh.it> |
| In reply to | #1216291 |
On Mon, 2015-08-31 at 17:05 +0100, David Woodhouse wrote: > On Mon, 2015-08-31 at 10:18 -0400, Mimi Zohar wrote: > > I'm not real happy about it, but since we can't break the existing ABI > > of loading data into the kernel via a buffer, a stop gap method of > > signing and verifying a buffer would be needed. > > Actually I think we can. The usermode helper is already being phased > out. Right. The discussion has moved beyond just firmware, but to policies and other things the kernel consumes. Mimi -- 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/
[toc] | [prev] | [next] | [standalone]
| From | "Luis R. Rodriguez" <mcgrof@suse.com> |
|---|---|
| Date | 2015-09-02 02:10 +0200 |
| Message-ID | <q43MK-5iI-9@gated-at.bofh.it> |
| In reply to | #1216321 |
On Mon, Aug 31, 2015 at 12:45:36PM -0400, Mimi Zohar wrote: > On Mon, 2015-08-31 at 17:05 +0100, David Woodhouse wrote: > > On Mon, 2015-08-31 at 10:18 -0400, Mimi Zohar wrote: > > > I'm not real happy about it, but since we can't break the existing ABI > > > of loading data into the kernel via a buffer, a stop gap method of > > > signing and verifying a buffer would be needed. > > > > Actually I think we can. The usermode helper is already being phased > > out. > > Right. The discussion has moved beyond just firmware, but to policies > and other things the kernel consumes. And I'm saying that if the pitch here is we should be vetting *all* buffers passed to the kernel I'd agree a generic interface is desriable but more importantly I think we should get everyone on board first and its not clear to me that has yet happened. For the other interfaces were discussing that *did* have an obvious file descriptor (struct fd), or file (struct file) use it would seem obvious to try to streamline that and share the code there (modules, firmware, kexec, initramfs, SELinux policy files), our only issues there were what to do about file that some distros require to be generated by machines and are machine specific (SELinux policy file in some cases, initramfs in some others) and for that Paul had suggested to consider the Machine Owner Key (MOK) -- but now for buffers.... its news to me we had everyone up in arms in agreement on that crusade. I didn't even know such crusade existed. I can see why, but was just not aware there was an effort to streamline a solution. Luis -- 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/
[toc] | [prev] | [next] | [standalone]
| From | "Luis R. Rodriguez" <mcgrof@suse.com> |
|---|---|
| Date | 2015-09-02 01:50 +0200 |
| Message-ID | <q43to-4H0-13@gated-at.bofh.it> |
| In reply to | #1216222 |
On Mon, Aug 31, 2015 at 10:18:55AM -0400, Mimi Zohar wrote:
> On Sat, 2015-08-29 at 04:16 +0200, Luis R. Rodriguez wrote:
> > On Thu, Aug 27, 2015 at 07:54:33PM -0400, Mimi Zohar wrote:
> > > On Thu, 2015-08-27 at 23:29 +0200, Luis R. Rodriguez wrote:
> > > > On Thu, Aug 27, 2015 at 10:57:23AM -0000, David Woodhouse wrote:
> > > > > > Luis R. Rodriguez <mcgrof@suse.com> wrote:
>
> > > > > In conversation with Mimi last week she was very keen on the model where
> > > > > we load modules & firmware in such a fashion that the kernel has access to
> > > > > the original inode -- by passing in a fd,
> > > >
> > > > Sure, so let's be specific to ensure what Mimi needs is there. I though there
> > > > was work needed on modules but that seems covered and work then seems only
> > > > needed for kexec and SELinux policy files (and a review of other possible file
> > > > consumers in the kernel) for what you describe.
> >
> > Correct me if I'm wrong:
> >
> > > At last year's LSS linux-integrity status update, I mentioned 6
> > > measurement/appraisal gaps, kernel modules (linux-3.7),
> >
> > Done.
> >
> > > firmware (linux-3.17),
> >
> > I'm working on it, but as far as LSMs are concerned the LSM hook
> > is in place.
>
> Right, the LSM hooks are used by LSMs, but also used by the integrity
> subsystem, like here, to measure the file and verify the integrity of
> the file.
Great.
> int security_kernel_fw_from_file(struct file *file, char *buf, size_t size)
> {
> int ret;
>
> ret = call_int_hook(kernel_fw_from_file, 0, file, buf, size);
> if (ret)
> return ret;
> return ima_fw_from_file(file, buf, size);
> }
>
> > > kexec,
> >
> > I'll note kexec has both a kernel and initramfs :) so just keep that
> > in mind. Technically it should vet for both. It seems we just need
> > an LSM hook there.
>
> Distros build the initramfs on the target system, so the initramfs can't
> come signed.
This seems to apply for some distributions.
> But for those systems that the initramfs can be signed, we
> should be verifying it.
Right so there are different solutions to this problem, it will depend on the
distribution and solution they have in place for this. For instance maybe some
distros may be satisfied with the integrity of the initramfs for kexec *iff*
they can vet for the integrity of the components that build the initramfs on
the target system, or perhaps they distribute the initramfs used by some
systems so they use singing facilities trusted by the kernel, or in the IMA
case you do boot up vetting through xatrrs and IMA.
A lot of this means a lot of these signing facilities then should be optional
and work in a permissive mode. Part of my earlier work (already merged) on the firmware
signing stuff was to take out from module signing code the part that let it be
permissive with my goal to re-share the same strategy for other purposes. This
is accomplished by using the bool_enable_only module parameter, for instance fw
signing will use:
+static bool sysdata_sig_enforce = IS_ENABLED(CONFIG_SYSTEM_DATA_SIG_FORCE);
+#ifndef CONFIG_SYSTEM_DATA_SIG_FORCE
+module_param(sysdata_sig_enforce, bool_enable_only, 0644);
+#endif /* !CONFIG_SYSTEM_DATA_SIG_FORCE */
Technically it should also be possible to remove the #ifndef provided we can
all rest assured no bullets can be put through it. Anyway, that's the gist of
the permissive model copied from module signing. If we have a lot of similar
users it begs the question if we should somehow drivertize a generic interface
for these things so that the actual implemenation that deals with permissivity
is shared, its perhaps too early to do that now but something to keep in mind
as it does sound like we will have a bit of users of the same mechanisms /
strategy. Exactly how they need to be differentiated remains to be seen.
> > > initramfs,
> >
> > Hm, what code path?
>
> In addition, the files within the initramfs should be measured and
> verified. There isn't a need for a new hook, but for xattr support in
> CPIO. I started adding that support last winter -
> http://lwn.net/Articles/630101/ . Others have requested other changes,
> not related to xattrs, before bumping the CPIO magic number. There
> should be a discussion as to what else needs to be done.
I see, thanks. Another way to do this is to copy the module signing
strategy and since the initramfs is linked in just peg the sinagure of the
blog at the end. This of course would mean you have to be permissive to
only enable folks who want this feature.
> > > eBPF/seccomp
OK I knew nothing about this but I just looked into it, here are my notes:
* old BPF - how far do we want to go? This goes so far as to parsing
user passed void __user *arg data through ioctls which typically
gets copy_from_user()'d and eventually gets BPF_PROG_RUN().
* eBPF:
seccomp() & prctl_set_seccomp()
|
V
do_seccomp()
|
V
seccomp_set_mode_filter()
|
V
seccomp_prepare_user_filter()
|
V
bpf_prog_create_from_user() (seccomp) \
bpf_prog_create() > bpf_prepare_filter()
sk_attach_filter() /
All approaches come from user passed data, nothing fd based.
For both old BPF and eBPF then:
If we wanted to be paranoid I suppose the Machine Owner Key (MOK)
Paul had mentioned up could be used to vet for passed filters, or
a new interface to enable fd based filters. This really would limit
the dynamic nature of these features though.
eBPF / secccomp would not be the only place in the kernel that would have
issues with user passed data, we have tons of places the same applies so
implicating the old BPF / eBPF / seccomp approaches can easily implicate
many other areas of the kernel, that's pretty huge but from the looks of
it below you seem to enable that to be a possibility for us to consider.
> > > and policies,
> >
> > Which ones?
Again not clear which ones.
> > > that have
> > > been or need to be addressed. Since then, a new kexec syscall, file
> > > descriptor based, was upstreamed that appraises the image. Until we can
> > > preserve the measurement list across kexec,
> >
> > I'm sorry I do not follow, can you elaborate on what you mean by this.
> > Its not clear to me what you mean by the measurement list. Do you mean
> > all the above items?
>
> A measurement is a hash of the file which is stored in the measurement
> list <securityfs>/ima/ascii_runtime_measurements and is used to extend
> the TPM (eg. PCR 10). The measurement list, in conjunction with a
> quote of the TPM PCRs, can be used to remotely detect whether a system
> has been compromised.
I see thanks. In light of that its unclear why you'd want to "preserve"
the measurement list from one boot onto another.
> David Safford's white paper "An Overview of the Linux Integrity
> subsystem" -
> http://downloads.sf.net/project/linux-ima/linux-ima/Integrity_overview.pdf goes into details of the different terms and concepts. (The IMA wiki is dated.) There's also a ic2e paper titled "Scalable Attestation: a step toward secure and trusted cloud".
>
> > > it doesn't make sense to
> > > measure the image just to have it thrown away. (skipping initramfs as
> > > that isn't related to LSM hooks
> >
> > Hrm, it can be, I mean at least for the kexec case its a fd that is passed
> > as part of the syscall, not sure of the other case you mentioned yet
> > as I haven't reviewed that code yet.
>
> Right, in those situations that the initramfs can be signed, it should
> be verified.
OK.
> > >.) Lastly, measuring/appraising policies
> > > (eg. IMA, SELinux, Smack, iptables/ebtables)
> >
> > OK for each of these:
> >
> > how do we load the data?
>
> I'm not real happy about it, but since we can't break the existing ABI
> of loading data into the kernel via a buffer, a stop gap method of
> signing and verifying a buffer would be needed.
Right so if such a solution were really desirable it would seem we'd be
wanting to change a histical approach to user <--> kernel interfaces.
This is a pretty significant change in paradigm. Is everyone on board?
> > Is that the full list? Note we should
> > be able to use grammar rules to hunt these down, I just haven't
> > sat down to write them but if this is important well we should.
> >
> > > or any other files consumed
> > > by the kernel.
> >
> > :D likewise
>
> < skip >
>
> > It'd be good for us to do a further review to really vet *all* areas.
> > I am not convinced we've covered them all.
>
> Agreed
Luis
--
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/
[toc] | [prev] | [next] | [standalone]
| From | Kees Cook <keescook@chromium.org> |
|---|---|
| Date | 2015-09-02 05:10 +0200 |
| Message-ID | <q46AV-Yh-3@gated-at.bofh.it> |
| In reply to | #1217178 |
On Tue, Sep 1, 2015 at 4:43 PM, Luis R. Rodriguez <mcgrof@suse.com> wrote: > On Mon, Aug 31, 2015 at 10:18:55AM -0400, Mimi Zohar wrote: >> > > eBPF/seccomp > > OK I knew nothing about this but I just looked into it, here are my notes: > > * old BPF - how far do we want to go? This goes so far as to parsing > user passed void __user *arg data through ioctls which typically > gets copy_from_user()'d and eventually gets BPF_PROG_RUN(). > > * eBPF: > seccomp() & prctl_set_seccomp() > | > V > do_seccomp() > | > V > seccomp_set_mode_filter() > | > V > seccomp_prepare_user_filter() > | > V > bpf_prog_create_from_user() (seccomp) \ > bpf_prog_create() > bpf_prepare_filter() > sk_attach_filter() / > > All approaches come from user passed data, nothing fd based. > > For both old BPF and eBPF then: > > If we wanted to be paranoid I suppose the Machine Owner Key (MOK) > Paul had mentioned up could be used to vet for passed filters, or > a new interface to enable fd based filters. This really would limit > the dynamic nature of these features though. > > eBPF / secccomp would not be the only place in the kernel that would have > issues with user passed data, we have tons of places the same applies so > implicating the old BPF / eBPF / seccomp approaches can easily implicate > many other areas of the kernel, that's pretty huge but from the looks of > it below you seem to enable that to be a possibility for us to consider. At the time (LSS 2014?) I argued that seccomp policies come from binaries, which are already being measured. And that policies only further restrict a process, so there seems to be to be little risk in continuing to leave them unmeasured. -Kees -- Kees Cook Chrome OS Security -- 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/
[toc] | [prev] | [next] | [standalone]
| From | Mimi Zohar <zohar@linux.vnet.ibm.com> |
|---|---|
| Date | 2015-09-02 05:50 +0200 |
| Message-ID | <q47dD-1GL-3@gated-at.bofh.it> |
| In reply to | #1217297 |
On Tue, 2015-09-01 at 20:08 -0700, Kees Cook wrote: > On Tue, Sep 1, 2015 at 4:43 PM, Luis R. Rodriguez <mcgrof@suse.com> wrote: > > On Mon, Aug 31, 2015 at 10:18:55AM -0400, Mimi Zohar wrote: > >> > > eBPF/seccomp > > > > OK I knew nothing about this but I just looked into it, here are my notes: > > > > * old BPF - how far do we want to go? This goes so far as to parsing > > user passed void __user *arg data through ioctls which typically > > gets copy_from_user()'d and eventually gets BPF_PROG_RUN(). > > > > * eBPF: > > seccomp() & prctl_set_seccomp() > > | > > V > > do_seccomp() > > | > > V > > seccomp_set_mode_filter() > > | > > V > > seccomp_prepare_user_filter() > > | > > V > > bpf_prog_create_from_user() (seccomp) \ > > bpf_prog_create() > bpf_prepare_filter() > > sk_attach_filter() / > > > > All approaches come from user passed data, nothing fd based. > > > > For both old BPF and eBPF then: > > > > If we wanted to be paranoid I suppose the Machine Owner Key (MOK) > > Paul had mentioned up could be used to vet for passed filters, or > > a new interface to enable fd based filters. This really would limit > > the dynamic nature of these features though. > > > > eBPF / secccomp would not be the only place in the kernel that would have > > issues with user passed data, we have tons of places the same applies so > > implicating the old BPF / eBPF / seccomp approaches can easily implicate > > many other areas of the kernel, that's pretty huge but from the looks of > > it below you seem to enable that to be a possibility for us to consider. > > At the time (LSS 2014?) I argued that seccomp policies come from > binaries, which are already being measured. And that policies only > further restrict a process, so there seems to be to be little risk in > continuing to leave them unmeasured. What do you mean by "measured"? Who is doing the measurement? Could someone detect a change in measurement? Mimi -- 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/
[toc] | [prev] | [next] | [standalone]
| From | Kees Cook <keescook@chromium.org> |
|---|---|
| Date | 2015-09-02 17:30 +0200 |
| Message-ID | <q4i96-yB-57@gated-at.bofh.it> |
| In reply to | #1217305 |
On Tue, Sep 1, 2015 at 8:44 PM, Mimi Zohar <zohar@linux.vnet.ibm.com> wrote: > On Tue, 2015-09-01 at 20:08 -0700, Kees Cook wrote: >> On Tue, Sep 1, 2015 at 4:43 PM, Luis R. Rodriguez <mcgrof@suse.com> wrote: >> > On Mon, Aug 31, 2015 at 10:18:55AM -0400, Mimi Zohar wrote: >> >> > > eBPF/seccomp >> > >> > OK I knew nothing about this but I just looked into it, here are my notes: >> > >> > * old BPF - how far do we want to go? This goes so far as to parsing >> > user passed void __user *arg data through ioctls which typically >> > gets copy_from_user()'d and eventually gets BPF_PROG_RUN(). >> > >> > * eBPF: >> > seccomp() & prctl_set_seccomp() >> > | >> > V >> > do_seccomp() >> > | >> > V >> > seccomp_set_mode_filter() >> > | >> > V >> > seccomp_prepare_user_filter() >> > | >> > V >> > bpf_prog_create_from_user() (seccomp) \ >> > bpf_prog_create() > bpf_prepare_filter() >> > sk_attach_filter() / >> > >> > All approaches come from user passed data, nothing fd based. >> > >> > For both old BPF and eBPF then: >> > >> > If we wanted to be paranoid I suppose the Machine Owner Key (MOK) >> > Paul had mentioned up could be used to vet for passed filters, or >> > a new interface to enable fd based filters. This really would limit >> > the dynamic nature of these features though. >> > >> > eBPF / secccomp would not be the only place in the kernel that would have >> > issues with user passed data, we have tons of places the same applies so >> > implicating the old BPF / eBPF / seccomp approaches can easily implicate >> > many other areas of the kernel, that's pretty huge but from the looks of >> > it below you seem to enable that to be a possibility for us to consider. >> >> At the time (LSS 2014?) I argued that seccomp policies come from >> binaries, which are already being measured. And that policies only >> further restrict a process, so there seems to be to be little risk in >> continuing to leave them unmeasured. > > What do you mean by "measured"? Who is doing the measurement? Could > someone detect a change in measurement? I meant from the perspective of IMA. The binary would have already been evaluated when it executed, and it's what's installing the seccomp filter. And since seccomp filters can only reduce privilege, it seems like they're not worth getting processed by IMA. But I might not understand the requirements! :) -Kees -- Kees Cook Chrome OS Security -- 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/
[toc] | [prev] | [next] | [standalone]
| From | Mimi Zohar <zohar@linux.vnet.ibm.com> |
|---|---|
| Date | 2015-09-02 18:50 +0200 |
| Message-ID | <q4jou-2g9-23@gated-at.bofh.it> |
| In reply to | #1217700 |
On Wed, 2015-09-02 at 08:28 -0700, Kees Cook wrote: > On Tue, Sep 1, 2015 at 8:44 PM, Mimi Zohar <zohar@linux.vnet.ibm.com> wrote: > > On Tue, 2015-09-01 at 20:08 -0700, Kees Cook wrote: > >> On Tue, Sep 1, 2015 at 4:43 PM, Luis R. Rodriguez <mcgrof@suse.com> wrote: > >> > On Mon, Aug 31, 2015 at 10:18:55AM -0400, Mimi Zohar wrote: > >> >> > > eBPF/seccomp > >> > > >> > OK I knew nothing about this but I just looked into it, here are my notes: > >> > > >> > * old BPF - how far do we want to go? This goes so far as to parsing > >> > user passed void __user *arg data through ioctls which typically > >> > gets copy_from_user()'d and eventually gets BPF_PROG_RUN(). > >> > > >> > * eBPF: > >> > seccomp() & prctl_set_seccomp() > >> > | > >> > V > >> > do_seccomp() > >> > | > >> > V > >> > seccomp_set_mode_filter() > >> > | > >> > V > >> > seccomp_prepare_user_filter() > >> > | > >> > V > >> > bpf_prog_create_from_user() (seccomp) \ > >> > bpf_prog_create() > bpf_prepare_filter() > >> > sk_attach_filter() / > >> > > >> > All approaches come from user passed data, nothing fd based. > >> > > >> > For both old BPF and eBPF then: > >> > > >> > If we wanted to be paranoid I suppose the Machine Owner Key (MOK) > >> > Paul had mentioned up could be used to vet for passed filters, or > >> > a new interface to enable fd based filters. This really would limit > >> > the dynamic nature of these features though. > >> > > >> > eBPF / secccomp would not be the only place in the kernel that would have > >> > issues with user passed data, we have tons of places the same applies so > >> > implicating the old BPF / eBPF / seccomp approaches can easily implicate > >> > many other areas of the kernel, that's pretty huge but from the looks of > >> > it below you seem to enable that to be a possibility for us to consider. > >> > >> At the time (LSS 2014?) I argued that seccomp policies come from > >> binaries, which are already being measured. And that policies only > >> further restrict a process, so there seems to be to be little risk in > >> continuing to leave them unmeasured. > > > > What do you mean by "measured"? Who is doing the measurement? Could > > someone detect a change in measurement? > > I meant from the perspective of IMA. The binary would have already > been evaluated when it executed, and it's what's installing the > seccomp filter. And since seccomp filters can only reduce privilege, > it seems like they're not worth getting processed by IMA. But I might > not understand the requirements! :) So because we trust the binary, we can trust the resulting output that is loaded into the kernel. That assumes the trusted binary appraises it's input, right? We're relying on seccomp filters to reduce privileges properly. This isn't any different than trusting any other policies consumed by the kernel. Mimi -- 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/
[toc] | [prev] | [next] | [standalone]
| From | Austin S Hemmelgarn <ahferroin7@gmail.com> |
|---|---|
| Date | 2015-09-02 19:40 +0200 |
| Message-ID | <q4kaR-3pO-3@gated-at.bofh.it> |
| In reply to | #1217746 |
[Multipart message — attachments visible in raw view] — view raw
On 2015-09-02 12:45, Mimi Zohar wrote: > On Wed, 2015-09-02 at 08:28 -0700, Kees Cook wrote: >> On Tue, Sep 1, 2015 at 8:44 PM, Mimi Zohar <zohar@linux.vnet.ibm.com> wrote: >>> On Tue, 2015-09-01 at 20:08 -0700, Kees Cook wrote: >>>> On Tue, Sep 1, 2015 at 4:43 PM, Luis R. Rodriguez <mcgrof@suse.com> wrote: >>>>> On Mon, Aug 31, 2015 at 10:18:55AM -0400, Mimi Zohar wrote: >>>>>>>> eBPF/seccomp >>>>> >>>>> OK I knew nothing about this but I just looked into it, here are my notes: >>>>> >>>>> * old BPF - how far do we want to go? This goes so far as to parsing >>>>> user passed void __user *arg data through ioctls which typically >>>>> gets copy_from_user()'d and eventually gets BPF_PROG_RUN(). >>>>> >>>>> * eBPF: >>>>> seccomp() & prctl_set_seccomp() >>>>> | >>>>> V >>>>> do_seccomp() >>>>> | >>>>> V >>>>> seccomp_set_mode_filter() >>>>> | >>>>> V >>>>> seccomp_prepare_user_filter() >>>>> | >>>>> V >>>>> bpf_prog_create_from_user() (seccomp) \ >>>>> bpf_prog_create() > bpf_prepare_filter() >>>>> sk_attach_filter() / >>>>> >>>>> All approaches come from user passed data, nothing fd based. >>>>> >>>>> For both old BPF and eBPF then: >>>>> >>>>> If we wanted to be paranoid I suppose the Machine Owner Key (MOK) >>>>> Paul had mentioned up could be used to vet for passed filters, or >>>>> a new interface to enable fd based filters. This really would limit >>>>> the dynamic nature of these features though. >>>>> >>>>> eBPF / secccomp would not be the only place in the kernel that would have >>>>> issues with user passed data, we have tons of places the same applies so >>>>> implicating the old BPF / eBPF / seccomp approaches can easily implicate >>>>> many other areas of the kernel, that's pretty huge but from the looks of >>>>> it below you seem to enable that to be a possibility for us to consider. >>>> >>>> At the time (LSS 2014?) I argued that seccomp policies come from >>>> binaries, which are already being measured. And that policies only >>>> further restrict a process, so there seems to be to be little risk in >>>> continuing to leave them unmeasured. >>> >>> What do you mean by "measured"? Who is doing the measurement? Could >>> someone detect a change in measurement? >> >> I meant from the perspective of IMA. The binary would have already >> been evaluated when it executed, and it's what's installing the >> seccomp filter. And since seccomp filters can only reduce privilege, >> it seems like they're not worth getting processed by IMA. But I might >> not understand the requirements! :) > > So because we trust the binary, we can trust the resulting output that > is loaded into the kernel. That assumes the trusted binary appraises > it's input, right? We're relying on seccomp filters to reduce > privileges properly. This isn't any different than trusting any other > policies consumed by the kernel. > Except many binaries that use seccomp (at least most of the ones that I've seen) don't change the filter based on input, but have it hard-coded into the binary and only offer to turn it on or off based on user input.
[toc] | [prev] | [next] | [standalone]
| From | Mimi Zohar <zohar@linux.vnet.ibm.com> |
|---|---|
| Date | 2015-09-03 02:00 +0200 |
| Message-ID | <q4q6C-3oh-7@gated-at.bofh.it> |
| In reply to | #1217178 |
On Wed, 2015-09-02 at 01:43 +0200, Luis R. Rodriguez wrote: > On Mon, Aug 31, 2015 at 10:18:55AM -0400, Mimi Zohar wrote: > > On Sat, 2015-08-29 at 04:16 +0200, Luis R. Rodriguez wrote: > > > On Thu, Aug 27, 2015 at 07:54:33PM -0400, Mimi Zohar wrote: > > > > On Thu, 2015-08-27 at 23:29 +0200, Luis R. Rodriguez wrote: > Right so there are different solutions to this problem, it will depend on the > distribution and solution they have in place for this. For instance maybe some > distros may be satisfied with the integrity of the initramfs for kexec *iff* > they can vet for the integrity of the components that build the initramfs on > the target system, or perhaps they distribute the initramfs used by some > systems so they use singing facilities trusted by the kernel, or in the IMA > case you do boot up vetting through xatrrs and IMA. > > A lot of this means a lot of these signing facilities then should be optional > and work in a permissive mode. Part of my earlier work (already merged) on the firmware > signing stuff was to take out from module signing code the part that let it be > permissive with my goal to re-share the same strategy for other purposes. This > is accomplished by using the bool_enable_only module parameter, for instance fw > signing will use: > > +static bool sysdata_sig_enforce = IS_ENABLED(CONFIG_SYSTEM_DATA_SIG_FORCE); > +#ifndef CONFIG_SYSTEM_DATA_SIG_FORCE > +module_param(sysdata_sig_enforce, bool_enable_only, 0644); > +#endif /* !CONFIG_SYSTEM_DATA_SIG_FORCE */ > > Technically it should also be possible to remove the #ifndef provided we can > all rest assured no bullets can be put through it. Anyway, that's the gist of > the permissive model copied from module signing. If we have a lot of similar > users it begs the question if we should somehow drivertize a generic interface > for these things so that the actual implemenation that deals with permissivity > is shared, its perhaps too early to do that now but something to keep in mind > as it does sound like we will have a bit of users of the same mechanisms / > strategy. Exactly how they need to be differentiated remains to be seen. Ok. Each "hook" would require a separate config option to allow flexibility. With this design, the decision for requiring signatures would be made at build. Do we really want policy hard coded into the kernel? (IMA is policy based.) > > > > initramfs, > > > > > > Hm, what code path? > > > > In addition, the files within the initramfs should be measured and > > verified. There isn't a need for a new hook, but for xattr support in > > CPIO. I started adding that support last winter - > > http://lwn.net/Articles/630101/ . Others have requested other changes, > > not related to xattrs, before bumping the CPIO magic number. There > > should be a discussion as to what else needs to be done. > > I see, thanks. Another way to do this is to copy the module signing > strategy and since the initramfs is linked in just peg the sinagure of the > blog at the end. This of course would mean you have to be permissive to > only enable folks who want this feature. At the same time the boot loader verifies the kernel signature, it could verify the the initramfs signature. kexec should emulate whatever the boot loader's method for verifying the initramfs signature. > > > > that have > > > > been or need to be addressed. Since then, a new kexec syscall, file > > > > descriptor based, was upstreamed that appraises the image. Until we can > > > > preserve the measurement list across kexec, > > > > > > I'm sorry I do not follow, can you elaborate on what you mean by this. > > > Its not clear to me what you mean by the measurement list. Do you mean > > > all the above items? > > > > A measurement is a hash of the file which is stored in the measurement > > list <securityfs>/ima/ascii_runtime_measurements and is used to extend > > the TPM (eg. PCR 10). The measurement list, in conjunction with a > > quote of the TPM PCRs, can be used to remotely detect whether a system > > has been compromised. > > I see thanks. In light of that its unclear why you'd want to "preserve" > the measurement list from one boot onto another. The TPM is reset on a hard reboot, not a soft one like kexec. Without preserving the measurement list across kexec, we would not be able to validate the quote. > > > >.) Lastly, measuring/appraising policies > > > > (eg. IMA, SELinux, Smack, iptables/ebtables) > > > > > > OK for each of these: > > > > > > how do we load the data? > > > > I'm not real happy about it, but since we can't break the existing ABI > > of loading data into the kernel via a buffer, a stop gap method of > > signing and verifying a buffer would be needed. > > Right so if such a solution were really desirable it would seem we'd be > wanting to change a histical approach to user <--> kernel interfaces. > This is a pretty significant change in paradigm. Is everyone on board? Perhaps defining a common method and converting an example or two would make sense, before making sure "everyone" is on board. The IMA policy could be the first. Dmitry has already added support for verifying the policy's signature for those systems without an initramfs. I can look into generalizing that solution. Mimi -- 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/
[toc] | [prev] | [next] | [standalone]
| From | "Luis R. Rodriguez" <mcgrof@suse.com> |
|---|---|
| Date | 2015-09-03 02:20 +0200 |
| Message-ID | <q4qpY-3ZU-5@gated-at.bofh.it> |
| In reply to | #1217951 |
On Wed, Sep 02, 2015 at 07:54:13PM -0400, Mimi Zohar wrote: > On Wed, 2015-09-02 at 01:43 +0200, Luis R. Rodriguez wrote: > > On Mon, Aug 31, 2015 at 10:18:55AM -0400, Mimi Zohar wrote: > > > On Sat, 2015-08-29 at 04:16 +0200, Luis R. Rodriguez wrote: > > > > On Thu, Aug 27, 2015 at 07:54:33PM -0400, Mimi Zohar wrote: > > > > > On Thu, 2015-08-27 at 23:29 +0200, Luis R. Rodriguez wrote: > > > Right so there are different solutions to this problem, it will depend on the > > distribution and solution they have in place for this. For instance maybe some > > distros may be satisfied with the integrity of the initramfs for kexec *iff* > > they can vet for the integrity of the components that build the initramfs on > > the target system, or perhaps they distribute the initramfs used by some > > systems so they use singing facilities trusted by the kernel, or in the IMA > > case you do boot up vetting through xatrrs and IMA. > > > > A lot of this means a lot of these signing facilities then should be optional > > and work in a permissive mode. Part of my earlier work (already merged) on the firmware > > signing stuff was to take out from module signing code the part that let it be > > permissive with my goal to re-share the same strategy for other purposes. This > > is accomplished by using the bool_enable_only module parameter, for instance fw > > signing will use: > > > > +static bool sysdata_sig_enforce = IS_ENABLED(CONFIG_SYSTEM_DATA_SIG_FORCE); > > +#ifndef CONFIG_SYSTEM_DATA_SIG_FORCE > > +module_param(sysdata_sig_enforce, bool_enable_only, 0644); > > +#endif /* !CONFIG_SYSTEM_DATA_SIG_FORCE */ > > > > Technically it should also be possible to remove the #ifndef provided we can > > all rest assured no bullets can be put through it. Anyway, that's the gist of > > the permissive model copied from module signing. If we have a lot of similar > > users it begs the question if we should somehow drivertize a generic interface > > for these things so that the actual implemenation that deals with permissivity > > is shared, its perhaps too early to do that now but something to keep in mind > > as it does sound like we will have a bit of users of the same mechanisms / > > strategy. Exactly how they need to be differentiated remains to be seen. > > Ok. Each "hook" would require a separate config option to allow > flexibility. With this design, the decision for requiring signatures > would be made at build. Do we really want policy hard coded into the > kernel? (IMA is policy based.) The thing is module signing is a policy built into the kernel, and as such firmware signing is following that tradition as well. The way historically module signing has evolved over time as LSMs have is through separate frameworks as such naturally its only now we've started to consider module signign through the eyes of a possible future core-LSM that others can stack over. Even with this long term possibility its still a kernel policy. Other similar functionality will natrally follow suit. > > > > > initramfs, > > > > > > > > Hm, what code path? > > > > > > In addition, the files within the initramfs should be measured and > > > verified. There isn't a need for a new hook, but for xattr support in > > > CPIO. I started adding that support last winter - > > > http://lwn.net/Articles/630101/ . Others have requested other changes, > > > not related to xattrs, before bumping the CPIO magic number. There > > > should be a discussion as to what else needs to be done. > > > > I see, thanks. Another way to do this is to copy the module signing > > strategy and since the initramfs is linked in just peg the sinagure of the > > blog at the end. This of course would mean you have to be permissive to > > only enable folks who want this feature. > > At the same time the boot loader verifies the kernel signature, it could > verify the the initramfs signature. kexec should emulate whatever the > boot loader's method for verifying the initramfs signature. Up to you guys :) > > > > > that have > > > > > been or need to be addressed. Since then, a new kexec syscall, file > > > > > descriptor based, was upstreamed that appraises the image. Until we can > > > > > preserve the measurement list across kexec, > > > > > > > > I'm sorry I do not follow, can you elaborate on what you mean by this. > > > > Its not clear to me what you mean by the measurement list. Do you mean > > > > all the above items? > > > > > > A measurement is a hash of the file which is stored in the measurement > > > list <securityfs>/ima/ascii_runtime_measurements and is used to extend > > > the TPM (eg. PCR 10). The measurement list, in conjunction with a > > > quote of the TPM PCRs, can be used to remotely detect whether a system > > > has been compromised. > > > > I see thanks. In light of that its unclear why you'd want to "preserve" > > the measurement list from one boot onto another. > > The TPM is reset on a hard reboot, not a soft one like kexec. Without > preserving the measurement list across kexec, we would not be able to > validate the quote. I see. Anyone doing that work? > > > > >.) Lastly, measuring/appraising policies > > > > > (eg. IMA, SELinux, Smack, iptables/ebtables) > > > > > > > > OK for each of these: > > > > > > > > how do we load the data? > > > > > > I'm not real happy about it, but since we can't break the existing ABI > > > of loading data into the kernel via a buffer, a stop gap method of > > > signing and verifying a buffer would be needed. > > > > Right so if such a solution were really desirable it would seem we'd be > > wanting to change a histical approach to user <--> kernel interfaces. > > This is a pretty significant change in paradigm. Is everyone on board? > > Perhaps defining a common method and converting an example or two would > make sense, before making sure "everyone" is on board. The IMA policy > could be the first. Dmitry has already added support for verifying the > policy's signature for those systems without an initramfs. I can look > into generalizing that solution. That would be nice. I think you want a pretty board audience review. The change in paradigm is pretty significant. Luis -- 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/
[toc] | [prev] | [next] | [standalone]
| From | Kees Cook <keescook@chromium.org> |
|---|---|
| Date | 2015-09-01 22:30 +0200 |
| Message-ID | <q40lQ-j7-3@gated-at.bofh.it> |
| In reply to | #1214834 |
On Thu, Aug 27, 2015 at 2:29 PM, Luis R. Rodriguez <mcgrof@suse.com> wrote: > On Thu, Aug 27, 2015 at 10:57:23AM -0000, David Woodhouse wrote: >> In conversation with Mimi last week she was very keen on the model where >> we load modules & firmware in such a fashion that the kernel has access to >> the original inode -- by passing in a fd, > > Sure, so let's be specific to ensure what Mimi needs is there. I though there It's not just IMA: the loadpin LSM needs an fd also (to tie back to dm-verity). > Right so now that firmware usermode helper is behind us (systemd ripped it) we > do the fs lookup directly ourselves. One of my side goals with the extensible Totally agreed: nothing uses the usermode helper any more, so we should ignore that moving forward. > I was under the impression that work was needed to add an LSM hook which would > grant the LSM access to the file specific data for modules but that's already > there with finit_module()! So Mimi needs is already there for modules as well > now. Nope, this was all already done. The kexec loading interface was also designed so that I could add an LSM hook for it without lots of work. > We have no LSM hook for kexec, even though the kernel does have access to the > fd, so if you wanted the struct file for an LSM it should be possible as the > syscall for kexec is: I can send a patch to add this; it should be trivial. :) (It's not high on my TODO list at the moment just because Chrome OS doesn't use kexec.) > Everywhere where we fetch a file from within the kernel either directly (say > firmware load, 802.11 regulatory request) or from userspace request (SELinux > policy load node) we end up having to sprinkle a new LSM hook. In fact for > modules and kexec there were syscalls added too. There might be a possiblity > for sharing some of these requests / code so some review is in order for it. Those syscalls were needed because the original ones were designed a long time ago. :) > Here's my review if we wanted to try sharing things, in consideration and > review of: > > * SELinux policy files > * modules > * firmware / system data (consider replacing CRDA) > * kexec > > ---- > > * SELinux policy files: > > sel_write_load() is very specific, its part of the selinuxfs and it just > uses copy_from_user() to dump the data from the file onto a vmalloc'd > piece of memory. We don't exactly read arbitrary files from the fs then. > If we *really* wanted to generalize things further we probably could > but I'm not going to lead any discussion about design over selinuxfs, > I'll let the folks behind it think about that themselves. > > * modules > * firmware / system data > > modules + firmware: there seems to be some code sharing we could possibly do > for both fw_read_file() and copy_module_from_fd(), note we are going to use > different keys for vetting each of these. It may be possible to share the > LSM hook here. All parties would just need to agree. As long as the LSM know what kind of file it's loading, and has access to the fd (and for IMA, the blob loaded from that fd), that should be everything it needs. IMA has the name and blob, loadpin has the fd, and a future signature-checking LSM could be able to look up signature type from the load type, and split the key off (or fetch the key file) itself. If we expect to stack signature checkers, we can optimize the signature parsing/loading infrastructure then. But since we have neither the sigchecking LSM nor multiple ones, we can leave that to later. > > * kexec > > kexec works by reading files and setting up pointers for the different > segments it needs for bootup, it does this for both the kernel and initrd > if present. It however uses its own copy_file_from_fd() routine and no > surprise here, there's code that can be shared as well. We'd be using > a separate signature for kexec, so that'd be vetted on its own already. > It may be possible to share the same LSM hook here, again all parties > would just need to agree. > > ---- > > So conclusion: > > After fw signing gets baked (or I'll do that as I work with the system data > helpers) there is possible work here to consolidate firmware's fw_read_file(), > module's fw_read_file(), and kexec's copy_file_from_fd() into a core kernel > tiny helper that gets it done right for all. If we really wanted to we could > also just use the same LSM hook for all, this hook would surely have the > struct file as Mimi wants as well. Unless I misunderstood things, at the > Linux security summit it seemed folks thought this was reasonable and > desirable. One of the gains then would be that the kernel can grow for > different use cases and files can be fetched as needed but we wouldn't have to > add yet-another-LSM hook for each new purpose, we'd just be sharing the same > fetch / LSM hook. Please discuss and let me know if this still stands, I'll > work towards any agreed upon direction with the fw signing code. > > And again, there may other parts of the kernel that do similar work, just > as we found out about SELinux policy files. Those need to be identified > and studied separatley. I guess we can use grammar to hunt these down. > > Luis -Kees -- Kees Cook Chrome OS Security -- 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/
[toc] | [prev] | [next] | [standalone]
| From | "Luis R. Rodriguez" <mcgrof@suse.com> |
|---|---|
| Date | 2015-09-02 02:10 +0200 |
| Message-ID | <q43MK-5iI-15@gated-at.bofh.it> |
| In reply to | #1217065 |
On Tue, Sep 01, 2015 at 01:20:37PM -0700, Kees Cook wrote: > On Thu, Aug 27, 2015 at 2:29 PM, Luis R. Rodriguez <mcgrof@suse.com> wrote: > > On Thu, Aug 27, 2015 at 10:57:23AM -0000, David Woodhouse wrote: > > Right so now that firmware usermode helper is behind us (systemd ripped it) we > > do the fs lookup directly ourselves. One of my side goals with the extensible > > Totally agreed: nothing uses the usermode helper any more, so we > should ignore that moving forward. Great the patches I have in place for the system data helpers let us deprecate this and put that code in a dark corner. > > We have no LSM hook for kexec, even though the kernel does have access to the > > fd, so if you wanted the struct file for an LSM it should be possible as the > > syscall for kexec is: > > I can send a patch to add this; it should be trivial. :) (It's not > high on my TODO list at the moment just because Chrome OS doesn't use > kexec.) If there are no users for it and since we are talking about bringing things together I'd prefer if we try to come up with a shared solution for that as it seems it can wait for kexec. > > Everywhere where we fetch a file from within the kernel either directly (say > > firmware load, 802.11 regulatory request) or from userspace request (SELinux > > policy load node) we end up having to sprinkle a new LSM hook. In fact for > > modules and kexec there were syscalls added too. There might be a possiblity > > for sharing some of these requests / code so some review is in order for it. > > Those syscalls were needed because the original ones were designed a > long time ago. :) OK fine :) > > Here's my review if we wanted to try sharing things, in consideration and > > review of: > > > > * SELinux policy files > > * modules > > * firmware / system data (consider replacing CRDA) > > * kexec > > > > ---- > > > > * SELinux policy files: > > > > sel_write_load() is very specific, its part of the selinuxfs and it just > > uses copy_from_user() to dump the data from the file onto a vmalloc'd > > piece of memory. We don't exactly read arbitrary files from the fs then. > > If we *really* wanted to generalize things further we probably could > > but I'm not going to lead any discussion about design over selinuxfs, > > I'll let the folks behind it think about that themselves. > > > > * modules > > * firmware / system data > > > > modules + firmware: there seems to be some code sharing we could possibly do > > for both fw_read_file() and copy_module_from_fd(), note we are going to use > > different keys for vetting each of these. It may be possible to share the > > LSM hook here. All parties would just need to agree. > > As long as the LSM know what kind of file it's loading, and has access > to the fd (and for IMA, the blob loaded from that fd), that should be > everything it needs. IMA has the name and blob, loadpin has the fd, > and a future signature-checking LSM could be able to look up signature > type from the load type, and split the key off (or fetch the key file) > itself. OK great, I think that instead of passing the actual routine name we should instead pass an enum type for to the LSM, that'd be easier to parse and we'd then have each case well documented. Each LSM then could add its own documetnation for this and can switch on it. If we went with a name we'd have to to use something like __func__ and then parse that, its not clear if we need to get that specific. > If we expect to stack signature checkers, we can optimize the > signature parsing/loading infrastructure then. But since we have > neither the sigchecking LSM nor multiple ones, we can leave that to > later. Sure. Luis -- 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/
[toc] | [prev] | [next] | [standalone]
| From | Mimi Zohar <zohar@linux.vnet.ibm.com> |
|---|---|
| Date | 2015-09-02 05:40 +0200 |
| Message-ID | <q473X-1vB-3@gated-at.bofh.it> |
| In reply to | #1217181 |
On Wed, 2015-09-02 at 02:09 +0200, Luis R. Rodriguez wrote:
> On Tue, Sep 01, 2015 at 01:20:37PM -0700, Kees Cook wrote:
> > On Thu, Aug 27, 2015 at 2:29 PM, Luis R. Rodriguez <mcgrof@suse.com> wrote:
> > As long as the LSM know what kind of file it's loading, and has access
> > to the fd (and for IMA, the blob loaded from that fd), that should be
> > everything it needs. IMA has the name and blob, loadpin has the fd,
> > and a future signature-checking LSM could be able to look up signature
> > type from the load type, and split the key off (or fetch the key file)
> > itself.
I assume "and for IMA, the blob loaded from that fd" is referring to
the file signature stored in the xattr.
> OK great, I think that instead of passing the actual routine name we should
> instead pass an enum type for to the LSM, that'd be easier to parse and we'd
> then have each case well documented. Each LSM then could add its own
> documetnation for this and can switch on it. If we went with a name we'd have
> to to use something like __func__ and then parse that, its not clear if we need
> to get that specific.
Agreed. IMA already defines an enumeration.
/* IMA policy related functions */
enum ima_hooks { FILE_CHECK = 1, MMAP_CHECK, BPRM_CHECK, MODULE_CHECK,
FIRMWARE_CHECK, POLICY_CHECK, POST_SETATTR };
Mimi
--
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/
[toc] | [prev] | [next] | [standalone]
| From | "Luis R. Rodriguez" <mcgrof@suse.com> |
|---|---|
| Date | 2015-09-02 20:50 +0200 |
| Message-ID | <q4lgC-4Zd-19@gated-at.bofh.it> |
| In reply to | #1217303 |
On Tue, Sep 01, 2015 at 11:35:05PM -0400, Mimi Zohar wrote:
> > OK great, I think that instead of passing the actual routine name we should
> > instead pass an enum type for to the LSM, that'd be easier to parse and we'd
> > then have each case well documented. Each LSM then could add its own
> > documetnation for this and can switch on it. If we went with a name we'd have
> > to to use something like __func__ and then parse that, its not clear if we need
> > to get that specific.
>
> Agreed. IMA already defines an enumeration.
>
> /* IMA policy related functions */
> enum ima_hooks { FILE_CHECK = 1, MMAP_CHECK, BPRM_CHECK, MODULE_CHECK,
> FIRMWARE_CHECK, POLICY_CHECK, POST_SETATTR };
>
We want something that is not only useful for IMA but any other LSM,
and FILE_CHECK seems very broad, not sure what BPRM_CHECK is even upon
inspecting kernel code. Likewise for POST_SETATTR. POLICY_CHECK might
be broad, perhaps its best we define then a generic set of enums to
which IMA can map them to then and let it decide. This would ensure
that the kernel defines each use caes for file inspection carefully,
documents and defines them and if an LSM wants to bunch a set together
it can do so easily with a switch statement to map set of generic
file checks in kernel to a group it already handles.
For instance at least in the short term we'd try to unify:
security_kernel_fw_from_file()
security_kernel_module_from_file()
to perhaps:
security_kernel_from_file()
As far, as far as I can tell, the only ones we'd be ready to start
grouping immediately or with small amount of work rather soon:
/**
*
* enum security_filecheck - known kernel security file checks types
*
* @__SECURITY_FILECHECK_UNSPEC: attribute 0 reserved
* @SECURITY_FILECHECK_MODULE: the file being processed is a Linux kernel module
* @SECURITY_FILECHECK_SYSDATA: the file being processed is either a firmware
* file or a system data file read from /lib/firmware/* by firmware_class
* @SECURITY_FILECHECK_KEXEC_KERNEL: the file being processed is a kernel file
* used by kexec
* @SECURITY_FILECHECK_KEXEC_INITRAMFS: the file being processed is an initramfs
* used by kexec
* The kernel reads files directly from the filesystem for a series of
* operations. The list of files the kernel reads from the filesystem are
* limited and each type of file consumed may have a different format and
* security vetting procedures. The kernel enables LSMs to vet for these files
* through a shared LSM hook prior to consumption. This list documents the
* different special kernel file types read by the kernel, it enables LSMs
* to vet for each differently if needed.
enum security_filecheck {
SECURITY_FILECHECK_UNSPEC,
SECURITY_FILECHECK_MODULE,
SECURITY_FILECHECK_SYSDATA,
SECURITY_FILECHECK_KEXEC_KERNEL,
SECURITY_FILECHECK_KEXEC_INITRAMFS,
};
Provided the MOK thing or alternative gets addressed we could also soon add
something for SELinux policy files but that needs to be discussed further
it seems. If MOK is used would SECURITY_FILECHECK_POLICY_MOK be OK? Again
this would likely need further discussion, its why I didn't list it above.
Luis
--
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/
[toc] | [prev] | [next] | [standalone]
| From | Kees Cook <keescook@chromium.org> |
|---|---|
| Date | 2015-09-02 23:00 +0200 |
| Message-ID | <q4niq-7PZ-25@gated-at.bofh.it> |
| In reply to | #1217804 |
On Wed, Sep 2, 2015 at 11:46 AM, Luis R. Rodriguez <mcgrof@suse.com> wrote:
> On Tue, Sep 01, 2015 at 11:35:05PM -0400, Mimi Zohar wrote:
>> > OK great, I think that instead of passing the actual routine name we should
>> > instead pass an enum type for to the LSM, that'd be easier to parse and we'd
>> > then have each case well documented. Each LSM then could add its own
>> > documetnation for this and can switch on it. If we went with a name we'd have
>> > to to use something like __func__ and then parse that, its not clear if we need
>> > to get that specific.
>>
>> Agreed. IMA already defines an enumeration.
>>
>> /* IMA policy related functions */
>> enum ima_hooks { FILE_CHECK = 1, MMAP_CHECK, BPRM_CHECK, MODULE_CHECK,
>> FIRMWARE_CHECK, POLICY_CHECK, POST_SETATTR };
>>
>
> We want something that is not only useful for IMA but any other LSM,
> and FILE_CHECK seems very broad, not sure what BPRM_CHECK is even upon
> inspecting kernel code. Likewise for POST_SETATTR. POLICY_CHECK might
> be broad, perhaps its best we define then a generic set of enums to
> which IMA can map them to then and let it decide. This would ensure
> that the kernel defines each use caes for file inspection carefully,
> documents and defines them and if an LSM wants to bunch a set together
> it can do so easily with a switch statement to map set of generic
> file checks in kernel to a group it already handles.
>
> For instance at least in the short term we'd try to unify:
>
> security_kernel_fw_from_file()
> security_kernel_module_from_file()
>
> to perhaps:
>
> security_kernel_from_file()
>
> As far, as far as I can tell, the only ones we'd be ready to start
> grouping immediately or with small amount of work rather soon:
>
> /**
> *
> * enum security_filecheck - known kernel security file checks types
> *
> * @__SECURITY_FILECHECK_UNSPEC: attribute 0 reserved
> * @SECURITY_FILECHECK_MODULE: the file being processed is a Linux kernel module
> * @SECURITY_FILECHECK_SYSDATA: the file being processed is either a firmware
> * file or a system data file read from /lib/firmware/* by firmware_class
I'd prefer a distinct category for firmware, as it carries an
implication that it is an executable blob of some sort (I know not all
are, though).
-Kees
> * @SECURITY_FILECHECK_KEXEC_KERNEL: the file being processed is a kernel file
> * used by kexec
> * @SECURITY_FILECHECK_KEXEC_INITRAMFS: the file being processed is an initramfs
> * used by kexec
>
> * The kernel reads files directly from the filesystem for a series of
> * operations. The list of files the kernel reads from the filesystem are
> * limited and each type of file consumed may have a different format and
> * security vetting procedures. The kernel enables LSMs to vet for these files
> * through a shared LSM hook prior to consumption. This list documents the
> * different special kernel file types read by the kernel, it enables LSMs
> * to vet for each differently if needed.
> enum security_filecheck {
> SECURITY_FILECHECK_UNSPEC,
> SECURITY_FILECHECK_MODULE,
> SECURITY_FILECHECK_SYSDATA,
> SECURITY_FILECHECK_KEXEC_KERNEL,
> SECURITY_FILECHECK_KEXEC_INITRAMFS,
> };
>
> Provided the MOK thing or alternative gets addressed we could also soon add
> something for SELinux policy files but that needs to be discussed further
> it seems. If MOK is used would SECURITY_FILECHECK_POLICY_MOK be OK? Again
> this would likely need further discussion, its why I didn't list it above.
>
> Luis
--
Kees Cook
Chrome OS Security
--
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/
[toc] | [prev] | [next] | [standalone]
| From | "Luis R. Rodriguez" <mcgrof@suse.com> |
|---|---|
| Date | 2015-09-02 23:40 +0200 |
| Message-ID | <q4nV8-mO-15@gated-at.bofh.it> |
| In reply to | #1217855 |
On Wed, Sep 02, 2015 at 01:54:43PM -0700, Kees Cook wrote:
> On Wed, Sep 2, 2015 at 11:46 AM, Luis R. Rodriguez <mcgrof@suse.com> wrote:
> > On Tue, Sep 01, 2015 at 11:35:05PM -0400, Mimi Zohar wrote:
> >> > OK great, I think that instead of passing the actual routine name we should
> >> > instead pass an enum type for to the LSM, that'd be easier to parse and we'd
> >> > then have each case well documented. Each LSM then could add its own
> >> > documetnation for this and can switch on it. If we went with a name we'd have
> >> > to to use something like __func__ and then parse that, its not clear if we need
> >> > to get that specific.
> >>
> >> Agreed. IMA already defines an enumeration.
> >>
> >> /* IMA policy related functions */
> >> enum ima_hooks { FILE_CHECK = 1, MMAP_CHECK, BPRM_CHECK, MODULE_CHECK,
> >> FIRMWARE_CHECK, POLICY_CHECK, POST_SETATTR };
> >>
> >
> > We want something that is not only useful for IMA but any other LSM,
> > and FILE_CHECK seems very broad, not sure what BPRM_CHECK is even upon
> > inspecting kernel code. Likewise for POST_SETATTR. POLICY_CHECK might
> > be broad, perhaps its best we define then a generic set of enums to
> > which IMA can map them to then and let it decide. This would ensure
> > that the kernel defines each use caes for file inspection carefully,
> > documents and defines them and if an LSM wants to bunch a set together
> > it can do so easily with a switch statement to map set of generic
> > file checks in kernel to a group it already handles.
> >
> > For instance at least in the short term we'd try to unify:
> >
> > security_kernel_fw_from_file()
> > security_kernel_module_from_file()
> >
> > to perhaps:
> >
> > security_kernel_from_file()
> >
> > As far, as far as I can tell, the only ones we'd be ready to start
> > grouping immediately or with small amount of work rather soon:
> >
> > /**
> > *
> > * enum security_filecheck - known kernel security file checks types
> > *
> > * @__SECURITY_FILECHECK_UNSPEC: attribute 0 reserved
> > * @SECURITY_FILECHECK_MODULE: the file being processed is a Linux kernel module
> > * @SECURITY_FILECHECK_SYSDATA: the file being processed is either a firmware
> > * file or a system data file read from /lib/firmware/* by firmware_class
>
> I'd prefer a distinct category for firmware, as it carries an
> implication that it is an executable blob of some sort (I know not all
> are, though).
The ship has sailed in terms of folks using frimrware API for things
that are not-firmware per se. The first one I am aware of was the
EEPROM override for the p54 driver. The other similar one was CPU
microcode, but that's a bit more close to home with "firmware". We
could ask users on the new system data request API I am building
to describe the type of file being used, as I agree differentiating
this for security purposes might be important. So other than just
file type we could have sub type category, then we could have,
SECURITY_FILECHECK_SYSDATA, and then:
SECURITY_FILE_SYSDATA_FW
SECURITY_FILE_SYSDATA_MICROCODE
SECURITY_FILE_SYSDATA_EEPROM
SECURITY_FILE_SYSDATA_POLICY (for 802.11 regulatory I suppose)
If we do this then we could juse have:
SECURITY_FILECHECK_KEXEC and on that have substypes:
SECURITY_FILE_KEXEC_KERNEL
SECURITY_FILE_KEXEC_INITRAMFS
Would that be desirable and help grow this to be easily extensible?
Luis
--
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/
[toc] | [prev] | [next] | [standalone]
| From | Kees Cook <keescook@chromium.org> |
|---|---|
| Date | 2015-09-03 23:20 +0200 |
| Message-ID | <q4K5k-6Ws-11@gated-at.bofh.it> |
| In reply to | #1217868 |
[removed bounced email addresses]
On Wed, Sep 2, 2015 at 2:37 PM, Luis R. Rodriguez <mcgrof@suse.com> wrote:
> On Wed, Sep 02, 2015 at 01:54:43PM -0700, Kees Cook wrote:
>> On Wed, Sep 2, 2015 at 11:46 AM, Luis R. Rodriguez <mcgrof@suse.com> wrote:
>> > On Tue, Sep 01, 2015 at 11:35:05PM -0400, Mimi Zohar wrote:
>> >> > OK great, I think that instead of passing the actual routine name we should
>> >> > instead pass an enum type for to the LSM, that'd be easier to parse and we'd
>> >> > then have each case well documented. Each LSM then could add its own
>> >> > documetnation for this and can switch on it. If we went with a name we'd have
>> >> > to to use something like __func__ and then parse that, its not clear if we need
>> >> > to get that specific.
>> >>
>> >> Agreed. IMA already defines an enumeration.
>> >>
>> >> /* IMA policy related functions */
>> >> enum ima_hooks { FILE_CHECK = 1, MMAP_CHECK, BPRM_CHECK, MODULE_CHECK,
>> >> FIRMWARE_CHECK, POLICY_CHECK, POST_SETATTR };
>> >>
>> >
>> > We want something that is not only useful for IMA but any other LSM,
>> > and FILE_CHECK seems very broad, not sure what BPRM_CHECK is even upon
>> > inspecting kernel code. Likewise for POST_SETATTR. POLICY_CHECK might
>> > be broad, perhaps its best we define then a generic set of enums to
>> > which IMA can map them to then and let it decide. This would ensure
>> > that the kernel defines each use caes for file inspection carefully,
>> > documents and defines them and if an LSM wants to bunch a set together
>> > it can do so easily with a switch statement to map set of generic
>> > file checks in kernel to a group it already handles.
>> >
>> > For instance at least in the short term we'd try to unify:
>> >
>> > security_kernel_fw_from_file()
>> > security_kernel_module_from_file()
>> >
>> > to perhaps:
>> >
>> > security_kernel_from_file()
>> >
>> > As far, as far as I can tell, the only ones we'd be ready to start
>> > grouping immediately or with small amount of work rather soon:
>> >
>> > /**
>> > *
>> > * enum security_filecheck - known kernel security file checks types
>> > *
>> > * @__SECURITY_FILECHECK_UNSPEC: attribute 0 reserved
>> > * @SECURITY_FILECHECK_MODULE: the file being processed is a Linux kernel module
>> > * @SECURITY_FILECHECK_SYSDATA: the file being processed is either a firmware
>> > * file or a system data file read from /lib/firmware/* by firmware_class
>>
>> I'd prefer a distinct category for firmware, as it carries an
>> implication that it is an executable blob of some sort (I know not all
>> are, though).
>
> The ship has sailed in terms of folks using frimrware API for things
> that are not-firmware per se. The first one I am aware of was the
> EEPROM override for the p54 driver. The other similar one was CPU
> microcode, but that's a bit more close to home with "firmware". We
> could ask users on the new system data request API I am building
> to describe the type of file being used, as I agree differentiating
> this for security purposes might be important. So other than just
> file type we could have sub type category, then we could have,
>
> SECURITY_FILECHECK_SYSDATA, and then:
I object to executable code being called data. :)
> SECURITY_FILE_SYSDATA_FW
> SECURITY_FILE_SYSDATA_MICROCODE
> SECURITY_FILE_SYSDATA_EEPROM
> SECURITY_FILE_SYSDATA_POLICY (for 802.11 regulatory I suppose)
The exception to the firmware loading is data, so the primary name
should be firmware. Regardless, if we want distinct objects, just name
them:
SECURITY_FILE_FIRMWARE
SECURITY_FILE_SYSDATA
Do we need finer-grain sub types?
>
> If we do this then we could juse have:
>
> SECURITY_FILECHECK_KEXEC and on that have substypes:
>
> SECURITY_FILE_KEXEC_KERNEL
> SECURITY_FILE_KEXEC_INITRAMFS
>
> Would that be desirable and help grow this to be easily extensible?
>
> Luis
-Kees
--
Kees Cook
Chrome OS Security
--
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/
[toc] | [prev] | [next] | [standalone]
| From | Mimi Zohar <zohar@linux.vnet.ibm.com> |
|---|---|
| Date | 2015-09-03 02:10 +0200 |
| Message-ID | <q4qgi-3OK-15@gated-at.bofh.it> |
| In reply to | #1217804 |
On Wed, 2015-09-02 at 20:46 +0200, Luis R. Rodriguez wrote:
> On Tue, Sep 01, 2015 at 11:35:05PM -0400, Mimi Zohar wrote:
> > > OK great, I think that instead of passing the actual routine name we should
> > > instead pass an enum type for to the LSM, that'd be easier to parse and we'd
> > > then have each case well documented. Each LSM then could add its own
> > > documetnation for this and can switch on it. If we went with a name we'd have
> > > to to use something like __func__ and then parse that, its not clear if we need
> > > to get that specific.
> >
> > Agreed. IMA already defines an enumeration.
> >
> > /* IMA policy related functions */
> > enum ima_hooks { FILE_CHECK = 1, MMAP_CHECK, BPRM_CHECK, MODULE_CHECK,
> > FIRMWARE_CHECK, POLICY_CHECK, POST_SETATTR };
> >
>
> We want something that is not only useful for IMA but any other LSM,
> and FILE_CHECK seems very broad, not sure what BPRM_CHECK is even upon
> inspecting kernel code. Likewise for POST_SETATTR. POLICY_CHECK might
> be broad, perhaps its best we define then a generic set of enums to
> which IMA can map them to then and let it decide. This would ensure
> that the kernel defines each use caes for file inspection carefully,
> documents and defines them and if an LSM wants to bunch a set together
> it can do so easily with a switch statement to map set of generic
> file checks in kernel to a group it already handles.
The names are based on the calling security hook. For a description of
each of these security hooks refer to include/linux/lsm_hooks.h.
> For instance at least in the short term we'd try to unify:
>
> security_kernel_fw_from_file()
> security_kernel_module_from_file()
>
> to perhaps:
>
> security_kernel_from_file()
>
> As far, as far as I can tell, the only ones we'd be ready to start
> grouping immediately or with small amount of work rather soon:
>
> /**
> *
> * enum security_filecheck - known kernel security file checks types
> *
> * @__SECURITY_FILECHECK_UNSPEC: attribute 0 reserved
> * @SECURITY_FILECHECK_MODULE: the file being processed is a Linux kernel module
> * @SECURITY_FILECHECK_SYSDATA: the file being processed is either a firmware
> * file or a system data file read from /lib/firmware/* by firmware_class
> * @SECURITY_FILECHECK_KEXEC_KERNEL: the file being processed is a kernel file
> * used by kexec
> * @SECURITY_FILECHECK_KEXEC_INITRAMFS: the file being processed is an initramfs
> * used by kexec
>
> * The kernel reads files directly from the filesystem for a series of
> * operations. The list of files the kernel reads from the filesystem are
> * limited and each type of file consumed may have a different format and
> * security vetting procedures. The kernel enables LSMs to vet for these files
> * through a shared LSM hook prior to consumption. This list documents the
> * different special kernel file types read by the kernel, it enables LSMs
> * to vet for each differently if needed.
> enum security_filecheck {
> SECURITY_FILECHECK_UNSPEC,
> SECURITY_FILECHECK_MODULE,
> SECURITY_FILECHECK_SYSDATA,
> SECURITY_FILECHECK_KEXEC_KERNEL,
> SECURITY_FILECHECK_KEXEC_INITRAMFS,
> };
>
> Provided the MOK thing or alternative gets addressed we could also soon add
> something for SELinux policy files but that needs to be discussed further
> it seems. If MOK is used would SECURITY_FILECHECK_POLICY_MOK be OK? Again
> this would likely need further discussion, its why I didn't list it above.
Oh, I'm really confused as to why MOK would be a separate hook. I
thought the discussion was about using a key in the UEFI MOK DB for
verifying locally signed files.
Mimi
--
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/
[toc] | [prev] | [next] | [standalone]
| From | "Luis R. Rodriguez" <mcgrof@suse.com> |
|---|---|
| Date | 2015-09-03 02:30 +0200 |
| Message-ID | <q4qzE-4aY-1@gated-at.bofh.it> |
| In reply to | #1217956 |
On Wed, Sep 02, 2015 at 08:05:36PM -0400, Mimi Zohar wrote:
> On Wed, 2015-09-02 at 20:46 +0200, Luis R. Rodriguez wrote:
> > On Tue, Sep 01, 2015 at 11:35:05PM -0400, Mimi Zohar wrote:
> > > > OK great, I think that instead of passing the actual routine name we should
> > > > instead pass an enum type for to the LSM, that'd be easier to parse and we'd
> > > > then have each case well documented. Each LSM then could add its own
> > > > documetnation for this and can switch on it. If we went with a name we'd have
> > > > to to use something like __func__ and then parse that, its not clear if we need
> > > > to get that specific.
> > >
> > > Agreed. IMA already defines an enumeration.
> > >
> > > /* IMA policy related functions */
> > > enum ima_hooks { FILE_CHECK = 1, MMAP_CHECK, BPRM_CHECK, MODULE_CHECK,
> > > FIRMWARE_CHECK, POLICY_CHECK, POST_SETATTR };
> > >
> >
> > We want something that is not only useful for IMA but any other LSM,
> > and FILE_CHECK seems very broad, not sure what BPRM_CHECK is even upon
> > inspecting kernel code. Likewise for POST_SETATTR. POLICY_CHECK might
> > be broad, perhaps its best we define then a generic set of enums to
> > which IMA can map them to then and let it decide. This would ensure
> > that the kernel defines each use caes for file inspection carefully,
> > documents and defines them and if an LSM wants to bunch a set together
> > it can do so easily with a switch statement to map set of generic
> > file checks in kernel to a group it already handles.
>
> The names are based on the calling security hook. For a description of
> each of these security hooks refer to include/linux/lsm_hooks.h.
I see, thanks, ok so BPRM_CHECK = for binary loading, are you folks
really wanting to unify LSM hooks for firmware, modules, and binary
data ?
POST_SETATTR seems to be for inode_post_setxattr, so that as well?
POLICY_CHECK seems broad, not sure what to relate that to exactly.
Is this just SELinux polify files? Or is this something more broad?
> > For instance at least in the short term we'd try to unify:
> >
> > security_kernel_fw_from_file()
> > security_kernel_module_from_file()
> >
> > to perhaps:
> >
> > security_kernel_from_file()
> >
> > As far, as far as I can tell, the only ones we'd be ready to start
> > grouping immediately or with small amount of work rather soon:
> >
> > /**
> > *
> > * enum security_filecheck - known kernel security file checks types
> > *
> > * @__SECURITY_FILECHECK_UNSPEC: attribute 0 reserved
> > * @SECURITY_FILECHECK_MODULE: the file being processed is a Linux kernel module
> > * @SECURITY_FILECHECK_SYSDATA: the file being processed is either a firmware
> > * file or a system data file read from /lib/firmware/* by firmware_class
> > * @SECURITY_FILECHECK_KEXEC_KERNEL: the file being processed is a kernel file
> > * used by kexec
> > * @SECURITY_FILECHECK_KEXEC_INITRAMFS: the file being processed is an initramfs
> > * used by kexec
> >
> > * The kernel reads files directly from the filesystem for a series of
> > * operations. The list of files the kernel reads from the filesystem are
> > * limited and each type of file consumed may have a different format and
> > * security vetting procedures. The kernel enables LSMs to vet for these files
> > * through a shared LSM hook prior to consumption. This list documents the
> > * different special kernel file types read by the kernel, it enables LSMs
> > * to vet for each differently if needed.
> > enum security_filecheck {
> > SECURITY_FILECHECK_UNSPEC,
> > SECURITY_FILECHECK_MODULE,
> > SECURITY_FILECHECK_SYSDATA,
> > SECURITY_FILECHECK_KEXEC_KERNEL,
> > SECURITY_FILECHECK_KEXEC_INITRAMFS,
> > };
> >
> > Provided the MOK thing or alternative gets addressed we could also soon add
> > something for SELinux policy files but that needs to be discussed further
> > it seems. If MOK is used would SECURITY_FILECHECK_POLICY_MOK be OK? Again
> > this would likely need further discussion, its why I didn't list it above.
>
> Oh, I'm really confused as to why MOK would be a separate hook. I
> thought the discussion was about using a key in the UEFI MOK DB for
> verifying locally signed files.
That's correct, and no I was not thinking of a separate hook but rather
a type that lets the LSM know that MOK was used to sign the file consumed.
Luis
--
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/
[toc] | [prev] | [next] | [standalone]
Page 2 of 3 — ← Prev page 1 [2] 3 Next page →
Back to top | Article view | linux.kernel
csiph-web