RE: [tpmdd-devel] [PATCH 2/2] keys, trusted: seal with a policy

[Fuchs, Andreas]

> 
> From: Jarkko Sakkinen [jarkko.sakki...@linux.intel.com]
> Sent: Tuesday, November 17, 2015 17:27
> 
> Support for sealing with a authorization policy.
> 
> Two new options for trusted keys:
> 
> * 'policydigest=': provide an auth policy digest for sealing.
> * 'policyhandle=': provide a policy session handle for unsealing.

Hi Jarkko,

just out of curiosity; when testing this, how did you calculate the blobauth 
parameter ?
Since its calculation requires the cpHash for the unseal()-command...
If you "predict" the cpHash in userSpace, this would mean that userspace needs 
to know the
kernels way of constructing the unseal()-command to the TPM, which in turn 
would make
this part of the ABI and require documentation before upstreaming, imho.

Cheers,
Andreas--
To unsubscribe from this list: send the line "unsubscribe 
linux-security-module" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 0/7] User namespace mount updates

[Richard W.M. Jones]

On Thu, Nov 19, 2015 at 03:49:00PM +0100, Richard Weinberger wrote:
> Am 19.11.2015 um 15:37 schrieb Colin Walters:
> > On Thu, Nov 19, 2015, at 02:53 AM, Richard Weinberger wrote:
> > 
> >> Erm, I don't want this in the kernel. That's why I've proposed the lklfuse 
> >> approach.
> > 
> > I already said this before but just to repeat, since I'm confused:
> > 
> > How would "lklfuse" be different from http://libguestfs.org/
> > which we at Red Hat (and a number of other organizations)
> > use quite widely now for build systems, debugging etc.
> 
> Currently libguestfs has a rather huge overhead because it
> boots a full virtual machine and hence a lot of communication
> is needed.
> With LKL you can use Linux as Library and link it to fuse.
> AFAIK Richard added already a LKL backend to libguestfs. :-)

Right.  For the longer story, see:

https://rwmj.wordpress.com/2015/11/07/linux-kernel-library-backend-for-libguestfs/#content

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-top is 'top' for virtual machines.  Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
http://people.redhat.com/~rjones/virt-top
--
To unsubscribe from this list: send the line "unsubscribe 
linux-security-module" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/2] keys, trusted: seal with a policy

[James Morris]

On Wed, 18 Nov 2015, Jarkko Sakkinen wrote:

> On Wed, Nov 18, 2015 at 11:21:01AM +1100, James Morris wrote:
> > On Tue, 17 Nov 2015, Jarkko Sakkinen wrote:
> > 
> > >   }
> > >   break;
> > > + case Opt_policydigest:
> > > + if (!tpm2 ||
> > > + strlen(args[0].from) != (2 * opt->digest_len))
> > > + return -EINVAL;
> > > + kfree(opt->policydigest);
> > > + opt->policydigest = kzalloc(opt->digest_len,
> > > + GFP_KERNEL);
> > 
> > Is it correct to kfree opt->policydigest here before allocating it?
> 
> I think so. The same option might be encountered multiple times.

This would surely signify an error?


-- 
James Morris


--
To unsubscribe from this list: send the line "unsubscribe 
linux-security-module" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC] readlink()-related oddities

[Al Viro]

On Thu, Nov 19, 2015 at 06:13:53PM -0800, Linus Torvalds wrote:

> > 3) normally, readlink(2) fails for non-symlinks.  Moreover, according to
> > POSIX it should do so (with -EINVAL).
> 
> I don't think POSIX is necessarily relevant here.
> 
> We have had magic file behavior outside the scope of POSIX before, and
> we will have it in the future. It makes perfect sense to use
> readlink() for management tools for automounting, even if the normal
> oepration is to treat the thing as a directory.
> 
> Not everything is within the domain of POSIX.

How would those tools know that this particular pathname _is_ a magical
symlink?  Sure, if you see a symlink with body that starts with % or #,
you could figure out that it's not a regular one and go parse the body,
but for stat(2) it looks like a directory.  Do those tools call readlink()
on every directory they spot on AFS volume?  David?

And what's the story with magical ->open() for those?  How could one get
to ->open() on those sucker and avoid triggering the automount instead?
--
To unsubscribe from this list: send the line "unsubscribe 
linux-security-module" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC] readlink()-related oddities

[Linus Torvalds]

On Thu, Nov 19, 2015 at 6:57 PM, Al Viro  wrote:
>
> How would those tools know that this particular pathname _is_ a magical
> symlink?

Like maybe just the AFS management tools? By design you'd only run
them on the mountpoint in question.

Not everything has to be "generic". Sometimes its' good enough to just
have the ability to get the work done.

Now, if it turns out that others also want to do this, maybe somebody
decides "let's add flag -V to 'ls', which forces a 'readlink()' on all
the targets, whether links or not, and shows the information".

I could imagine other special files having "a single line of
information about the file" that they'd expose with readlink(). Who
knows?

So there is *potential* for just making it generic, but that doesn't
mean that it necessarily has to act that way.

Linus
--
To unsubscribe from this list: send the line "unsubscribe 
linux-security-module" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 0/7] User namespace mount updates

[Richard Weinberger]

Am 19.11.2015 um 15:37 schrieb Colin Walters:
> On Thu, Nov 19, 2015, at 02:53 AM, Richard Weinberger wrote:
> 
>> Erm, I don't want this in the kernel. That's why I've proposed the lklfuse 
>> approach.
> 
> I already said this before but just to repeat, since I'm confused:
> 
> How would "lklfuse" be different from http://libguestfs.org/
> which we at Red Hat (and a number of other organizations)
> use quite widely now for build systems, debugging etc.

Currently libguestfs has a rather huge overhead because it
boots a full virtual machine and hence a lot of communication
is needed.
With LKL you can use Linux as Library and link it to fuse.
AFAIK Richard added already a LKL backend to libguestfs. :-)

> In the end it's just running the kernel in KVM with a custom protocol,
> with support for non-filesystem things like "install a bootloader",
> and it already supports FUSE.
> 
> I'm pretty firmly with Al here - the attack surface increase here
> is too great, and we'd likely turn this off if it even did make it
> into the kernel.

Agreed. This is why I'm promoting the fuse solution.

Thanks,
//richard
--
To unsubscribe from this list: send the line "unsubscribe 
linux-security-module" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 0/7] User namespace mount updates

[Colin Walters]

On Thu, Nov 19, 2015, at 02:53 AM, Richard Weinberger wrote:

> Erm, I don't want this in the kernel. That's why I've proposed the lklfuse 
> approach.

I already said this before but just to repeat, since I'm confused:

How would "lklfuse" be different from http://libguestfs.org/
which we at Red Hat (and a number of other organizations)
use quite widely now for build systems, debugging etc.

In the end it's just running the kernel in KVM with a custom protocol,
with support for non-filesystem things like "install a bootloader",
and it already supports FUSE.

I'm pretty firmly with Al here - the attack surface increase here
is too great, and we'd likely turn this off if it even did make it
into the kernel.
--
To unsubscribe from this list: send the line "unsubscribe 
linux-security-module" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html