Re: [systemd-devel] systemd should not depend on CONFIG_CRYPTO_USER_API_HASH

2017-03-20 Thread Mantas Mikulėnas
On Mon, Mar 20, 2017 at 3:50 PM, Cristian Rodríguez <
crrodrig...@opensuse.org> wrote:

>
>
> El 20-03-2017 a las 10:26, D.S. Ljungmark escribió:
> > I find your argument to be strange.
> >
> > "The kernel has this functionality, please do not use it and rather
> > reimplement it in every piece of userspace that ever needs it, because
> > that's supposed to be more secure."
> >
> > I simply don't buy your argument here.
>
> I guess we can't please everyone.. next it will come the "systemd has
> too many library dependencies" crowd :-|


systemd already has had a dependency on libgcrypt for a long time, though.

-- 
Mantas Mikulėnas 
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] systemd should not depend on CONFIG_CRYPTO_USER_API_HASH

2017-03-20 Thread Cristian Rodríguez


El 20-03-2017 a las 10:26, D.S. Ljungmark escribió:
> I find your argument to be strange.
> 
> "The kernel has this functionality, please do not use it and rather
> reimplement it in every piece of userspace that ever needs it, because
> that's supposed to be more secure."
> 
> I simply don't buy your argument here.

I guess we can't please everyone.. next it will come the "systemd has
too many library dependencies" crowd :-|


___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] systemd should not depend on CONFIG_CRYPTO_USER_API_HASH

2017-03-20 Thread D.S. Ljungmark
I find your argument to be strange.

"The kernel has this functionality, please do not use it and rather
reimplement it in every piece of userspace that ever needs it, because
that's supposed to be more secure."

I simply don't buy your argument here.

//D.S.

On Mon, Mar 20, 2017 at 8:22 AM, Eric Biggers  wrote:
> Hello,
>
> The latest systemd README and NEWS claim that the userspace interface to the
> in-kernel hash algorithms (CONFIG_CRYPTO_USER_API_HASH) is now required.
>
> I don't know how much thought was put into this decision, but I think it's a
> mistake security-wise.  AF_ALG sockets increase the kernel's attack surface by
> allowing users to instantiate and use arbitrary crypto algorithms, in
> combinations or ways which may not have been tested.  Indeed, historically 
> there
> have been a number of security vulnerabilities related to this feature, both 
> in
> the API itself and in the various crypto modules.  For this reason, I think
> security-conscious users would prefer to have this kernel feature turned off.
>
> Why exactly does systemd suddenly need this feature?  If it's really just to
> compute hashes, then please do it in userspace instead.  Unless systemd 
> *really*
> needs to support using hardware crypto accelerators, there is no need to call
> into the kernel just to compute hashes.  Or at the very least, make the
> dependency optional.
>
> Thanks!
>
> - Eric
> ___
> systemd-devel mailing list
> systemd-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/systemd-devel



-- 
8362 CB14 98AD 11EF CEB6  FA81 FCC3 7674 449E 3CFC
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


[systemd-devel] systemd should not depend on CONFIG_CRYPTO_USER_API_HASH

2017-03-20 Thread Eric Biggers
Hello,

The latest systemd README and NEWS claim that the userspace interface to the
in-kernel hash algorithms (CONFIG_CRYPTO_USER_API_HASH) is now required.

I don't know how much thought was put into this decision, but I think it's a
mistake security-wise.  AF_ALG sockets increase the kernel's attack surface by
allowing users to instantiate and use arbitrary crypto algorithms, in
combinations or ways which may not have been tested.  Indeed, historically there
have been a number of security vulnerabilities related to this feature, both in
the API itself and in the various crypto modules.  For this reason, I think
security-conscious users would prefer to have this kernel feature turned off.

Why exactly does systemd suddenly need this feature?  If it's really just to
compute hashes, then please do it in userspace instead.  Unless systemd *really*
needs to support using hardware crypto accelerators, there is no need to call
into the kernel just to compute hashes.  Or at the very least, make the
dependency optional.

Thanks!

- Eric
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel