Re: [PATCH v1 7/7] ima: require signed IMA policy

2015-12-10 Thread Petko Manolov 
On 15-12-08 13:01:24, Mimi Zohar wrote:
> Require the IMA policy to be signed when additional rules can be added.
> 
> Signed-off-by: Mimi Zohar 
> ---
>  security/integrity/ima/ima_policy.c | 4 
>  1 file changed, 4 insertions(+)
> 
> diff --git a/security/integrity/ima/ima_policy.c 
> b/security/integrity/ima/ima_policy.c
> index 87614a6..6248ae23 100644
> --- a/security/integrity/ima/ima_policy.c
> +++ b/security/integrity/ima/ima_policy.c
> @@ -131,6 +131,10 @@ static struct ima_rule_entry default_appraise_rules[] = {
>   {.action = DONT_APPRAISE, .fsmagic = SELINUX_MAGIC, .flags = 
> IMA_FSMAGIC},
>   {.action = DONT_APPRAISE, .fsmagic = NSFS_MAGIC, .flags = IMA_FSMAGIC},
>   {.action = DONT_APPRAISE, .fsmagic = CGROUP_SUPER_MAGIC, .flags = 
> IMA_FSMAGIC},
> +#ifdef CONFIG_IMA_WRITE_POLICY
> + {.action = APPRAISE, .read_func = POLICY_CHECK,
> + .flags = IMA_FUNC | IMA_DIGSIG_REQUIRED},
> +#endif

The only time this is not going to work is when there is no IMA key in the 
keyring and there is no default policy so you need to load one at boot time.  
This case does not make much sense, however, so i assume the patch is fine.


>  #ifndef CONFIG_IMA_APPRAISE_SIGNED_INIT
>   {.action = APPRAISE, .fowner = GLOBAL_ROOT_UID, .flags = IMA_FOWNER},
>  #else


Petko
--
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 0/2] crypto: KEYS: convert public key to akcipher api

2015-12-10 Thread Mimi Zohar 
On Thu, 2015-12-10 at 10:39 -0800, Tadeusz Struk wrote:
> Hi Mimi,
> On 12/10/2015 10:25 AM, Mimi Zohar wrote:
> >> This patch set converts the module verification and digital signature
> >> > code to the new akcipher API.
> >> > RSA implementation has been removed from crypto/asymmetric_keys and the
> >> > new API is used for cryptographic primitives.
> >> > There is no need for MPI above the akcipher API anymore.
> >> > Modules can be verified with software as well as HW RSA implementations.
> > With these two patches my system doesn't even boot.  Digging deeper...
> > 
> 
> It needs RSA implementation built-in.
> Could you check if you have CONFIG_CRYPTO_RSA=y

The diff between this config and the previous one:
< CONFIG_CRYPTO_AKCIPHER=y
< CONFIG_CRYPTO_RSA=y
---
> # CONFIG_CRYPTO_RSA is not set

Mimi



--
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] X.509: Fix the time validation [ver #3]

2015-12-10 Thread Alexander Holler 

Am 12.11.2015 um 12:38 schrieb David Howells:

This fixes CVE-2015-5327.  It affects kernels from 4.3-rc1 onwards.

Fix the X.509 time validation to use month number-1 when looking up the
number of days in that month.  Also put the month number validation before
doing the lookup so as not to risk overrunning the array.


I've just run into this with 4.3.1 (mon_len ended up with 0 because of 
the wrong index). Which means currently build stable kernels with 
signature verification might not load modules (depending on which value 
the invalid index mon_len (12) ends up with.


Regards,

Alexander Holler

--
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 v1 7/7] ima: require signed IMA policy

2015-12-10 Thread Mimi Zohar 
On Thu, 2015-12-10 at 21:12 +0200, Petko Manolov wrote:

> On 15-12-08 13:01:24, Mimi Zohar wrote:
> > Require the IMA policy to be signed when additional rules can be added.
> > 
> > Signed-off-by: Mimi Zohar 
> > ---
> >  security/integrity/ima/ima_policy.c | 4 
> >  1 file changed, 4 insertions(+)
> > 
> > diff --git a/security/integrity/ima/ima_policy.c 
> > b/security/integrity/ima/ima_policy.c
> > index 87614a6..6248ae23 100644
> > --- a/security/integrity/ima/ima_policy.c
> > +++ b/security/integrity/ima/ima_policy.c
> > @@ -131,6 +131,10 @@ static struct ima_rule_entry default_appraise_rules[] 
> > = {
> > {.action = DONT_APPRAISE, .fsmagic = SELINUX_MAGIC, .flags = 
> > IMA_FSMAGIC},
> > {.action = DONT_APPRAISE, .fsmagic = NSFS_MAGIC, .flags = IMA_FSMAGIC},
> > {.action = DONT_APPRAISE, .fsmagic = CGROUP_SUPER_MAGIC, .flags = 
> > IMA_FSMAGIC},
> > +#ifdef CONFIG_IMA_WRITE_POLICY
> > +   {.action = APPRAISE, .read_func = POLICY_CHECK,
> > +   .flags = IMA_FUNC | IMA_DIGSIG_REQUIRED},
> > +#endif
> 
> The only time this is not going to work is when there is no IMA key in the 
> keyring and there is no default policy so you need to load one at boot time.  
> This case does not make much sense, however, so i assume the patch is fine.

Up to now, the policy could be replaced only once, which was normally
done in the initramfs.  With the ability to extend the IMA policy on a
running system, it is important that these policy extensions be signed.

To clarify, this patch modifies the builtin appraise policy, so that the
subsequent policy needs to be signed.  If the system is not booted with
the built-in appraise policy  (not a good idea), then the policy being
loaded won't need to be signed.

It is safe for the certificate file not to be signed, as the cert itself
must be signed by a key on either of the trusted (eg. system or ima_mok)
keyrings for it to be added to the .ima keyring.

Thank you reviewing the patch and making  sure it doesn't break your
usecase scenario.

Mimi

> >  #ifndef CONFIG_IMA_APPRAISE_SIGNED_INIT
> > {.action = APPRAISE, .fowner = GLOBAL_ROOT_UID, .flags = IMA_FOWNER},
> >  #else
> 
> 
>   Petko
> 


--
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

[RFC PATCH] VFS: Remove security module inode blob allocation overhead - unmundged

2015-12-10 Thread Casey Schaufler 
Subject: [RFC PATCH] VFS: Remove security module inode blob allocation overhead

Apologies for the previous mundged posting.

The LSM infrastructure requires that the security modules
allocate and free inode data as they require it. SELinux
and Smack, the two security modules that use inode data,
require that all inodes allocate security data. Allocating
and freeing this data independently from the inode adds
unnecessary overhead. The indirection from the inode to
the security blob also adds overhead.

I fully expect objections to this approach. This approach
would have been unreasonable when the LSM was introduced,
as the majority of systems did not use a security module.
That is no longer the case. Most systems (RedHat, Fedora,
Ubuntu, Tizen, Android) use security modules today.

Putting the security blob directly into the inode increases
the size of the inode. The relative sizes are:

Security disabled:  552
Security enabled, no module:552
Security enabled with Smack:624
Security enabled with SELinux:  632
Security enabled with both: 632

The first two numbers are the same because the module
data is only included if the module is included. There
is no i_security taking up space when it isn't needed.
The last two numbers are the same because i_selinux
and i_smack are unioned, which is sane since you can't
use them both at the same time. Systems using only
AppArmor get smaller inodes when properly configured.
Systems with security modules compiled out are unaffected.
Systems using either SELinux or Smack get full advantage.

It should be clear that for a properly configured kernel
it will always be advantageous to include the security blob
in the inode. By "properly configured" I mean simply that
the only security facilities built in are the ones that are
intended to be used, or that the value of generality is
sufficient to incur some overhead. A downside of this
approach is that the security blob structures are exposed.
I expect that there is some compiler trick I could use to
get the size of the blobs without doing so, but I am
disinclined to pursue that. Exposing the blob structure
has typing advantages.

Earlier discussions about changing the inode structure to
better accommodate the use of security data include:

https://lkml.org/lkml/2013/6/3/516

Signed-off-by: Casey Schaufler 
---
 fs/nfs/inode.c|   5 +-
 include/linux/fs.h|  11 +++-
 include/linux/selinux_blob.h  |  41 
 include/linux/smack_blob.h|  32 +
 security/security.c   |   2 +-
 security/selinux/hooks.c  | 132 +-
 security/selinux/include/objsec.h |  14 +---
 security/selinux/selinuxfs.c  |   8 +--
 security/smack/smack.h|  16 +
 security/smack/smack_lsm.c|  54 ++--
 10 files changed, 174 insertions(+), 141 deletions(-)

diff --git a/fs/nfs/inode.c b/fs/nfs/inode.c
index 326d9e1..157f99e 100644
--- a/fs/nfs/inode.c
+++ b/fs/nfs/inode.c
@@ -292,11 +292,14 @@ void nfs_setsecurity(struct inode *inode, struct 
nfs_fattr *fattr,
struct nfs4_label *label)
 {
int error;
+   u32 secid = 0;
 
if (label == NULL)
return;
 
-   if ((fattr->valid & NFS_ATTR_FATTR_V4_SECURITY_LABEL) && 
inode->i_security) {
+   security_inode_getsecid(inode, );
+
+   if ((fattr->valid & NFS_ATTR_FATTR_V4_SECURITY_LABEL) && secid != 0) {
error = security_inode_notifysecctx(inode, label->label,
label->len);
if (error)
diff --git a/include/linux/fs.h b/include/linux/fs.h
index 3aa5142..65d17fb 100644
--- a/include/linux/fs.h
+++ b/include/linux/fs.h
@@ -31,6 +31,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 
 #include 
 #include 
@@ -598,8 +600,15 @@ struct inode {
struct address_space*i_mapping;
 
 #ifdef CONFIG_SECURITY
-   void*i_security;
+   union {
+#ifdef CONFIG_SECURITY_SELINUX
+   struct inode_selinuxi_selinux;
+#endif
+#ifdef CONFIG_SECURITY_SMACK
+   struct inode_smack  i_smack;
 #endif
+   };
+#endif /* CONFIG_SECURITY */
 
/* Stat data, not accessed from path walking */
unsigned long   i_ino;
diff --git a/include/linux/selinux_blob.h b/include/linux/selinux_blob.h
new file mode 100644
index 000..0ee65bc
--- /dev/null
+++ b/include/linux/selinux_blob.h
@@ -0,0 +1,41 @@
+/*
+ *  NSA Security-Enhanced Linux (SELinux) security module
+ *
+ *  This file contains the SELinux security data structures for kernel objects
+ *  that are exposed outside the module.
+ *
+ *  Author(s):  Stephen Smalley, 
+ * Chris Vance, 
+ * Wayne Salamon, 
+ * James Morris

Re: [PATCH 0/2] crypto: KEYS: convert public key to akcipher api

2015-12-10 Thread Mimi Zohar 
On Thu, 2015-12-10 at 14:37 -0500, Mimi Zohar wrote:
> On Thu, 2015-12-10 at 10:39 -0800, Tadeusz Struk wrote:
> > Hi Mimi,
> > On 12/10/2015 10:25 AM, Mimi Zohar wrote:
> > >> This patch set converts the module verification and digital signature
> > >> > code to the new akcipher API.
> > >> > RSA implementation has been removed from crypto/asymmetric_keys and the
> > >> > new API is used for cryptographic primitives.
> > >> > There is no need for MPI above the akcipher API anymore.
> > >> > Modules can be verified with software as well as HW RSA 
> > >> > implementations.
> > > With these two patches my system doesn't even boot.  Digging deeper...
> > > 
> > 
> > It needs RSA implementation built-in.
> > Could you check if you have CONFIG_CRYPTO_RSA=y
> 
> The diff between this config and the previous one:
> < CONFIG_CRYPTO_AKCIPHER=y
> < CONFIG_CRYPTO_RSA=y
> ---
> > # CONFIG_CRYPTO_RSA is not set

FYI, dracut loaded the keys on the IMA keyring properly.  When we try to
pivot root, real root /sbin/init fails appraisal.  The audit subsystem
is showing "invalid-signature".

There's no additional debugging information with the boot command line
options rd.debug or systemd.log_level=debug.

Mimi


--
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

[RFC PATCH] VFS: Remove security module inode blob allocation overhead

2015-12-10 Thread Casey Schaufler 

Subject: [RFC PATCH] VFS: Remove security module inode blob allocation overhead

The LSM infrastructure requires that the security modules
allocate and free inode data as they require it. SELinux
and Smack, the two security modules that use inode data,
require that all inodes allocate security data. Allocating
and freeing this data independently from the inode adds
unnecessary overhead. The indirection from the inode to
the security blob also adds overhead.

I fully expect objections to this approach. This approach
would have been unreasonable when the LSM was introduced,
as the majority of systems did not use a security module.
That is no longer the case. Most systems (RedHat, Fedora,
Ubuntu, Tizen, Android) use security modules today.

Putting the security blob directly into the inode increases
the size of the inode. The relative sizes are:

Security disabled:  552
Security enabled, no module:552
Security enabled with Smack:624
Security enabled with SELinux:  632
Security enabled with both: 632

The first two numbers are the same because the module
data is only included if the module is included. There
is no i_security taking up space when it isn't needed.
The last two numbers are the same because i_selinux
and i_smack are unioned, which is sane since you can't
use them both at the same time. Systems using only
AppArmor get smaller inodes when properly configured.
Systems with security modules compiled out are unaffected.
Systems using either SELinux or Smack get full advantage.

It should be clear that for a properly configured kernel
it will always be advantageous to include the security blob
in the inode. By "properly configured" I mean simply that
the only security facilities built in are the ones that are
intended to be used, or that the value of generality is
sufficient to incur some overhead. A downside of this
approach is that the security blob structures are exposed.
I expect that there is some compiler trick I could use to
get the size of the blobs without doing so, but I am
disinclined to pursue that. Exposing the blob structure
has typing advantages.

Earlier discussions about changing the inode structure to
better accommodate the use of security data include:

https://lkml.org/lkml/2013/6/3/516

Signed-off-by: Casey Schaufler 
---
 fs/nfs/inode.c|   5 +-
 include/linux/fs.h|  11 +++-
 include/linux/selinux_blob.h  |  41 
 include/linux/smack_blob.h|  32 +
 security/security.c   |   2 +-
 security/selinux/hooks.c  | 132 +-
 security/selinux/include/objsec.h |  14 +---
 security/selinux/selinuxfs.c  |   8 +--
 security/smack/smack.h|  16 +
 security/smack/smack_lsm.c|  54 ++--
 10 files changed, 174 insertions(+), 141 deletions(-)

diff --git a/fs/nfs/inode.c b/fs/nfs/inode.c
index 326d9e1..157f99e 100644
--- a/fs/nfs/inode.c
+++ b/fs/nfs/inode.c
@@ -292,11 +292,14 @@ void nfs_setsecurity(struct inode *inode, struct 
nfs_fattr *fattr,
struct nfs4_label *label)
 {
int error;
+   u32 secid = 0;
 
 	if (label == NULL)

return;
 
-	if ((fattr->valid & NFS_ATTR_FATTR_V4_SECURITY_LABEL) && inode->i_security) {

+   security_inode_getsecid(inode, );
+
+   if ((fattr->valid & NFS_ATTR_FATTR_V4_SECURITY_LABEL) && secid != 0) {
error = security_inode_notifysecctx(inode, label->label,
label->len);
if (error)
diff --git a/include/linux/fs.h b/include/linux/fs.h
index 3aa5142..65d17fb 100644
--- a/include/linux/fs.h
+++ b/include/linux/fs.h
@@ -31,6 +31,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 
 #include 

 #include 
@@ -598,8 +600,15 @@ struct inode {
struct address_space*i_mapping;
 
 #ifdef CONFIG_SECURITY

-   void*i_security;
+   union {
+#ifdef CONFIG_SECURITY_SELINUX
+   struct inode_selinuxi_selinux;
+#endif
+#ifdef CONFIG_SECURITY_SMACK
+   struct inode_smack  i_smack;
 #endif
+   };
+#endif /* CONFIG_SECURITY */
 
 	/* Stat data, not accessed from path walking */

unsigned long   i_ino;
diff --git a/include/linux/selinux_blob.h b/include/linux/selinux_blob.h
new file mode 100644
index 000..0ee65bc
--- /dev/null
+++ b/include/linux/selinux_blob.h
@@ -0,0 +1,41 @@
+/*
+ *  NSA Security-Enhanced Linux (SELinux) security module
+ *
+ *  This file contains the SELinux security data structures for kernel objects
+ *  that are exposed outside the module.
+ *
+ *  Author(s):  Stephen Smalley, 
+ * Chris Vance, 
+ * Wayne Salamon, 
+ * James Morris 
+ * Casey Schaufler

Re: [PATCH 0/2] crypto: KEYS: convert public key to akcipher api

2015-12-10 Thread Mimi Zohar 
On Wed, 2015-12-09 at 15:52 -0800, Tadeusz Struk wrote:
> This patch set converts the module verification and digital signature
> code to the new akcipher API.
> RSA implementation has been removed from crypto/asymmetric_keys and the
> new API is used for cryptographic primitives.
> There is no need for MPI above the akcipher API anymore.
> Modules can be verified with software as well as HW RSA implementations.

With these two patches my system doesn't even boot.  Digging deeper...

Mimi

> Patches generated against cryptodev-2.6
> ---
> 
> Tadeusz Struk (2):
>   crypto: KEYS: convert public key to the akcipher api
>   integrity: convert digsig to akcipher api
> 
> 
>  crypto/asymmetric_keys/Kconfig|2 
>  crypto/asymmetric_keys/Makefile   |7 -
>  crypto/asymmetric_keys/pkcs7_parser.c |   12 +-
>  crypto/asymmetric_keys/pkcs7_trust.c  |2 
>  crypto/asymmetric_keys/pkcs7_verify.c |2 
>  crypto/asymmetric_keys/public_key.c   |   64 +++--
>  crypto/asymmetric_keys/public_key.h   |   36 -
>  crypto/asymmetric_keys/rsa.c  |  211 
> +++--
>  crypto/asymmetric_keys/x509_cert_parser.c |   37 +
>  crypto/asymmetric_keys/x509_public_key.c  |   17 +-
>  crypto/asymmetric_keys/x509_rsakey.asn1   |4 -
>  include/crypto/public_key.h   |   49 ++-
>  security/integrity/digsig_asymmetric.c|   10 -
>  13 files changed, 138 insertions(+), 315 deletions(-)
>  delete mode 100644 crypto/asymmetric_keys/public_key.h
>  delete mode 100644 crypto/asymmetric_keys/x509_rsakey.asn1
> 
> --
> TS
> --
> 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
> 


--
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] X.509: Fix the time validation [ver #3]

2015-12-10 Thread Greg Kroah-Hartman 
On Thu, Dec 10, 2015 at 07:00:46PM +0100, Alexander Holler wrote:
> Am 10.12.2015 um 16:34 schrieb Alexander Holler:
> >Am 10.12.2015 um 16:26 schrieb Greg Kroah-Hartman:
> >>On Thu, Dec 10, 2015 at 04:15:22PM +0100, Alexander Holler wrote:
> >
> >>>Just in case of, I would suggest to quickly push out 4.3.2 (only 4.3
> >>>seems
> >>>to be affected) which contains at least the patch mentioned in the
> >>>subject
> >>>(58585c1fc301a36625db41ac7078c4dd0a218d84 in mainline).
> >>
> >>58585c1fc301a36625db41ac7078c4dd0a218d84 doesn't reference anything in
> >>Linus's tree, where did you get that git commit id?
> >
> >Uh, hmm, maybe I've picked the wrong commit number when I've used git
> >gui blame to find the original commit. Might have been one from my own
> >trees which are based on mainline. Sorry, having had a second look, the
> >one I've cherry-picked from mainline was
> >cc25b994acfbc901429da682d0f73c190e960206
> 
> To give my motivation for that mail (and that "quickly"): it's highly
> annoying to end up with a box which does not have network and, as in my
> case, even without working input devices because modules weren't loaded. And
> other people don't might be able to find the problem (and existing patch) as
> quick as I did and might end up even more annoyed than I was for a short
> period of time. ;)

We already have one other report of this problem hitting them.  I've now
released 4.3.2-rc1, with a "quick" review period of 24 hours before I
release 4.3.2 with just this fix.  If you could verify I didn't mess
anything up I would appreciate it.

thanks,

greg k-h
--
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] X.509: Fix the time validation [ver #3]

2015-12-10 Thread Alexander Holler 

Am 10.12.2015 um 19:09 schrieb Greg Kroah-Hartman:


We already have one other report of this problem hitting them.  I've now
released 4.3.2-rc1, with a "quick" review period of 24 hours before I
release 4.3.2 with just this fix.  If you could verify I didn't mess
anything up I would appreciate it.


After applying those two patches from 4.3.2-rc1 you've posted instead of 
the one I've cherry-picked, git diff ended up with no difference to the 
source of the kernel I'm currently running. Reading those two patches 
also looks good.


Thanks a lot.

Alexander Holler

--
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] X.509: Fix the time validation [ver #3]

2015-12-10 Thread Alexander Holler 

Am 10.12.2015 um 16:34 schrieb Alexander Holler:

Am 10.12.2015 um 16:26 schrieb Greg Kroah-Hartman:

On Thu, Dec 10, 2015 at 04:15:22PM +0100, Alexander Holler wrote:



Just in case of, I would suggest to quickly push out 4.3.2 (only 4.3
seems
to be affected) which contains at least the patch mentioned in the
subject
(58585c1fc301a36625db41ac7078c4dd0a218d84 in mainline).


58585c1fc301a36625db41ac7078c4dd0a218d84 doesn't reference anything in
Linus's tree, where did you get that git commit id?


Uh, hmm, maybe I've picked the wrong commit number when I've used git
gui blame to find the original commit. Might have been one from my own
trees which are based on mainline. Sorry, having had a second look, the
one I've cherry-picked from mainline was
cc25b994acfbc901429da682d0f73c190e960206


To give my motivation for that mail (and that "quickly"): it's highly 
annoying to end up with a box which does not have network and, as in my 
case, even without working input devices because modules weren't loaded. 
And other people don't might be able to find the problem (and existing 
patch) as quick as I did and might end up even more annoyed than I was 
for a short period of time. ;)



Regards,

Alexander Holler


--
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 0/2] crypto: KEYS: convert public key to akcipher api

2015-12-10 Thread Tadeusz Struk 
Hi Mimi,
On 12/10/2015 10:25 AM, Mimi Zohar wrote:
>> This patch set converts the module verification and digital signature
>> > code to the new akcipher API.
>> > RSA implementation has been removed from crypto/asymmetric_keys and the
>> > new API is used for cryptographic primitives.
>> > There is no need for MPI above the akcipher API anymore.
>> > Modules can be verified with software as well as HW RSA implementations.
> With these two patches my system doesn't even boot.  Digging deeper...
> 

It needs RSA implementation built-in.
Could you check if you have CONFIG_CRYPTO_RSA=y
Thanks

-- 
TS
--
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] X.509: Fix leap year handling again and support leap seconds

2015-12-10 Thread David Howells 
Rudolf Polzer  wrote:

> Also, while at it - apparently hour 24 is allowed by ISO 8601 too as long as
> minutes and seconds are zero, leading to even more non-canonicality... can
> you check whether this is also valid ASN.1 then?

Sorry, I missed this bit.  The ASN.1 spec says that GeneralizedTime is ISO
8601 format.

> > It's not entirely clear that ASN.1 expects it, but we can relax the
> > seconds check slightly for GeneralizedTime.

What I'm not sure of is whether other ASN.1 implementations will expect it.

David
--
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 0/2] security: clarify that some code is really non-modular

2015-12-10 Thread David Howells 
Paul Gortmaker  wrote:

> Paul Gortmaker (2):
>   security/keys: make big_key.c explicitly non-modular
>   security/integrity: make ima/ima_mok.c explicitly non-modular

Note that I only see patch 1.  Note also that keyri...@linux-nfs.org should
now be keyri...@vger.kernel.org.

David
--
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] X.509: Fix the time validation [ver #3]

2015-12-10 Thread Alexander Holler 

Am 10.12.2015 um 16:26 schrieb Greg Kroah-Hartman:

On Thu, Dec 10, 2015 at 04:15:22PM +0100, Alexander Holler wrote:



Just in case of, I would suggest to quickly push out 4.3.2 (only 4.3 seems
to be affected) which contains at least the patch mentioned in the subject
(58585c1fc301a36625db41ac7078c4dd0a218d84 in mainline).


58585c1fc301a36625db41ac7078c4dd0a218d84 doesn't reference anything in
Linus's tree, where did you get that git commit id?


Uh, hmm, maybe I've picked the wrong commit number when I've used git 
gui blame to find the original commit. Might have been one from my own 
trees which are based on mainline. Sorry, having had a second look, the 
one I've cherry-picked from mainline was 
cc25b994acfbc901429da682d0f73c190e960206


Regards,

Alexander Holler
--
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] X.509: Fix the time validation [ver #3]

2015-12-10 Thread Alexander Holler 

Am 10.12.2015 um 10:23 schrieb Alexander Holler:

Am 12.11.2015 um 12:38 schrieb David Howells:

This fixes CVE-2015-5327.  It affects kernels from 4.3-rc1 onwards.

Fix the X.509 time validation to use month number-1 when looking up the
number of days in that month.  Also put the month number validation
before
doing the lookup so as not to risk overrunning the array.


I've just run into this with 4.3.1 (mon_len ended up with 0 because of
the wrong index). Which means currently build stable kernels with
signature verification might not load modules (depending on which value
the invalid index mon_len (12) ends up with.


Just in case of, I would suggest to quickly push out 4.3.2 (only 4.3 
seems to be affected) which contains at least the patch mentioned in the 
subject (58585c1fc301a36625db41ac7078c4dd0a218d84 in mainline).


Regards,

Alexander Holler
--
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] X.509: Fix the time validation [ver #3]

2015-12-10 Thread Greg Kroah-Hartman 
On Thu, Dec 10, 2015 at 04:15:22PM +0100, Alexander Holler wrote:
> Am 10.12.2015 um 10:23 schrieb Alexander Holler:
> >Am 12.11.2015 um 12:38 schrieb David Howells:
> >>This fixes CVE-2015-5327.  It affects kernels from 4.3-rc1 onwards.
> >>
> >>Fix the X.509 time validation to use month number-1 when looking up the
> >>number of days in that month.  Also put the month number validation
> >>before
> >>doing the lookup so as not to risk overrunning the array.
> >
> >I've just run into this with 4.3.1 (mon_len ended up with 0 because of
> >the wrong index). Which means currently build stable kernels with
> >signature verification might not load modules (depending on which value
> >the invalid index mon_len (12) ends up with.
> 
> Just in case of, I would suggest to quickly push out 4.3.2 (only 4.3 seems
> to be affected) which contains at least the patch mentioned in the subject
> (58585c1fc301a36625db41ac7078c4dd0a218d84 in mainline).

58585c1fc301a36625db41ac7078c4dd0a218d84 doesn't reference anything in
Linus's tree, where did you get that git commit id?

David, any reason you didn't put a cc: stable in the commit for it to be
picked up in the stable releases?

thanks,

greg k-h

--
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