Re: [PATCH] crypto: user - Allow CRYPTO_MSG_GETALG without CAP_NET_ADMIN
On 05/01/14 12:53, Marek Vasut wrote: > On Wednesday, April 30, 2014 at 09:23:40 PM, Matthias-Christian Ott wrote: >> On 04/28/14 23:37, Marek Vasut wrote: >>> On Friday, April 25, 2014 at 12:51:06 AM, Matthias-Christian Ott wrote: >>>> CRYPTO_USER requires CAP_NET_ADMIN for all operations. Most information >>>> provided by CRYPTO_MSG_GETALG is also accessible through /proc/modules >>>> and AF_ALG. CRYPTO_MSG_GETALG should not require CAP_NET_ADMIN so that >>>> processes without CAP_NET_ADMIN can use CRYPTO_MSG_GETALG to get cipher >>>> details, such as cipher priorities, for AF_ALG. >>>> >>>> Signed-off-by: Matthias-Christian Ott >>>> --- >>>> >>>> crypto/crypto_user.c | 12 +--- >>>> 1 file changed, 9 insertions(+), 3 deletions(-) >>> >>> Can you please submit the patch using git send-email so we can properly >>> review it? >> >> git-send-email or more specifically Net::SMTP only works with IPv4. The >> SMTP server I use for submission only listens IPv6 addresses. Moreover, >> TLS seems broken. I patched Net::SMTP to use IO::Socket::INET6 but gave >> up because of the TLS issues and used git format-patch and git imap-send. > > You can always set up a separate mailserver or use one of the many > free-to-use > mailservers to follow the agreed-upon submission process, right? I don't comment on this statement to keep this discussion focused (send me a private email if you want to discuss it). I did try to submit the email directly (with SPF disabled) from git send-email to vger.kernel.org but vger.kernel.org uses greylisting, so I can't help you with that. Can you simply copy the file that was attached on the first email I sent, save it to the filesystem and simply commit it in git? You would have to do this anyway if I filed a bug in the Kernel Bug Tracker. So there is an “agreed-upon submission process” to commit a file. > Of course, patches for Net::SMTP are welcome. I reported the bug and someone who actually knows Perl is working on it. -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] crypto: user - Allow CRYPTO_MSG_GETALG without CAP_NET_ADMIN
On 04/28/14 23:37, Marek Vasut wrote: > On Friday, April 25, 2014 at 12:51:06 AM, Matthias-Christian Ott wrote: >> CRYPTO_USER requires CAP_NET_ADMIN for all operations. Most information >> provided by CRYPTO_MSG_GETALG is also accessible through /proc/modules >> and AF_ALG. CRYPTO_MSG_GETALG should not require CAP_NET_ADMIN so that >> processes without CAP_NET_ADMIN can use CRYPTO_MSG_GETALG to get cipher >> details, such as cipher priorities, for AF_ALG. >> >> Signed-off-by: Matthias-Christian Ott >> --- >> crypto/crypto_user.c | 12 +--- >> 1 file changed, 9 insertions(+), 3 deletions(-) > > Can you please submit the patch using git send-email so we can properly > review > it? git-send-email or more specifically Net::SMTP only works with IPv4. The SMTP server I use for submission only listens IPv6 addresses. Moreover, TLS seems broken. I patched Net::SMTP to use IO::Socket::INET6 but gave up because of the TLS issues and used git format-patch and git imap-send. Regards, Matthias-Christian -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] crypto: user - Allow CRYPTO_MSG_GETALG without CAP_NET_ADMIN
CRYPTO_USER requires CAP_NET_ADMIN for all operations. Most information
provided by CRYPTO_MSG_GETALG is also accessible through /proc/modules
and AF_ALG. CRYPTO_MSG_GETALG should not require CAP_NET_ADMIN so that
processes without CAP_NET_ADMIN can use CRYPTO_MSG_GETALG to get cipher
details, such as cipher priorities, for AF_ALG.
Signed-off-by: Matthias-Christian Ott
---
crypto/crypto_user.c | 12 +---
1 file changed, 9 insertions(+), 3 deletions(-)
diff --git a/crypto/crypto_user.c b/crypto/crypto_user.c
index 1512e41..aa906b8 100644
--- a/crypto/crypto_user.c
+++ b/crypto/crypto_user.c
@@ -265,6 +265,9 @@ static int crypto_update_alg(struct sk_buff *skb, struct nlmsghdr *nlh,
struct nlattr *priority = attrs[CRYPTOCFGA_PRIORITY_VAL];
LIST_HEAD(list);
+ if (!capable(CAP_NET_ADMIN))
+ return -EPERM;
+
if (!null_terminated(p->cru_name) || !null_terminated(p->cru_driver_name))
return -EINVAL;
@@ -295,6 +298,9 @@ static int crypto_del_alg(struct sk_buff *skb, struct nlmsghdr *nlh,
struct crypto_alg *alg;
struct crypto_user_alg *p = nlmsg_data(nlh);
+ if (!capable(CAP_NET_ADMIN))
+ return -EPERM;
+
if (!null_terminated(p->cru_name) || !null_terminated(p->cru_driver_name))
return -EINVAL;
@@ -379,6 +385,9 @@ static int crypto_add_alg(struct sk_buff *skb, struct nlmsghdr *nlh,
struct crypto_user_alg *p = nlmsg_data(nlh);
struct nlattr *priority = attrs[CRYPTOCFGA_PRIORITY_VAL];
+ if (!capable(CAP_NET_ADMIN))
+ return -EPERM;
+
if (!null_terminated(p->cru_name) || !null_terminated(p->cru_driver_name))
return -EINVAL;
@@ -466,9 +475,6 @@ static int crypto_user_rcv_msg(struct sk_buff *skb, struct nlmsghdr *nlh)
type -= CRYPTO_MSG_BASE;
link = &crypto_dispatch[type];
- if (!capable(CAP_NET_ADMIN))
- return -EPERM;
-
if ((type == (CRYPTO_MSG_GETALG - CRYPTO_MSG_BASE) &&
(nlh->nlmsg_flags & NLM_F_DUMP))) {
struct crypto_alg *alg;
Why does CRYPTO_USER require CAP_NET_ADMIN?
If I'm not mistaken, CRYPTO_USER requires CAP_NET_ADMIN for all requests. Is there any reason for this requirement for read-only requests? I think read-only requests should not require CAP_NET_ADMIN. An example where this is important is important is AF_ALG. I'm working on AF_ALG support for GnuTLS, encryption and decryption via AF_ALG does not require special capabilities. However, retrieving the cipher priority to determine whether the cipher is hardware accelerated does require CAP_NET_ADMIN. Regards, Matthias-Christian -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Hardware acceleration indication in af_alg
On Fri, Oct 21, 2011 at 04:15:41PM +0200, Matthias-Christian Ott wrote: > On Fri, Oct 21, 2011 at 03:23:36PM +0200, Herbert Xu wrote: > > Matthias-Christian Ott wrote: > > > I did some experiments with af_alg and noticed that to be really > > > useful, it should indicate whether a certain algorithm is hardware > > > accelerated. I guess this has to be inferred by the priority of the > > > algorithm could be made available via a read-only socket option. Any > > > thoughts on this? > > > > > > I can imagine, an alternative approach and perhaps better approach > > > would be to measure the speed of the kernel provided algorithm against > > > a software implementation, but there are many other factors that could > > > influence the results. Therefore, it is perhaps better to just make > > > the assumption that hardware acceleration is faster which is made in > > > the kernel anyhow. > > > > You have to be careful to distinguish between hardware acceleration > > that is directly available to user-space (such as AESNI) and those > > that aren't. > > > > For the former it makes zero sense to go through the kernel as > > you'll only make it slower. The latter case is the reason why > > this interface exists. > > This is why I didn't consider hardware acceleration that is directly > available to user-space in the first place (I'm not aware of anything > except CPUs that is usable this way). So the question remains whether > e.g. the AES implementation provided through af_alg by the kernel is > faster (and thus most likely hardware accelerated) than a software > implementation. Since the kernel seems to make the assumption that > hardware acceleration is faster, I asked whether it would be possible to > pass this information to user-space as well. Ignore that e-mail. The the recent user configuration patches by Stefan Klassert seem to expose the algorithm's priority via CRYPTOCFGA_PRIORITY_VAL. This should solve my problem, provided that the patches will be included. Regards, Matthias-Christian -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Hardware acceleration indication in af_alg
On Fri, Oct 21, 2011 at 03:23:36PM +0200, Herbert Xu wrote: > Matthias-Christian Ott wrote: > > I did some experiments with af_alg and noticed that to be really > > useful, it should indicate whether a certain algorithm is hardware > > accelerated. I guess this has to be inferred by the priority of the > > algorithm could be made available via a read-only socket option. Any > > thoughts on this? > > > > I can imagine, an alternative approach and perhaps better approach > > would be to measure the speed of the kernel provided algorithm against > > a software implementation, but there are many other factors that could > > influence the results. Therefore, it is perhaps better to just make > > the assumption that hardware acceleration is faster which is made in > > the kernel anyhow. > > You have to be careful to distinguish between hardware acceleration > that is directly available to user-space (such as AESNI) and those > that aren't. > > For the former it makes zero sense to go through the kernel as > you'll only make it slower. The latter case is the reason why > this interface exists. This is why I didn't consider hardware acceleration that is directly available to user-space in the first place (I'm not aware of anything except CPUs that is usable this way). So the question remains whether e.g. the AES implementation provided through af_alg by the kernel is faster (and thus most likely hardware accelerated) than a software implementation. Since the kernel seems to make the assumption that hardware acceleration is faster, I asked whether it would be possible to pass this information to user-space as well. Regards, Matthias-Christian -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hardware acceleration indication in af_alg
I did some experiments with af_alg and noticed that to be really useful, it should indicate whether a certain algorithm is hardware accelerated. I guess this has to be inferred by the priority of the algorithm could be made available via a read-only socket option. Any thoughts on this? I can imagine, an alternative approach and perhaps better approach would be to measure the speed of the kernel provided algorithm against a software implementation, but there are many other factors that could influence the results. Therefore, it is perhaps better to just make the assumption that hardware acceleration is faster which is made in the kernel anyhow. Regards, Matthias-Christian -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
