[yocto] [PATCH] semodule-utils: clear -dev's RDEPENDS

[George McCollister]

Set RDEPENDS_${PN}-dev = "" so ${PN}-dev doesn't RDEPEND on ${PN} (which
isn't created because it contains no files).
This recipe places every file under one of it's sub-packages.

This fixes an error encountered when building an SDK:
 nothing provides semodule-utils = 2.7-r0 needed by
 semodule-utils-dev-2.7-r0.core2-32

Signed-off-by: George McCollister 
---
 recipes-security/selinux/semodule-utils.inc | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/recipes-security/selinux/semodule-utils.inc 
b/recipes-security/selinux/semodule-utils.inc
index 1e92745..2c75c48 100644
--- a/recipes-security/selinux/semodule-utils.inc
+++ b/recipes-security/selinux/semodule-utils.inc
@@ -8,6 +8,8 @@ LICENSE = "GPLv2+"
 
 DEPENDS += "libsepol"
 
+RDEPENDS_${PN}-dev = ""
+
 EXTRA_OEMAKE += "LIBSEPOLA=${STAGING_LIBDIR}/libsepol.a"
 
 PACKAGES =+ "\
-- 
2.11.0

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [meta-selinux][PATCH] semodule-utils: create empty package

[George McCollister]

Allow creation of an empty package since semodule-utils itself doesn't
actually contain any files but is still required by semodule-utils-dev.
This recipe places every file under one of it's sub-packages.

This fixes an error encountered when building an SDK:
 nothing provides semodule-utils = 2.7-r0 needed by
 semodule-utils-dev-2.7-r0.core2-32

Signed-off-by: George McCollister 
---
 recipes-security/selinux/semodule-utils.inc | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/recipes-security/selinux/semodule-utils.inc 
b/recipes-security/selinux/semodule-utils.inc
index 1e92745..114b4b1 100644
--- a/recipes-security/selinux/semodule-utils.inc
+++ b/recipes-security/selinux/semodule-utils.inc
@@ -8,6 +8,8 @@ LICENSE = "GPLv2+"
 
 DEPENDS += "libsepol"
 
+ALLOW_EMPTY_${PN} = "1"
+
 EXTRA_OEMAKE += "LIBSEPOLA=${STAGING_LIBDIR}/libsepol.a"
 
 PACKAGES =+ "\
-- 
2.11.0

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [meta-selinux][master][rocko][PATCH] selinux-image: fix labeling on non-seclabel mounts

[George McCollister]

Use -m to prevent non-seclabel mounts from being excluded from labeling.
After the following commit setfiles will no longer label files on a
mount other than / if it doesn't have seclabel listed in /proc/mounts:
https://github.com/SELinuxProject/selinux/commit/f2e77865e144ab2e1313aa78d99b969f8f48695e#diff-2de9aefdd8fc5bc6a8740533e5d1cc2e

Signed-off-by: George McCollister <george.mccollis...@gmail.com>
---
 classes/selinux-image.bbclass | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/classes/selinux-image.bbclass b/classes/selinux-image.bbclass
index 90ead2f..5174dc5 100644
--- a/classes/selinux-image.bbclass
+++ b/classes/selinux-image.bbclass
@@ -1,6 +1,6 @@
 selinux_set_labels () {
 POL_TYPE=$(sed -n -e 
"s&^SELINUXTYPE[[:space:]]*=[[:space:]]*\([0-9A-Za-z_]\+\)&\1" 
${IMAGE_ROOTFS}/${sysconfdir}/selinux/config)
-if ! setfiles -r ${IMAGE_ROOTFS} 
${IMAGE_ROOTFS}/${sysconfdir}/selinux/${POL_TYPE}/contexts/files/file_contexts 
${IMAGE_ROOTFS}
+if ! setfiles -m -r ${IMAGE_ROOTFS} 
${IMAGE_ROOTFS}/${sysconfdir}/selinux/${POL_TYPE}/contexts/files/file_contexts 
${IMAGE_ROOTFS}
 then
 echo WARNING: Unable to set filesystem context, setfiles / restorecon 
must be run on the live image.
 touch ${IMAGE_ROOTFS}/.autorelabel
-- 
2.16.0

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [meta-selinux] image labeling not working

[George McCollister]

Is anyone else finding that selinux_set_labels no longer sets selinux
labels after everything selinux related was upreved to 2.6 in early
January?

setfiles appears to be excluding everything in the image rootfs directory.

Regards,
George McCollister
Software Architect
NovaTech LLC
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Correct way to use a custom bsp .scc file in morty

[George McCollister]

On Fri, Jan 20, 2017 at 10:59 AM, Bruce Ashfield
<bruce.ashfi...@windriver.com> wrote:
> On 2017-01-20 09:19 AM, George McCollister wrote:
>>
>> On Thu, Jan 19, 2017 at 5:24 PM, Bruce Ashfield
>> <bruce.ashfi...@windriver.com> wrote:
>>>
>>> On 2017-01-19 6:20 PM, George McCollister wrote:
>>>>
>>>>
>>>> What's the correct way to use a custom bsp .scc file located in my
>>>> custom bsp layer? For purposes of this email let's say it's name is
>>>> myplatform-preempt-rt.scc. If I specifically add it to the
>>>> yocto-linux-rt_4.4 SRC_URI it appears to get processed twice by scc
>>>> according to the meta-series output file. It then tries to apply
>>>> patches to standard/preempt-rt/base that don't apply. When building on
>>>> a intel-core2-32 platform, intel-core2-32-preempt-rt.scc only gets
>>>> processed once and no incorrect patches are applied.
>>>
>>>
>>>
>>> Something could have broken, I never rule out bugs!
>>>
>>> Morty had some different semantics than the newer branches (which
>>> are simplified compared to the auto-resume logic in old releases).
>>>
>>> That being said, the capability to have a BSP description in the
>>> SRC_URI is there, and did work during that release cycle. To have
>>> it work, you do need the right format in the BSP .scc file, in
>>> particular something with the KMACHINE and KTYPE descriptions will
>>> be seen as an entry point, and not trigger the re-application of
>>> the inherited patches.
>>>
>>> Is there any way that I can see the contents of that .scc file ?
>>> Otherwise, I can spin up a morty build and mock something up
>>> myself.
>>
>>
>> Bruce,
>>
>> I stripped down my bsp later and pushed it github. You can find the
>> BSP .scc (and the files it includes) here:
>>
>> https://github.com/gmccollister/meta-orion-minimal-bsp/tree/master/recipes-kernel/linux/linux-yocto/orion-io
>>
>> The linux-yocto-rt_4.4.bbappend that adds orion-io-preempt-rt.scc to
>> the SRC_URI is here:
>>
>> https://github.com/gmccollister/meta-orion-minimal-bsp/blob/master/recipes-kernel/linux/linux-yocto-rt_4.4.bbappend
>>
>
> Thanks, this helped .. and did show me the behaviour that you were
> mentioning.
>
> I had to scratch my head for minute, since I tested this scenario
> myself when doing the major re-work in morty for how the kernel
> meta data s processed.
>
> In morty I was able to delete about 40% of all the code and simplified
> the processing. There used to be logic that would process the patch
> series, resume processing, wrap .cfg/.scc files, detect BSP definitions
> and do special processing .. etc, etc. It was a rats nest of corner
> cases.
>
> In morty, if something is on the SRC_URI .. it is applied to the
> tree. No exceptions. Hence why when your BSP definition is on the
> SRC_URI .. it tries to reapply all the patches to the tree.
>
> The way that out of tree/recipe space meta data is handled is now
> the same as the way the core linux-yocto 'kernel-meta' is handled.
> You specify either a git repo or a directory on the SRC_URI and
> tag it as having meta-data. Those directories are searched for
> a BSP that matches the machine that is being built. Once found,
> it is processed like any other BSP .. no special cases.
>
> What looks to have been missed was documenting *how* this should
> be done with a directory in a layer, versus a separate git
> repository. If you'd like to open a bug against me, I'll make sure
> that it is documented in the upcoming release (and hopefully on
> morty as well).

Done:
https://bugzilla.yoctoproject.org/show_bug.cgi?id=10946

>
> The following change to your bbappend triggered the right processing
> in my case:
>
>  SRC_URI_append_orion-io = " \
> -   file://orion-io-preempt-rt.scc \
> +   file://orion-io;type=kmeta;destsuffix=orion-io \
>  "

Perfect, that works. Thanks for clearing this up!

>
> All that says, is that the directory orion-io (where you had the
> .scc/.cfg files) is kernel meta data, and that it can be found
> in the directory called 'orion-io' after the fetcher pulls it
> into WORKDIR.
>
> From there, it is found, and the configuration, etc, applied to
> the build.
>
> Bruce
>
>
>
>> -George
>>
>>>
>>> Bruce
>>>
>>>
>>>>
>>>> If I don't include it in the yocto-linux-rt_4.4 SRC_URI it's never
>>>> applied at all. I'm wondering if this a n

Re: [yocto] Correct way to use a custom bsp .scc file in morty

[George McCollister]

On Thu, Jan 19, 2017 at 5:24 PM, Bruce Ashfield
<bruce.ashfi...@windriver.com> wrote:
> On 2017-01-19 6:20 PM, George McCollister wrote:
>>
>> What's the correct way to use a custom bsp .scc file located in my
>> custom bsp layer? For purposes of this email let's say it's name is
>> myplatform-preempt-rt.scc. If I specifically add it to the
>> yocto-linux-rt_4.4 SRC_URI it appears to get processed twice by scc
>> according to the meta-series output file. It then tries to apply
>> patches to standard/preempt-rt/base that don't apply. When building on
>> a intel-core2-32 platform, intel-core2-32-preempt-rt.scc only gets
>> processed once and no incorrect patches are applied.
>
>
> Something could have broken, I never rule out bugs!
>
> Morty had some different semantics than the newer branches (which
> are simplified compared to the auto-resume logic in old releases).
>
> That being said, the capability to have a BSP description in the
> SRC_URI is there, and did work during that release cycle. To have
> it work, you do need the right format in the BSP .scc file, in
> particular something with the KMACHINE and KTYPE descriptions will
> be seen as an entry point, and not trigger the re-application of
> the inherited patches.
>
> Is there any way that I can see the contents of that .scc file ?
> Otherwise, I can spin up a morty build and mock something up
> myself.

Bruce,

I stripped down my bsp later and pushed it github. You can find the
BSP .scc (and the files it includes) here:
https://github.com/gmccollister/meta-orion-minimal-bsp/tree/master/recipes-kernel/linux/linux-yocto/orion-io

The linux-yocto-rt_4.4.bbappend that adds orion-io-preempt-rt.scc to
the SRC_URI is here:
https://github.com/gmccollister/meta-orion-minimal-bsp/blob/master/recipes-kernel/linux/linux-yocto-rt_4.4.bbappend

-George

>
> Bruce
>
>
>>
>> If I don't include it in the yocto-linux-rt_4.4 SRC_URI it's never
>> applied at all. I'm wondering if this a new problem with the last big
>> push to morty since I didn't notice this before.
>>
>> I also verified that I can make myplatform-preempt-rt.scc work by
>> doing the following (only shows as processed once in meta-series and
>> no incorrect patches applied):
>> bitbake -c cleanall linux-yocto-rt
>> bitbake -c unpack linux-yocto-rt
>> Manually copy myplatform-preempt-rt.scc and related .scc, .cfg files
>> to the following path:
>>
>> work/myplatform-oe-linux-gnueabi/linux-yocto-rt/4.4.36+gitAUTOINC+b846fc6436_61d7bf47fe-r0/kernel-meta/bsp/myplatform/
>> bitbake -c compile linux-yocto-rt
>>
>> Regards,
>> George McCollister
>>
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] Correct way to use a custom bsp .scc file in morty

[George McCollister]

What's the correct way to use a custom bsp .scc file located in my
custom bsp layer? For purposes of this email let's say it's name is
myplatform-preempt-rt.scc. If I specifically add it to the
yocto-linux-rt_4.4 SRC_URI it appears to get processed twice by scc
according to the meta-series output file. It then tries to apply
patches to standard/preempt-rt/base that don't apply. When building on
a intel-core2-32 platform, intel-core2-32-preempt-rt.scc only gets
processed once and no incorrect patches are applied.

If I don't include it in the yocto-linux-rt_4.4 SRC_URI it's never
applied at all. I'm wondering if this a new problem with the last big
push to morty since I didn't notice this before.

I also verified that I can make myplatform-preempt-rt.scc work by
doing the following (only shows as processed once in meta-series and
no incorrect patches applied):
bitbake -c cleanall linux-yocto-rt
bitbake -c unpack linux-yocto-rt
Manually copy myplatform-preempt-rt.scc and related .scc, .cfg files
to the following path:
work/myplatform-oe-linux-gnueabi/linux-yocto-rt/4.4.36+gitAUTOINC+b846fc6436_61d7bf47fe-r0/kernel-meta/bsp/myplatform/
bitbake -c compile linux-yocto-rt

Regards,
George McCollister
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [kernel-tools][PATCH] scc: Fix process_file error check

[George McCollister]

Commit 626ceac135fa66277c2fa53197be33cc9d4d7614 broke the error check in
process_file by adding in three lines that stomp on $? which print the
output file when verbose is set.

Move output file on verbose print to an elif after the error check.

Signed-off-by: George McCollister <george.mccollis...@gmail.com>
---
 tools/scc | 6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/tools/scc b/tools/scc
index 4cd68a4..3d17496 100755
--- a/tools/scc
+++ b/tools/scc
@@ -246,10 +246,6 @@ process_file()
 )
 )
 
-if [ -n "${verbose}" ]; then
-cat ${scc_output_file}
-fi
-
 if [ $? -ne 0 ]; then
 echo "[ERROR]: processing of file $in failed"
 cat ${scc_output_file}
@@ -275,6 +271,8 @@ process_file()
 fi
rm -f ${scc_output_file}
 exit 1
+elif [ -n "${verbose}" ]; then
+cat ${scc_output_file}
 fi
 
 rm -f ${scc_output_file}
-- 
2.11.0

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [pseudo][PATCH] Add capset pseudo function that always succeeds

[George McCollister]

The setcap utility supplied by libcap is used to set capabilities on a
file. Before setting a file's capabilities with cap_set_file() (which uses
setxattr()) it calls cap_set_flag(mycaps, CAP_EFFECTIVE, 1, ,
CAP_SET). cap_set_flag() uses the capset syscall to raise the process'
effective capability. In most cases if the process isn't running as root
this will fail and setcap will exit with an error. Because setxattr is
intercepted by pseudo it's unnecessary for setcap to call capset().

Override capset with a pseudo function that does nothing and always
returns 0.

Signed-off-by: George McCollister <george.mccollis...@gmail.com>
---
 ports/linux/guts/capset.c | 13 +
 ports/linux/portdefs.h|  2 ++
 ports/linux/pseudo_wrappers.c |  7 +++
 ports/linux/wrapfuncs.in  |  1 +
 4 files changed, 23 insertions(+)
 create mode 100644 ports/linux/guts/capset.c

diff --git a/ports/linux/guts/capset.c b/ports/linux/guts/capset.c
new file mode 100644
index 000..51e0cdf
--- /dev/null
+++ b/ports/linux/guts/capset.c
@@ -0,0 +1,13 @@
+/*
+ * Copyright (c) 2016 Wind River Systems; see
+ * guts/COPYRIGHT for information.
+ *
+ * int capset(cap_user_header_t hdrp, const cap_user_data_t datap)
+ * int rc = -1;
+ */
+
+   rc = real_capset(hdrp, datap);
+
+/* return rc;
+ * }
+ */
diff --git a/ports/linux/portdefs.h b/ports/linux/portdefs.h
index f0a0e40..d8c5020 100644
--- a/ports/linux/portdefs.h
+++ b/ports/linux/portdefs.h
@@ -25,3 +25,5 @@ GLIBC_COMPAT_SYMBOL(memcpy,2.2.5);
 #elif defined(__i386__)
 GLIBC_COMPAT_SYMBOL(memcpy,2.0);
 #endif
+
+#include 
diff --git a/ports/linux/pseudo_wrappers.c b/ports/linux/pseudo_wrappers.c
index 26b29b0..c6c072b 100644
--- a/ports/linux/pseudo_wrappers.c
+++ b/ports/linux/pseudo_wrappers.c
@@ -31,3 +31,10 @@ int
 pseudo_fstat64(int fd, struct stat64 *buf) {
return real___fxstat64(_STAT_VER, fd, buf);
 }
+
+int pseudo_capset(cap_user_header_t hdrp, const cap_user_data_t datap) {
+   (void)hdrp;
+   (void)datap;
+
+   return 0;
+}
diff --git a/ports/linux/wrapfuncs.in b/ports/linux/wrapfuncs.in
index 3b8955a..578db35 100644
--- a/ports/linux/wrapfuncs.in
+++ b/ports/linux/wrapfuncs.in
@@ -51,3 +51,4 @@ int euidaccess(const char *path, int mode);
 int getpw(uid_t uid, char *buf);
 int getpwent_r(struct passwd *pwbuf, char *buf, size_t buflen, struct passwd 
**pwbufp);
 int getgrent_r(struct group *gbuf, char *buf, size_t buflen, struct group 
**gbufp);
+int capset(cap_user_header_t hdrp, const cap_user_data_t datap); /* 
real_func=pseudo_capset */
-- 
2.8.0

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [PATCH][meta-selinux] refpolicy-minimum: port changes for prepare_policy_store

[George McCollister]

On Mon, Apr 18, 2016 at 2:34 AM, wenzong fan  wrote:
> On 04/18/2016 05:02 AM, Philip Tricca wrote:
>>
>> Hello Wenzong,
>>
>> On 04/08/2016 01:19 AM, wenzong@windriver.com wrote:
>>>
>>> From: Wenzong Fan 
>>>
>>> Apply the changes to refpolicy-minimum_2.20151208.bb:
>>>
>>>commit bfaf278116e6c3a04bb82c9f8a4f8629a0a85df8
>>>Author: Wenzong Fan 
>>>Date:   Tue Oct 27 06:25:04 2015 -0400
>>>
>>>  refpolicy-minimum: update prepare_policy_store
>>>
>>>  * update prepare_policy_store() for supporting SELinux 2.4 & CIL,
>>> the
>>>logic is from refpolicy_common.inc but with minimum set of policy
>>>modules;
>>>
>>>  * add extra policy modules that required by sysnetwork, without
>>> those
>>>modules the install process will fail with error:
>>>
>>>  | Failed to resolve roletype statement at 62 of \
>>>
>>> .../image/var/lib/selinux/minimum/tmp/modules/100/sysnetwork/cil
>>>  | Failed to resolve ast
>>>  | semodule:  Failed!
>>>
>>>  Signed-off-by: Wenzong Fan 
>>>  Signed-off-by: Joe MacDonald 
>>>
>>> Signed-off-by: Wenzong Fan 
>>> ---
>>
>>
>> This looks great but in testing it I'm unable to use the 'minimum'
>> refpolicy recipe in any image. The recipe builds fine but the do_rootfs
>> fails trying to label the filesystem. I haven't been able to find the
>> root cause for this yet, but I'm seeing this behavior both before and
>> after adding this patch so it may be a preexisting issue?
>>
>> Given all of that, I've merged this patch into master since it doesn't
>> seem related to the issue I'm seeing. Still, some help in resolving the
>> issue I'm seeing with the minimum refpolicy recipe would be appreciated.
>
>
> Hi Philip,
>
> Thanks for getting the change merged.
>
> I did a test and see errors about:
>
>
> /.../core-image-selinux/1.0-r0/rootfs//etc/selinux/mcs/contexts/files/file_contexts:
> No such file or directory
>
> That should be the SELINUXTYPE in /etc/selinux/config is not correct, below
> patches could fix it:
>
> --- a/recipes-security/refpolicy/refpolicy_common.inc
> +++ b/recipes-security/refpolicy/refpolicy_common.inc
> @@ -162,7 +162,8 @@ SELINUX=${DEFAULT_ENFORCING}
>  # mls - Multi Level Security protection.
>  # targeted - Targeted processes are protected.
>  # mcs - Multi Category Security protection.
> -SELINUXTYPE=${POLICY_TYPE}
> +# minimum - Minimum Security protection.
> +SELINUXTYPE=${POLICY_NAME}
>
> It works in my test, please feel free to integrate it if you think it makes
> sense.
>

With this change my refpolicy-targeted build completes again.
Thanks,
George

> Thanks
> Wenzong
>
>
>>
>> Thanks,
>> Philip
>>
>>>   .../refpolicy/refpolicy-minimum_2.20151208.bb  | 41
>>> --
>>>   1 file changed, 30 insertions(+), 11 deletions(-)
>>>
>>> diff --git a/recipes-security/refpolicy/refpolicy-minimum_2.20151208.bb
>>> b/recipes-security/refpolicy/refpolicy-minimum_2.20151208.bb
>>> index b275821..47ed558 100644
>>> --- a/recipes-security/refpolicy/refpolicy-minimum_2.20151208.bb
>>> +++ b/recipes-security/refpolicy/refpolicy-minimum_2.20151208.bb
>>> @@ -26,23 +26,42 @@ EXTRA_POLICY_MODULES += "nscd"
>>>   # "login", so "login" process will access to /var/spool/mail.
>>>   EXTRA_POLICY_MODULES += "mta"
>>>
>>> +# sysnetwork requires type definitions (insmod_t, consoletype_t,
>>> +# hostname_t, ping_t, netutils_t) from modules:
>>> +EXTRA_POLICY_MODULES += "modutils consoletype hostname netutils"
>>> +
>>>   POLICY_MODULES_MIN = "${CORE_POLICY_MODULES} ${EXTRA_POLICY_MODULES}"
>>>
>>>   # re-write the same func from refpolicy_common.inc
>>>   prepare_policy_store () {
>>> oe_runmake 'DESTDIR=${D}' 'prefix=${D}${prefix}' install
>>> +   POL_PRIORITY=100
>>> +   POL_SRC=${D}${datadir}/selinux/${POLICY_NAME}
>>> +   POL_STORE=${D}${localstatedir}/lib/selinux/${POLICY_NAME}
>>> +   POL_ACTIVE_MODS=${POL_STORE}/active/modules/${POL_PRIORITY}
>>>
>>> # Prepare to create policy store
>>> -   mkdir -p ${D}${sysconfdir}/selinux/
>>> -   mkdir -p ${D}${sysconfdir}/selinux/${POLICY_NAME}/policy
>>> -   mkdir -p
>>> ${D}${sysconfdir}/selinux/${POLICY_NAME}/modules/active/modules
>>> -   mkdir -p ${D}${sysconfdir}/selinux/${POLICY_NAME}/contexts/files
>>> -   touch
>>> ${D}${sysconfdir}/selinux/${POLICY_NAME}/contexts/files/file_contexts.local
>>> -   for i in ${D}${datadir}/selinux/${POLICY_NAME}/*.pp; do
>>> -   bzip2 -f $i && mv -f $i.bz2 $i
>>> -   done
>>> -   cp base.pp
>>> ${D}${sysconfdir}/selinux/${POLICY_NAME}/modules/active/base.pp
>>> -   for i in ${POLICY_MODULES_MIN}; do
>>> -   cp ${i}.pp
>>> ${D}${sysconfdir}/selinux/${POLICY_NAME}/modules/active/modules/`basename
>>> $i.pp`
>>> +   mkdir -p ${POL_STORE}