* [meta-security][PATCH] libcap-ng: port CVE-2014-3215 patch
@ 2014-11-27 18:49 Joe MacDonald
2014-11-27 22:03 ` akuster808
2014-11-30 4:51 ` akuster808
0 siblings, 2 replies; 6+ messages in thread
From: Joe MacDonald @ 2014-11-27 18:49 UTC (permalink / raw)
To: yocto
Importing the patch from meta-selinux, which itself was a backport from
the upstream source tree.
Signed-off-by: Joe MacDonald <joe_macdonald@mentor.com>
---
I mentioned a while back that I had at least one patch in meta-selinux that may
apply to meta-security as well. I don't know if you guys are interested in this
or not since the primary tool to demonstrate the exploit is seunshare, but it is
a problem in libcap-ng itself and it is exploitable outside of the selinux
framework.
-J.
.../libcap-ng/libcap-ng/CVE-2014-3215.patch | 91 ++++++++++++++++++++++
recipes-security/libcap-ng/libcap-ng_0.7.3.bb | 4 +-
2 files changed, 94 insertions(+), 1 deletion(-)
create mode 100644 recipes-security/libcap-ng/libcap-ng/CVE-2014-3215.patch
diff --git a/recipes-security/libcap-ng/libcap-ng/CVE-2014-3215.patch b/recipes-security/libcap-ng/libcap-ng/CVE-2014-3215.patch
new file mode 100644
index 0000000..e9164d4
--- /dev/null
+++ b/recipes-security/libcap-ng/libcap-ng/CVE-2014-3215.patch
@@ -0,0 +1,91 @@
+libcap-ng: local privilege escalation due to capng_lock
+
+Following the discussion here:
+
+ http://openwall.com/lists/oss-security/2014/04/29/7
+
+This is known to impact SELinux tools, however the issue could be exploited by
+any application using the relevant functions in libcap-ng provided it is suid
+root.
+
+Upstream-Status: Backport
+
+Signed-off-by: Joe MacDonald <joe_macdonald@mentor.com>
+
+diff --git a/docs/capng_lock.3 b/docs/capng_lock.3
+index 7683119..a070c1e 100644
+--- a/docs/capng_lock.3
++++ b/docs/capng_lock.3
+@@ -8,12 +8,13 @@ int capng_lock(void);
+
+ .SH "DESCRIPTION"
+
+-capng_lock will take steps to prevent children of the current process to regain full privileges if the uid is 0. This should be called while possessing the CAP_SETPCAP capability in the kernel. This function will do the following if permitted by the kernel: Set the NOROOT option on for PR_SET_SECUREBITS, set the NOROOT_LOCKED option to on for PR_SET_SECUREBITS, set the PR_NO_SETUID_FIXUP option on for PR_SET_SECUREBITS, and set the PR_NO_SETUID_FIXUP_LOCKED option on for PR_SET_SECUREBITS.
++capng_lock will take steps to prevent children of the current process from gaining privileges by executing setuid programs. This should be called while possessing the CAP_SETPCAP capability in the kernel.
+
++This function will do the following if permitted by the kernel: If the kernel supports PR_SET_NO_NEW_PRIVS, it will use it. Otherwise it will set the NOROOT option on for PR_SET_SECUREBITS, set the NOROOT_LOCKED option to on for PR_SET_SECUREBITS, set the PR_NO_SETUID_FIXUP option on for PR_SET_SECUREBITS, and set the PR_NO_SETUID_FIXUP_LOCKED option on for PR_SET_SECUREBITS. If both fail, it will return an error.
+
+ .SH "RETURN VALUE"
+
+-This returns 0 on success and a negative number on failure. -1 means a failure setting any of the PR_SET_SECUREBITS options.
++This returns 0 on success and a negative number on failure. -1 means a failure to use PR_SET_NO_NEW_PRIVS and a failure setting any of the PR_SET_SECUREBITS options.
+
+ .SH "SEE ALSO"
+
+diff --git a/src/cap-ng.c b/src/cap-ng.c
+index bd105ba..422f2bc 100644
+--- a/src/cap-ng.c
++++ b/src/cap-ng.c
+@@ -45,6 +45,7 @@
+ * 2.6.24 kernel XATTR_NAME_CAPS
+ * 2.6.25 kernel PR_CAPBSET_DROP, CAPABILITY_VERSION_2
+ * 2.6.26 kernel PR_SET_SECUREBITS, SECURE_*_LOCKED, VERSION_3
++ * 3.5 kernel PR_SET_NO_NEW_PRIVS
+ */
+
+ /* External syscall prototypes */
+@@ -122,6 +123,14 @@ extern int capget(cap_user_header_t header, const cap_user_data_t data);
+ #define SECURE_NO_SETUID_FIXUP_LOCKED 3 /* make bit-2 immutable */
+ #endif
+
++/* prctl values that we use */
++#ifndef PR_SET_SECUREBITS
++#define PR_SET_SECUREBITS 28
++#endif
++#ifndef PR_SET_NO_NEW_PRIVS
++#define PR_SET_NO_NEW_PRIVS 38
++#endif
++
+ // States: new, allocated, initted, updated, applied
+ typedef enum { CAPNG_NEW, CAPNG_ERROR, CAPNG_ALLOCATED, CAPNG_INIT,
+ CAPNG_UPDATED, CAPNG_APPLIED } capng_states_t;
+@@ -663,15 +672,22 @@ int capng_change_id(int uid, int gid, capng_flags_t flag)
+
+ int capng_lock(void)
+ {
+-#ifdef PR_SET_SECUREBITS
+- int rc = prctl(PR_SET_SECUREBITS,
+- 1 << SECURE_NOROOT |
+- 1 << SECURE_NOROOT_LOCKED |
+- 1 << SECURE_NO_SETUID_FIXUP |
+- 1 << SECURE_NO_SETUID_FIXUP_LOCKED, 0, 0, 0);
++ int rc;
++
++ // On Linux 3.5 and up, we can directly prevent ourselves and
++ // our descendents from gaining privileges.
++ if (prctl(PR_SET_NO_NEW_PRIVS, 1, 0, 0, 0) == 0)
++ return 0;
++
++ // This kernel is too old or otherwise doesn't support
++ // PR_SET_NO_NEW_PRIVS. Fall back to using securebits.
++ rc = prctl(PR_SET_SECUREBITS,
++ 1 << SECURE_NOROOT |
++ 1 << SECURE_NOROOT_LOCKED |
++ 1 << SECURE_NO_SETUID_FIXUP |
++ 1 << SECURE_NO_SETUID_FIXUP_LOCKED, 0, 0, 0);
+ if (rc)
+ return -1;
+-#endif
+
+ return 0;
+ }
diff --git a/recipes-security/libcap-ng/libcap-ng_0.7.3.bb b/recipes-security/libcap-ng/libcap-ng_0.7.3.bb
index 3f225ba..1acf554 100644
--- a/recipes-security/libcap-ng/libcap-ng_0.7.3.bb
+++ b/recipes-security/libcap-ng/libcap-ng_0.7.3.bb
@@ -8,7 +8,9 @@ LIC_FILES_CHKSUM = "file://COPYING;md5=94d55d512a9ba36caa9b7df079bae19f \
file://COPYING.LIB;md5=e3eda01d9815f8d24aae2dbd89b68b06"
SRC_URI = "http://people.redhat.com/sgrubb/libcap-ng/libcap-ng-${PV}.tar.gz \
- file://python.patch"
+ file://python.patch \
+ file://CVE-2014-3215.patch \
+ "
inherit lib_package autotools pythonnative
--
1.9.1
^ permalink raw reply related [flat|nested] 6+ messages in thread
* Re: [meta-security][PATCH] libcap-ng: port CVE-2014-3215 patch
2014-11-27 18:49 [meta-security][PATCH] libcap-ng: port CVE-2014-3215 patch Joe MacDonald
@ 2014-11-27 22:03 ` akuster808
2014-11-30 4:51 ` akuster808
1 sibling, 0 replies; 6+ messages in thread
From: akuster808 @ 2014-11-27 22:03 UTC (permalink / raw)
To: Joe MacDonald, yocto
Thanks.
Armin
On 11/27/2014 10:49 AM, Joe MacDonald wrote:
> Importing the patch from meta-selinux, which itself was a backport from
> the upstream source tree.
>
> Signed-off-by: Joe MacDonald <joe_macdonald@mentor.com>
> ---
>
> I mentioned a while back that I had at least one patch in meta-selinux that may
> apply to meta-security as well. I don't know if you guys are interested in this
> or not since the primary tool to demonstrate the exploit is seunshare, but it is
> a problem in libcap-ng itself and it is exploitable outside of the selinux
> framework.
>
> -J.
>
> .../libcap-ng/libcap-ng/CVE-2014-3215.patch | 91 ++++++++++++++++++++++
> recipes-security/libcap-ng/libcap-ng_0.7.3.bb | 4 +-
> 2 files changed, 94 insertions(+), 1 deletion(-)
> create mode 100644 recipes-security/libcap-ng/libcap-ng/CVE-2014-3215.patch
>
> diff --git a/recipes-security/libcap-ng/libcap-ng/CVE-2014-3215.patch b/recipes-security/libcap-ng/libcap-ng/CVE-2014-3215.patch
> new file mode 100644
> index 0000000..e9164d4
> --- /dev/null
> +++ b/recipes-security/libcap-ng/libcap-ng/CVE-2014-3215.patch
> @@ -0,0 +1,91 @@
> +libcap-ng: local privilege escalation due to capng_lock
> +
> +Following the discussion here:
> +
> + http://openwall.com/lists/oss-security/2014/04/29/7
> +
> +This is known to impact SELinux tools, however the issue could be exploited by
> +any application using the relevant functions in libcap-ng provided it is suid
> +root.
> +
> +Upstream-Status: Backport
> +
> +Signed-off-by: Joe MacDonald <joe_macdonald@mentor.com>
> +
> +diff --git a/docs/capng_lock.3 b/docs/capng_lock.3
> +index 7683119..a070c1e 100644
> +--- a/docs/capng_lock.3
> ++++ b/docs/capng_lock.3
> +@@ -8,12 +8,13 @@ int capng_lock(void);
> +
> + .SH "DESCRIPTION"
> +
> +-capng_lock will take steps to prevent children of the current process to regain full privileges if the uid is 0. This should be called while possessing the CAP_SETPCAP capability in the kernel. This function will do the following if permitted by the kernel: Set the NOROOT option on for PR_SET_SECUREBITS, set the NOROOT_LOCKED option to on for PR_SET_SECUREBITS, set the PR_NO_SETUID_FIXUP option on for PR_SET_SECUREBITS, and set the PR_NO_SETUID_FIXUP_LOCKED option on for PR_SET_SECUREBITS.
> ++capng_lock will take steps to prevent children of the current process from gaining privileges by executing setuid programs. This should be called while possessing the CAP_SETPCAP capability in the kernel.
> +
> ++This function will do the following if permitted by the kernel: If the kernel supports PR_SET_NO_NEW_PRIVS, it will use it. Otherwise it will set the NOROOT option on for PR_SET_SECUREBITS, set the NOROOT_LOCKED option to on for PR_SET_SECUREBITS, set the PR_NO_SETUID_FIXUP option on for PR_SET_SECUREBITS, and set the PR_NO_SETUID_FIXUP_LOCKED option on for PR_SET_SECUREBITS. If both fail, it will return an error.
> +
> + .SH "RETURN VALUE"
> +
> +-This returns 0 on success and a negative number on failure. -1 means a failure setting any of the PR_SET_SECUREBITS options.
> ++This returns 0 on success and a negative number on failure. -1 means a failure to use PR_SET_NO_NEW_PRIVS and a failure setting any of the PR_SET_SECUREBITS options.
> +
> + .SH "SEE ALSO"
> +
> +diff --git a/src/cap-ng.c b/src/cap-ng.c
> +index bd105ba..422f2bc 100644
> +--- a/src/cap-ng.c
> ++++ b/src/cap-ng.c
> +@@ -45,6 +45,7 @@
> + * 2.6.24 kernel XATTR_NAME_CAPS
> + * 2.6.25 kernel PR_CAPBSET_DROP, CAPABILITY_VERSION_2
> + * 2.6.26 kernel PR_SET_SECUREBITS, SECURE_*_LOCKED, VERSION_3
> ++ * 3.5 kernel PR_SET_NO_NEW_PRIVS
> + */
> +
> + /* External syscall prototypes */
> +@@ -122,6 +123,14 @@ extern int capget(cap_user_header_t header, const cap_user_data_t data);
> + #define SECURE_NO_SETUID_FIXUP_LOCKED 3 /* make bit-2 immutable */
> + #endif
> +
> ++/* prctl values that we use */
> ++#ifndef PR_SET_SECUREBITS
> ++#define PR_SET_SECUREBITS 28
> ++#endif
> ++#ifndef PR_SET_NO_NEW_PRIVS
> ++#define PR_SET_NO_NEW_PRIVS 38
> ++#endif
> ++
> + // States: new, allocated, initted, updated, applied
> + typedef enum { CAPNG_NEW, CAPNG_ERROR, CAPNG_ALLOCATED, CAPNG_INIT,
> + CAPNG_UPDATED, CAPNG_APPLIED } capng_states_t;
> +@@ -663,15 +672,22 @@ int capng_change_id(int uid, int gid, capng_flags_t flag)
> +
> + int capng_lock(void)
> + {
> +-#ifdef PR_SET_SECUREBITS
> +- int rc = prctl(PR_SET_SECUREBITS,
> +- 1 << SECURE_NOROOT |
> +- 1 << SECURE_NOROOT_LOCKED |
> +- 1 << SECURE_NO_SETUID_FIXUP |
> +- 1 << SECURE_NO_SETUID_FIXUP_LOCKED, 0, 0, 0);
> ++ int rc;
> ++
> ++ // On Linux 3.5 and up, we can directly prevent ourselves and
> ++ // our descendents from gaining privileges.
> ++ if (prctl(PR_SET_NO_NEW_PRIVS, 1, 0, 0, 0) == 0)
> ++ return 0;
> ++
> ++ // This kernel is too old or otherwise doesn't support
> ++ // PR_SET_NO_NEW_PRIVS. Fall back to using securebits.
> ++ rc = prctl(PR_SET_SECUREBITS,
> ++ 1 << SECURE_NOROOT |
> ++ 1 << SECURE_NOROOT_LOCKED |
> ++ 1 << SECURE_NO_SETUID_FIXUP |
> ++ 1 << SECURE_NO_SETUID_FIXUP_LOCKED, 0, 0, 0);
> + if (rc)
> + return -1;
> +-#endif
> +
> + return 0;
> + }
> diff --git a/recipes-security/libcap-ng/libcap-ng_0.7.3.bb b/recipes-security/libcap-ng/libcap-ng_0.7.3.bb
> index 3f225ba..1acf554 100644
> --- a/recipes-security/libcap-ng/libcap-ng_0.7.3.bb
> +++ b/recipes-security/libcap-ng/libcap-ng_0.7.3.bb
> @@ -8,7 +8,9 @@ LIC_FILES_CHKSUM = "file://COPYING;md5=94d55d512a9ba36caa9b7df079bae19f \
> file://COPYING.LIB;md5=e3eda01d9815f8d24aae2dbd89b68b06"
>
> SRC_URI = "http://people.redhat.com/sgrubb/libcap-ng/libcap-ng-${PV}.tar.gz \
> - file://python.patch"
> + file://python.patch \
> + file://CVE-2014-3215.patch \
> + "
>
> inherit lib_package autotools pythonnative
>
>
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [meta-security][PATCH] libcap-ng: port CVE-2014-3215 patch
2014-11-27 18:49 [meta-security][PATCH] libcap-ng: port CVE-2014-3215 patch Joe MacDonald
2014-11-27 22:03 ` akuster808
@ 2014-11-30 4:51 ` akuster808
2014-11-30 19:45 ` Joe MacDonald
1 sibling, 1 reply; 6+ messages in thread
From: akuster808 @ 2014-11-30 4:51 UTC (permalink / raw)
To: Joe MacDonald; +Cc: yocto
Joe,
I went a head and updated to 7.4 which included the security fix. Thanks
for the reminder.
- Armin
On 11/27/2014 10:49 AM, Joe MacDonald wrote:
> Importing the patch from meta-selinux, which itself was a backport from
> the upstream source tree.
>
> Signed-off-by: Joe MacDonald <joe_macdonald@mentor.com>
> ---
>
> I mentioned a while back that I had at least one patch in meta-selinux that may
> apply to meta-security as well. I don't know if you guys are interested in this
> or not since the primary tool to demonstrate the exploit is seunshare, but it is
> a problem in libcap-ng itself and it is exploitable outside of the selinux
> framework.
>
> -J.
>
> .../libcap-ng/libcap-ng/CVE-2014-3215.patch | 91 ++++++++++++++++++++++
> recipes-security/libcap-ng/libcap-ng_0.7.3.bb | 4 +-
> 2 files changed, 94 insertions(+), 1 deletion(-)
> create mode 100644 recipes-security/libcap-ng/libcap-ng/CVE-2014-3215.patch
>
> diff --git a/recipes-security/libcap-ng/libcap-ng/CVE-2014-3215.patch b/recipes-security/libcap-ng/libcap-ng/CVE-2014-3215.patch
> new file mode 100644
> index 0000000..e9164d4
> --- /dev/null
> +++ b/recipes-security/libcap-ng/libcap-ng/CVE-2014-3215.patch
> @@ -0,0 +1,91 @@
> +libcap-ng: local privilege escalation due to capng_lock
> +
> +Following the discussion here:
> +
> + http://openwall.com/lists/oss-security/2014/04/29/7
> +
> +This is known to impact SELinux tools, however the issue could be exploited by
> +any application using the relevant functions in libcap-ng provided it is suid
> +root.
> +
> +Upstream-Status: Backport
> +
> +Signed-off-by: Joe MacDonald <joe_macdonald@mentor.com>
> +
> +diff --git a/docs/capng_lock.3 b/docs/capng_lock.3
> +index 7683119..a070c1e 100644
> +--- a/docs/capng_lock.3
> ++++ b/docs/capng_lock.3
> +@@ -8,12 +8,13 @@ int capng_lock(void);
> +
> + .SH "DESCRIPTION"
> +
> +-capng_lock will take steps to prevent children of the current process to regain full privileges if the uid is 0. This should be called while possessing the CAP_SETPCAP capability in the kernel. This function will do the following if permitted by the kernel: Set the NOROOT option on for PR_SET_SECUREBITS, set the NOROOT_LOCKED option to on for PR_SET_SECUREBITS, set the PR_NO_SETUID_FIXUP option on for PR_SET_SECUREBITS, and set the PR_NO_SETUID_FIXUP_LOCKED option on for PR_SET_SECUREBITS.
> ++capng_lock will take steps to prevent children of the current process from gaining privileges by executing setuid programs. This should be called while possessing the CAP_SETPCAP capability in the kernel.
> +
> ++This function will do the following if permitted by the kernel: If the kernel supports PR_SET_NO_NEW_PRIVS, it will use it. Otherwise it will set the NOROOT option on for PR_SET_SECUREBITS, set the NOROOT_LOCKED option to on for PR_SET_SECUREBITS, set the PR_NO_SETUID_FIXUP option on for PR_SET_SECUREBITS, and set the PR_NO_SETUID_FIXUP_LOCKED option on for PR_SET_SECUREBITS. If both fail, it will return an error.
> +
> + .SH "RETURN VALUE"
> +
> +-This returns 0 on success and a negative number on failure. -1 means a failure setting any of the PR_SET_SECUREBITS options.
> ++This returns 0 on success and a negative number on failure. -1 means a failure to use PR_SET_NO_NEW_PRIVS and a failure setting any of the PR_SET_SECUREBITS options.
> +
> + .SH "SEE ALSO"
> +
> +diff --git a/src/cap-ng.c b/src/cap-ng.c
> +index bd105ba..422f2bc 100644
> +--- a/src/cap-ng.c
> ++++ b/src/cap-ng.c
> +@@ -45,6 +45,7 @@
> + * 2.6.24 kernel XATTR_NAME_CAPS
> + * 2.6.25 kernel PR_CAPBSET_DROP, CAPABILITY_VERSION_2
> + * 2.6.26 kernel PR_SET_SECUREBITS, SECURE_*_LOCKED, VERSION_3
> ++ * 3.5 kernel PR_SET_NO_NEW_PRIVS
> + */
> +
> + /* External syscall prototypes */
> +@@ -122,6 +123,14 @@ extern int capget(cap_user_header_t header, const cap_user_data_t data);
> + #define SECURE_NO_SETUID_FIXUP_LOCKED 3 /* make bit-2 immutable */
> + #endif
> +
> ++/* prctl values that we use */
> ++#ifndef PR_SET_SECUREBITS
> ++#define PR_SET_SECUREBITS 28
> ++#endif
> ++#ifndef PR_SET_NO_NEW_PRIVS
> ++#define PR_SET_NO_NEW_PRIVS 38
> ++#endif
> ++
> + // States: new, allocated, initted, updated, applied
> + typedef enum { CAPNG_NEW, CAPNG_ERROR, CAPNG_ALLOCATED, CAPNG_INIT,
> + CAPNG_UPDATED, CAPNG_APPLIED } capng_states_t;
> +@@ -663,15 +672,22 @@ int capng_change_id(int uid, int gid, capng_flags_t flag)
> +
> + int capng_lock(void)
> + {
> +-#ifdef PR_SET_SECUREBITS
> +- int rc = prctl(PR_SET_SECUREBITS,
> +- 1 << SECURE_NOROOT |
> +- 1 << SECURE_NOROOT_LOCKED |
> +- 1 << SECURE_NO_SETUID_FIXUP |
> +- 1 << SECURE_NO_SETUID_FIXUP_LOCKED, 0, 0, 0);
> ++ int rc;
> ++
> ++ // On Linux 3.5 and up, we can directly prevent ourselves and
> ++ // our descendents from gaining privileges.
> ++ if (prctl(PR_SET_NO_NEW_PRIVS, 1, 0, 0, 0) == 0)
> ++ return 0;
> ++
> ++ // This kernel is too old or otherwise doesn't support
> ++ // PR_SET_NO_NEW_PRIVS. Fall back to using securebits.
> ++ rc = prctl(PR_SET_SECUREBITS,
> ++ 1 << SECURE_NOROOT |
> ++ 1 << SECURE_NOROOT_LOCKED |
> ++ 1 << SECURE_NO_SETUID_FIXUP |
> ++ 1 << SECURE_NO_SETUID_FIXUP_LOCKED, 0, 0, 0);
> + if (rc)
> + return -1;
> +-#endif
> +
> + return 0;
> + }
> diff --git a/recipes-security/libcap-ng/libcap-ng_0.7.3.bb b/recipes-security/libcap-ng/libcap-ng_0.7.3.bb
> index 3f225ba..1acf554 100644
> --- a/recipes-security/libcap-ng/libcap-ng_0.7.3.bb
> +++ b/recipes-security/libcap-ng/libcap-ng_0.7.3.bb
> @@ -8,7 +8,9 @@ LIC_FILES_CHKSUM = "file://COPYING;md5=94d55d512a9ba36caa9b7df079bae19f \
> file://COPYING.LIB;md5=e3eda01d9815f8d24aae2dbd89b68b06"
>
> SRC_URI = "http://people.redhat.com/sgrubb/libcap-ng/libcap-ng-${PV}.tar.gz \
> - file://python.patch"
> + file://python.patch \
> + file://CVE-2014-3215.patch \
> + "
>
> inherit lib_package autotools pythonnative
>
>
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [meta-security][PATCH] libcap-ng: port CVE-2014-3215 patch
2014-11-30 4:51 ` akuster808
@ 2014-11-30 19:45 ` Joe MacDonald
2014-11-30 21:21 ` akuster808
0 siblings, 1 reply; 6+ messages in thread
From: Joe MacDonald @ 2014-11-30 19:45 UTC (permalink / raw)
To: akuster808; +Cc: yocto
[-- Attachment #1: Type: text/plain, Size: 6472 bytes --]
[Re: [yocto] [meta-security][PATCH] libcap-ng: port CVE-2014-3215 patch] On 14.11.29 (Sat 20:51) akuster808 wrote:
> Joe,
>
> I went a head and updated to 7.4 which included the security fix.
> Thanks for the reminder.
Yeah, that's on my to-do list for meta-selinux, too. That's the right
course of action on this one. :-)
-J.
>
> - Armin
>
> On 11/27/2014 10:49 AM, Joe MacDonald wrote:
> >Importing the patch from meta-selinux, which itself was a backport from
> >the upstream source tree.
> >
> >Signed-off-by: Joe MacDonald <joe_macdonald@mentor.com>
> >---
> >
> >I mentioned a while back that I had at least one patch in meta-selinux that may
> >apply to meta-security as well. I don't know if you guys are interested in this
> >or not since the primary tool to demonstrate the exploit is seunshare, but it is
> >a problem in libcap-ng itself and it is exploitable outside of the selinux
> >framework.
> >
> >-J.
> >
> > .../libcap-ng/libcap-ng/CVE-2014-3215.patch | 91 ++++++++++++++++++++++
> > recipes-security/libcap-ng/libcap-ng_0.7.3.bb | 4 +-
> > 2 files changed, 94 insertions(+), 1 deletion(-)
> > create mode 100644 recipes-security/libcap-ng/libcap-ng/CVE-2014-3215.patch
> >
> >diff --git a/recipes-security/libcap-ng/libcap-ng/CVE-2014-3215.patch b/recipes-security/libcap-ng/libcap-ng/CVE-2014-3215.patch
> >new file mode 100644
> >index 0000000..e9164d4
> >--- /dev/null
> >+++ b/recipes-security/libcap-ng/libcap-ng/CVE-2014-3215.patch
> >@@ -0,0 +1,91 @@
> >+libcap-ng: local privilege escalation due to capng_lock
> >+
> >+Following the discussion here:
> >+
> >+ http://openwall.com/lists/oss-security/2014/04/29/7
> >+
> >+This is known to impact SELinux tools, however the issue could be exploited by
> >+any application using the relevant functions in libcap-ng provided it is suid
> >+root.
> >+
> >+Upstream-Status: Backport
> >+
> >+Signed-off-by: Joe MacDonald <joe_macdonald@mentor.com>
> >+
> >+diff --git a/docs/capng_lock.3 b/docs/capng_lock.3
> >+index 7683119..a070c1e 100644
> >+--- a/docs/capng_lock.3
> >++++ b/docs/capng_lock.3
> >+@@ -8,12 +8,13 @@ int capng_lock(void);
> >+
> >+ .SH "DESCRIPTION"
> >+
> >+-capng_lock will take steps to prevent children of the current process to regain full privileges if the uid is 0. This should be called while possessing the CAP_SETPCAP capability in the kernel. This function will do the following if permitted by the kernel: Set the NOROOT option on for PR_SET_SECUREBITS, set the NOROOT_LOCKED option to on for PR_SET_SECUREBITS, set the PR_NO_SETUID_FIXUP option on for PR_SET_SECUREBITS, and set the PR_NO_SETUID_FIXUP_LOCKED option on for PR_SET_SECUREBITS.
> >++capng_lock will take steps to prevent children of the current process from gaining privileges by executing setuid programs. This should be called while possessing the CAP_SETPCAP capability in the kernel.
> >+
> >++This function will do the following if permitted by the kernel: If the kernel supports PR_SET_NO_NEW_PRIVS, it will use it. Otherwise it will set the NOROOT option on for PR_SET_SECUREBITS, set the NOROOT_LOCKED option to on for PR_SET_SECUREBITS, set the PR_NO_SETUID_FIXUP option on for PR_SET_SECUREBITS, and set the PR_NO_SETUID_FIXUP_LOCKED option on for PR_SET_SECUREBITS. If both fail, it will return an error.
> >+
> >+ .SH "RETURN VALUE"
> >+
> >+-This returns 0 on success and a negative number on failure. -1 means a failure setting any of the PR_SET_SECUREBITS options.
> >++This returns 0 on success and a negative number on failure. -1 means a failure to use PR_SET_NO_NEW_PRIVS and a failure setting any of the PR_SET_SECUREBITS options.
> >+
> >+ .SH "SEE ALSO"
> >+
> >+diff --git a/src/cap-ng.c b/src/cap-ng.c
> >+index bd105ba..422f2bc 100644
> >+--- a/src/cap-ng.c
> >++++ b/src/cap-ng.c
> >+@@ -45,6 +45,7 @@
> >+ * 2.6.24 kernel XATTR_NAME_CAPS
> >+ * 2.6.25 kernel PR_CAPBSET_DROP, CAPABILITY_VERSION_2
> >+ * 2.6.26 kernel PR_SET_SECUREBITS, SECURE_*_LOCKED, VERSION_3
> >++ * 3.5 kernel PR_SET_NO_NEW_PRIVS
> >+ */
> >+
> >+ /* External syscall prototypes */
> >+@@ -122,6 +123,14 @@ extern int capget(cap_user_header_t header, const cap_user_data_t data);
> >+ #define SECURE_NO_SETUID_FIXUP_LOCKED 3 /* make bit-2 immutable */
> >+ #endif
> >+
> >++/* prctl values that we use */
> >++#ifndef PR_SET_SECUREBITS
> >++#define PR_SET_SECUREBITS 28
> >++#endif
> >++#ifndef PR_SET_NO_NEW_PRIVS
> >++#define PR_SET_NO_NEW_PRIVS 38
> >++#endif
> >++
> >+ // States: new, allocated, initted, updated, applied
> >+ typedef enum { CAPNG_NEW, CAPNG_ERROR, CAPNG_ALLOCATED, CAPNG_INIT,
> >+ CAPNG_UPDATED, CAPNG_APPLIED } capng_states_t;
> >+@@ -663,15 +672,22 @@ int capng_change_id(int uid, int gid, capng_flags_t flag)
> >+
> >+ int capng_lock(void)
> >+ {
> >+-#ifdef PR_SET_SECUREBITS
> >+- int rc = prctl(PR_SET_SECUREBITS,
> >+- 1 << SECURE_NOROOT |
> >+- 1 << SECURE_NOROOT_LOCKED |
> >+- 1 << SECURE_NO_SETUID_FIXUP |
> >+- 1 << SECURE_NO_SETUID_FIXUP_LOCKED, 0, 0, 0);
> >++ int rc;
> >++
> >++ // On Linux 3.5 and up, we can directly prevent ourselves and
> >++ // our descendents from gaining privileges.
> >++ if (prctl(PR_SET_NO_NEW_PRIVS, 1, 0, 0, 0) == 0)
> >++ return 0;
> >++
> >++ // This kernel is too old or otherwise doesn't support
> >++ // PR_SET_NO_NEW_PRIVS. Fall back to using securebits.
> >++ rc = prctl(PR_SET_SECUREBITS,
> >++ 1 << SECURE_NOROOT |
> >++ 1 << SECURE_NOROOT_LOCKED |
> >++ 1 << SECURE_NO_SETUID_FIXUP |
> >++ 1 << SECURE_NO_SETUID_FIXUP_LOCKED, 0, 0, 0);
> >+ if (rc)
> >+ return -1;
> >+-#endif
> >+
> >+ return 0;
> >+ }
> >diff --git a/recipes-security/libcap-ng/libcap-ng_0.7.3.bb b/recipes-security/libcap-ng/libcap-ng_0.7.3.bb
> >index 3f225ba..1acf554 100644
> >--- a/recipes-security/libcap-ng/libcap-ng_0.7.3.bb
> >+++ b/recipes-security/libcap-ng/libcap-ng_0.7.3.bb
> >@@ -8,7 +8,9 @@ LIC_FILES_CHKSUM = "file://COPYING;md5=94d55d512a9ba36caa9b7df079bae19f \
> > file://COPYING.LIB;md5=e3eda01d9815f8d24aae2dbd89b68b06"
> >
> > SRC_URI = "http://people.redhat.com/sgrubb/libcap-ng/libcap-ng-${PV}.tar.gz \
> >- file://python.patch"
> >+ file://python.patch \
> >+ file://CVE-2014-3215.patch \
> >+ "
> >
> > inherit lib_package autotools pythonnative
> >
> >
--
-Joe MacDonald.
:wq
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 501 bytes --]
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [meta-security][PATCH] libcap-ng: port CVE-2014-3215 patch
2014-11-30 19:45 ` Joe MacDonald
@ 2014-11-30 21:21 ` akuster808
2014-12-01 3:21 ` Joe MacDonald
0 siblings, 1 reply; 6+ messages in thread
From: akuster808 @ 2014-11-30 21:21 UTC (permalink / raw)
To: Joe MacDonald; +Cc: yocto
On 11/30/2014 11:45 AM, Joe MacDonald wrote:
> [Re: [yocto] [meta-security][PATCH] libcap-ng: port CVE-2014-3215 patch] On 14.11.29 (Sat 20:51) akuster808 wrote:
>
>> Joe,
>>
>> I went a head and updated to 7.4 which included the security fix.
>> Thanks for the reminder.
>
> Yeah, that's on my to-do list for meta-selinux, too. That's the right
> course of action on this one. :-)
To be honest, this package should be in one in core or meta-openembedded.
- Armin
> -J.
>
>>
>> - Armin
>>
>> On 11/27/2014 10:49 AM, Joe MacDonald wrote:
>>> Importing the patch from meta-selinux, which itself was a backport from
>>> the upstream source tree.
>>>
>>> Signed-off-by: Joe MacDonald <joe_macdonald@mentor.com>
>>> ---
>>>
>>> I mentioned a while back that I had at least one patch in meta-selinux that may
>>> apply to meta-security as well. I don't know if you guys are interested in this
>>> or not since the primary tool to demonstrate the exploit is seunshare, but it is
>>> a problem in libcap-ng itself and it is exploitable outside of the selinux
>>> framework.
>>>
>>> -J.
>>>
>>> .../libcap-ng/libcap-ng/CVE-2014-3215.patch | 91 ++++++++++++++++++++++
>>> recipes-security/libcap-ng/libcap-ng_0.7.3.bb | 4 +-
>>> 2 files changed, 94 insertions(+), 1 deletion(-)
>>> create mode 100644 recipes-security/libcap-ng/libcap-ng/CVE-2014-3215.patch
>>>
>>> diff --git a/recipes-security/libcap-ng/libcap-ng/CVE-2014-3215.patch b/recipes-security/libcap-ng/libcap-ng/CVE-2014-3215.patch
>>> new file mode 100644
>>> index 0000000..e9164d4
>>> --- /dev/null
>>> +++ b/recipes-security/libcap-ng/libcap-ng/CVE-2014-3215.patch
>>> @@ -0,0 +1,91 @@
>>> +libcap-ng: local privilege escalation due to capng_lock
>>> +
>>> +Following the discussion here:
>>> +
>>> + http://openwall.com/lists/oss-security/2014/04/29/7
>>> +
>>> +This is known to impact SELinux tools, however the issue could be exploited by
>>> +any application using the relevant functions in libcap-ng provided it is suid
>>> +root.
>>> +
>>> +Upstream-Status: Backport
>>> +
>>> +Signed-off-by: Joe MacDonald <joe_macdonald@mentor.com>
>>> +
>>> +diff --git a/docs/capng_lock.3 b/docs/capng_lock.3
>>> +index 7683119..a070c1e 100644
>>> +--- a/docs/capng_lock.3
>>> ++++ b/docs/capng_lock.3
>>> +@@ -8,12 +8,13 @@ int capng_lock(void);
>>> +
>>> + .SH "DESCRIPTION"
>>> +
>>> +-capng_lock will take steps to prevent children of the current process to regain full privileges if the uid is 0. This should be called while possessing the CAP_SETPCAP capability in the kernel. This function will do the following if permitted by the kernel: Set the NOROOT option on for PR_SET_SECUREBITS, set the NOROOT_LOCKED option to on for PR_SET_SECUREBITS, set the PR_NO_SETUID_FIXUP option on for PR_SET_SECUREBITS, and set the PR_NO_SETUID_FIXUP_LOCKED option on for PR_SET_SECUREBITS.
>>> ++capng_lock will take steps to prevent children of the current process from gaining privileges by executing setuid programs. This should be called while possessing the CAP_SETPCAP capability in the kernel.
>>> +
>>> ++This function will do the following if permitted by the kernel: If the kernel supports PR_SET_NO_NEW_PRIVS, it will use it. Otherwise it will set the NOROOT option on for PR_SET_SECUREBITS, set the NOROOT_LOCKED option to on for PR_SET_SECUREBITS, set the PR_NO_SETUID_FIXUP option on for PR_SET_SECUREBITS, and set the PR_NO_SETUID_FIXUP_LOCKED option on for PR_SET_SECUREBITS. If both fail, it will return an error.
>>> +
>>> + .SH "RETURN VALUE"
>>> +
>>> +-This returns 0 on success and a negative number on failure. -1 means a failure setting any of the PR_SET_SECUREBITS options.
>>> ++This returns 0 on success and a negative number on failure. -1 means a failure to use PR_SET_NO_NEW_PRIVS and a failure setting any of the PR_SET_SECUREBITS options.
>>> +
>>> + .SH "SEE ALSO"
>>> +
>>> +diff --git a/src/cap-ng.c b/src/cap-ng.c
>>> +index bd105ba..422f2bc 100644
>>> +--- a/src/cap-ng.c
>>> ++++ b/src/cap-ng.c
>>> +@@ -45,6 +45,7 @@
>>> + * 2.6.24 kernel XATTR_NAME_CAPS
>>> + * 2.6.25 kernel PR_CAPBSET_DROP, CAPABILITY_VERSION_2
>>> + * 2.6.26 kernel PR_SET_SECUREBITS, SECURE_*_LOCKED, VERSION_3
>>> ++ * 3.5 kernel PR_SET_NO_NEW_PRIVS
>>> + */
>>> +
>>> + /* External syscall prototypes */
>>> +@@ -122,6 +123,14 @@ extern int capget(cap_user_header_t header, const cap_user_data_t data);
>>> + #define SECURE_NO_SETUID_FIXUP_LOCKED 3 /* make bit-2 immutable */
>>> + #endif
>>> +
>>> ++/* prctl values that we use */
>>> ++#ifndef PR_SET_SECUREBITS
>>> ++#define PR_SET_SECUREBITS 28
>>> ++#endif
>>> ++#ifndef PR_SET_NO_NEW_PRIVS
>>> ++#define PR_SET_NO_NEW_PRIVS 38
>>> ++#endif
>>> ++
>>> + // States: new, allocated, initted, updated, applied
>>> + typedef enum { CAPNG_NEW, CAPNG_ERROR, CAPNG_ALLOCATED, CAPNG_INIT,
>>> + CAPNG_UPDATED, CAPNG_APPLIED } capng_states_t;
>>> +@@ -663,15 +672,22 @@ int capng_change_id(int uid, int gid, capng_flags_t flag)
>>> +
>>> + int capng_lock(void)
>>> + {
>>> +-#ifdef PR_SET_SECUREBITS
>>> +- int rc = prctl(PR_SET_SECUREBITS,
>>> +- 1 << SECURE_NOROOT |
>>> +- 1 << SECURE_NOROOT_LOCKED |
>>> +- 1 << SECURE_NO_SETUID_FIXUP |
>>> +- 1 << SECURE_NO_SETUID_FIXUP_LOCKED, 0, 0, 0);
>>> ++ int rc;
>>> ++
>>> ++ // On Linux 3.5 and up, we can directly prevent ourselves and
>>> ++ // our descendents from gaining privileges.
>>> ++ if (prctl(PR_SET_NO_NEW_PRIVS, 1, 0, 0, 0) == 0)
>>> ++ return 0;
>>> ++
>>> ++ // This kernel is too old or otherwise doesn't support
>>> ++ // PR_SET_NO_NEW_PRIVS. Fall back to using securebits.
>>> ++ rc = prctl(PR_SET_SECUREBITS,
>>> ++ 1 << SECURE_NOROOT |
>>> ++ 1 << SECURE_NOROOT_LOCKED |
>>> ++ 1 << SECURE_NO_SETUID_FIXUP |
>>> ++ 1 << SECURE_NO_SETUID_FIXUP_LOCKED, 0, 0, 0);
>>> + if (rc)
>>> + return -1;
>>> +-#endif
>>> +
>>> + return 0;
>>> + }
>>> diff --git a/recipes-security/libcap-ng/libcap-ng_0.7.3.bb b/recipes-security/libcap-ng/libcap-ng_0.7.3.bb
>>> index 3f225ba..1acf554 100644
>>> --- a/recipes-security/libcap-ng/libcap-ng_0.7.3.bb
>>> +++ b/recipes-security/libcap-ng/libcap-ng_0.7.3.bb
>>> @@ -8,7 +8,9 @@ LIC_FILES_CHKSUM = "file://COPYING;md5=94d55d512a9ba36caa9b7df079bae19f \
>>> file://COPYING.LIB;md5=e3eda01d9815f8d24aae2dbd89b68b06"
>>>
>>> SRC_URI = "http://people.redhat.com/sgrubb/libcap-ng/libcap-ng-${PV}.tar.gz \
>>> - file://python.patch"
>>> + file://python.patch \
>>> + file://CVE-2014-3215.patch \
>>> + "
>>>
>>> inherit lib_package autotools pythonnative
>>>
>>>
>
>
>
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [meta-security][PATCH] libcap-ng: port CVE-2014-3215 patch
2014-11-30 21:21 ` akuster808
@ 2014-12-01 3:21 ` Joe MacDonald
0 siblings, 0 replies; 6+ messages in thread
From: Joe MacDonald @ 2014-12-01 3:21 UTC (permalink / raw)
To: akuster808; +Cc: yocto
[-- Attachment #1: Type: text/plain, Size: 7356 bytes --]
[Re: [yocto] [meta-security][PATCH] libcap-ng: port CVE-2014-3215 patch] On 14.11.30 (Sun 13:21) akuster808 wrote:
>
>
> On 11/30/2014 11:45 AM, Joe MacDonald wrote:
> >[Re: [yocto] [meta-security][PATCH] libcap-ng: port CVE-2014-3215 patch] On 14.11.29 (Sat 20:51) akuster808 wrote:
> >
> >>Joe,
> >>
> >>I went a head and updated to 7.4 which included the security fix.
> >>Thanks for the reminder.
> >
> >Yeah, that's on my to-do list for meta-selinux, too. That's the right
> >course of action on this one. :-)
>
> To be honest, this package should be in one in core or meta-openembedded.
I agree, but I'd like to see it moved to core if anywhere, since
currently meta-selinux still doesn't have any layer dependencies beyond
core. I'm not sure that's viable in the long term, but I think there's
value in making selinux as light as possible for anyone wanting to use
it.
-J.
>
> - Armin
> >-J.
> >
> >>
> >>- Armin
> >>
> >>On 11/27/2014 10:49 AM, Joe MacDonald wrote:
> >>>Importing the patch from meta-selinux, which itself was a backport from
> >>>the upstream source tree.
> >>>
> >>>Signed-off-by: Joe MacDonald <joe_macdonald@mentor.com>
> >>>---
> >>>
> >>>I mentioned a while back that I had at least one patch in meta-selinux that may
> >>>apply to meta-security as well. I don't know if you guys are interested in this
> >>>or not since the primary tool to demonstrate the exploit is seunshare, but it is
> >>>a problem in libcap-ng itself and it is exploitable outside of the selinux
> >>>framework.
> >>>
> >>>-J.
> >>>
> >>> .../libcap-ng/libcap-ng/CVE-2014-3215.patch | 91 ++++++++++++++++++++++
> >>> recipes-security/libcap-ng/libcap-ng_0.7.3.bb | 4 +-
> >>> 2 files changed, 94 insertions(+), 1 deletion(-)
> >>> create mode 100644 recipes-security/libcap-ng/libcap-ng/CVE-2014-3215.patch
> >>>
> >>>diff --git a/recipes-security/libcap-ng/libcap-ng/CVE-2014-3215.patch b/recipes-security/libcap-ng/libcap-ng/CVE-2014-3215.patch
> >>>new file mode 100644
> >>>index 0000000..e9164d4
> >>>--- /dev/null
> >>>+++ b/recipes-security/libcap-ng/libcap-ng/CVE-2014-3215.patch
> >>>@@ -0,0 +1,91 @@
> >>>+libcap-ng: local privilege escalation due to capng_lock
> >>>+
> >>>+Following the discussion here:
> >>>+
> >>>+ http://openwall.com/lists/oss-security/2014/04/29/7
> >>>+
> >>>+This is known to impact SELinux tools, however the issue could be exploited by
> >>>+any application using the relevant functions in libcap-ng provided it is suid
> >>>+root.
> >>>+
> >>>+Upstream-Status: Backport
> >>>+
> >>>+Signed-off-by: Joe MacDonald <joe_macdonald@mentor.com>
> >>>+
> >>>+diff --git a/docs/capng_lock.3 b/docs/capng_lock.3
> >>>+index 7683119..a070c1e 100644
> >>>+--- a/docs/capng_lock.3
> >>>++++ b/docs/capng_lock.3
> >>>+@@ -8,12 +8,13 @@ int capng_lock(void);
> >>>+
> >>>+ .SH "DESCRIPTION"
> >>>+
> >>>+-capng_lock will take steps to prevent children of the current process to regain full privileges if the uid is 0. This should be called while possessing the CAP_SETPCAP capability in the kernel. This function will do the following if permitted by the kernel: Set the NOROOT option on for PR_SET_SECUREBITS, set the NOROOT_LOCKED option to on for PR_SET_SECUREBITS, set the PR_NO_SETUID_FIXUP option on for PR_SET_SECUREBITS, and set the PR_NO_SETUID_FIXUP_LOCKED option on for PR_SET_SECUREBITS.
> >>>++capng_lock will take steps to prevent children of the current process from gaining privileges by executing setuid programs. This should be called while possessing the CAP_SETPCAP capability in the kernel.
> >>>+
> >>>++This function will do the following if permitted by the kernel: If the kernel supports PR_SET_NO_NEW_PRIVS, it will use it. Otherwise it will set the NOROOT option on for PR_SET_SECUREBITS, set the NOROOT_LOCKED option to on for PR_SET_SECUREBITS, set the PR_NO_SETUID_FIXUP option on for PR_SET_SECUREBITS, and set the PR_NO_SETUID_FIXUP_LOCKED option on for PR_SET_SECUREBITS. If both fail, it will return an error.
> >>>+
> >>>+ .SH "RETURN VALUE"
> >>>+
> >>>+-This returns 0 on success and a negative number on failure. -1 means a failure setting any of the PR_SET_SECUREBITS options.
> >>>++This returns 0 on success and a negative number on failure. -1 means a failure to use PR_SET_NO_NEW_PRIVS and a failure setting any of the PR_SET_SECUREBITS options.
> >>>+
> >>>+ .SH "SEE ALSO"
> >>>+
> >>>+diff --git a/src/cap-ng.c b/src/cap-ng.c
> >>>+index bd105ba..422f2bc 100644
> >>>+--- a/src/cap-ng.c
> >>>++++ b/src/cap-ng.c
> >>>+@@ -45,6 +45,7 @@
> >>>+ * 2.6.24 kernel XATTR_NAME_CAPS
> >>>+ * 2.6.25 kernel PR_CAPBSET_DROP, CAPABILITY_VERSION_2
> >>>+ * 2.6.26 kernel PR_SET_SECUREBITS, SECURE_*_LOCKED, VERSION_3
> >>>++ * 3.5 kernel PR_SET_NO_NEW_PRIVS
> >>>+ */
> >>>+
> >>>+ /* External syscall prototypes */
> >>>+@@ -122,6 +123,14 @@ extern int capget(cap_user_header_t header, const cap_user_data_t data);
> >>>+ #define SECURE_NO_SETUID_FIXUP_LOCKED 3 /* make bit-2 immutable */
> >>>+ #endif
> >>>+
> >>>++/* prctl values that we use */
> >>>++#ifndef PR_SET_SECUREBITS
> >>>++#define PR_SET_SECUREBITS 28
> >>>++#endif
> >>>++#ifndef PR_SET_NO_NEW_PRIVS
> >>>++#define PR_SET_NO_NEW_PRIVS 38
> >>>++#endif
> >>>++
> >>>+ // States: new, allocated, initted, updated, applied
> >>>+ typedef enum { CAPNG_NEW, CAPNG_ERROR, CAPNG_ALLOCATED, CAPNG_INIT,
> >>>+ CAPNG_UPDATED, CAPNG_APPLIED } capng_states_t;
> >>>+@@ -663,15 +672,22 @@ int capng_change_id(int uid, int gid, capng_flags_t flag)
> >>>+
> >>>+ int capng_lock(void)
> >>>+ {
> >>>+-#ifdef PR_SET_SECUREBITS
> >>>+- int rc = prctl(PR_SET_SECUREBITS,
> >>>+- 1 << SECURE_NOROOT |
> >>>+- 1 << SECURE_NOROOT_LOCKED |
> >>>+- 1 << SECURE_NO_SETUID_FIXUP |
> >>>+- 1 << SECURE_NO_SETUID_FIXUP_LOCKED, 0, 0, 0);
> >>>++ int rc;
> >>>++
> >>>++ // On Linux 3.5 and up, we can directly prevent ourselves and
> >>>++ // our descendents from gaining privileges.
> >>>++ if (prctl(PR_SET_NO_NEW_PRIVS, 1, 0, 0, 0) == 0)
> >>>++ return 0;
> >>>++
> >>>++ // This kernel is too old or otherwise doesn't support
> >>>++ // PR_SET_NO_NEW_PRIVS. Fall back to using securebits.
> >>>++ rc = prctl(PR_SET_SECUREBITS,
> >>>++ 1 << SECURE_NOROOT |
> >>>++ 1 << SECURE_NOROOT_LOCKED |
> >>>++ 1 << SECURE_NO_SETUID_FIXUP |
> >>>++ 1 << SECURE_NO_SETUID_FIXUP_LOCKED, 0, 0, 0);
> >>>+ if (rc)
> >>>+ return -1;
> >>>+-#endif
> >>>+
> >>>+ return 0;
> >>>+ }
> >>>diff --git a/recipes-security/libcap-ng/libcap-ng_0.7.3.bb b/recipes-security/libcap-ng/libcap-ng_0.7.3.bb
> >>>index 3f225ba..1acf554 100644
> >>>--- a/recipes-security/libcap-ng/libcap-ng_0.7.3.bb
> >>>+++ b/recipes-security/libcap-ng/libcap-ng_0.7.3.bb
> >>>@@ -8,7 +8,9 @@ LIC_FILES_CHKSUM = "file://COPYING;md5=94d55d512a9ba36caa9b7df079bae19f \
> >>> file://COPYING.LIB;md5=e3eda01d9815f8d24aae2dbd89b68b06"
> >>>
> >>> SRC_URI = "http://people.redhat.com/sgrubb/libcap-ng/libcap-ng-${PV}.tar.gz \
> >>>- file://python.patch"
> >>>+ file://python.patch \
> >>>+ file://CVE-2014-3215.patch \
> >>>+ "
> >>>
> >>> inherit lib_package autotools pythonnative
> >>>
> >>>
> >
> >
> >
--
-Joe MacDonald.
:wq
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 501 bytes --]
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2014-12-01 3:21 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2014-11-27 18:49 [meta-security][PATCH] libcap-ng: port CVE-2014-3215 patch Joe MacDonald
2014-11-27 22:03 ` akuster808
2014-11-30 4:51 ` akuster808
2014-11-30 19:45 ` Joe MacDonald
2014-11-30 21:21 ` akuster808
2014-12-01 3:21 ` Joe MacDonald
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.