[yocto] [meta-security][thud][PATCH 1/3] apparmor: ptest fail to build on arm

[Anders Montonen]

From: Armin Kuster 

exclude arm and aarch64 ptest tasks

[v2&3]

Sent before committing.

Signed-off-by: Armin Kuster 
(cherry picked from commit 27ddb455543b670097e252ba0d0ad5b7e4101748)
Signed-off-by: Anders Montonen 
---
 recipes-security/AppArmor/apparmor_2.12.bb | 18 ++
 1 file changed, 18 insertions(+)

diff --git a/recipes-security/AppArmor/apparmor_2.12.bb 
b/recipes-security/AppArmor/apparmor_2.12.bb
index e3f8dc9..377d918 100644
--- a/recipes-security/AppArmor/apparmor_2.12.bb
+++ b/recipes-security/AppArmor/apparmor_2.12.bb
@@ -111,6 +111,15 @@ do_install () {
fi
 }
 
+#Building ptest on arm fails.
+do_compile_ptest_aarch64 () {
+  :
+}
+
+do_compile_ptest_arm () {
+  :
+}
+
 do_compile_ptest () {
 oe_runmake -C ${B}/tests/regression/apparmor
 oe_runmake -C ${B}/parser/tst
@@ -138,6 +147,15 @@ do_install_ptest () {
cp -rf ${B}/binutils ${t}
 }
 
+#Building ptest on arm fails.
+do_install_ptest_aarch64 () {
+  :
+}
+
+do_install_ptest_arm() {
+  :
+}
+
 INITSCRIPT_PACKAGES = "${PN}"
 INITSCRIPT_NAME = "apparmor"
 INITSCRIPT_PARAMS = "start 16 2 3 4 5 . stop 35 0 1 6 ."
-- 
2.17.1

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

[yocto] [meta-security][thud][PATCH 2/3] apparmor: fix systemd support so it works

[Anders Montonen]

From: Armin Kuster 

[Yocto # 13568]

Signed-off-by: Armin Kuster 
(cherry picked from commit 5d049e7ef8a0a0a811e2ea1353521c6898e54e4d)
Signed-off-by: Anders Montonen 
---
 recipes-security/AppArmor/apparmor_2.12.bb | 18 --
 1 file changed, 12 insertions(+), 6 deletions(-)

diff --git a/recipes-security/AppArmor/apparmor_2.12.bb 
b/recipes-security/AppArmor/apparmor_2.12.bb
index 377d918..ad7f94e 100644
--- a/recipes-security/AppArmor/apparmor_2.12.bb
+++ b/recipes-security/AppArmor/apparmor_2.12.bb
@@ -43,7 +43,6 @@ PACKAGECONFIG[apache2] = ",,apache2,"
 PAMLIB="${@bb.utils.contains('DISTRO_FEATURES', 'pam', '1', '0', d)}"
 HTTPD="${@bb.utils.contains('PACKAGECONFIG', 'apache2', '1', '0', d)}"
 
-
 python() {
 if 'apache2' in d.getVar('PACKAGECONFIG').split() and \
 'webserver' not in d.getVar('BBFILE_COLLECTIONS').split():
@@ -83,7 +82,6 @@ do_compile () {
 do_install () {
install -d ${D}/${INIT_D_DIR}
install -d ${D}/lib/apparmor
-   
oe_runmake -C ${B}/libraries/libapparmor DESTDIR="${D}" install
oe_runmake -C ${B}/binutils DESTDIR="${D}" install
oe_runmake -C ${B}/utils DESTDIR="${D}" install
@@ -104,10 +102,12 @@ do_install () {
 
install ${WORKDIR}/apparmor ${D}/${INIT_D_DIR}/apparmor
install ${WORKDIR}/functions ${D}/lib/apparmor
-   if [ "${VIRTUAL-RUNTIME_init_manager}" = "systemd" ]; then
+   sed -i -e 's/getconf _NPROCESSORS_ONLN/nproc/' 
${D}/lib/apparmor/functions
+   sed -i -e 's/ls -AU/ls -A/' ${D}/lib/apparmor/functions
+
+   if ${@bb.utils.contains('DISTRO_FEATURES','systemd','true','false',d)}; 
then
install -d ${D}${systemd_system_unitdir}
-   install ${WORKDIR}/apparmor.service \
-   ${D}${systemd_system_unitdir}
+   install ${WORKDIR}/apparmor.service 
${D}${systemd_system_unitdir}
fi
 }
 
@@ -156,13 +156,19 @@ do_install_ptest_arm() {
   :
 }
 
+# We need the init script so don't rm it
+python() {
+postfuncs = 
d.getVarFlags('do_install')['postfuncs'].replace('rm_sysvinit_initddir', '')
+d.setVarFlags('do_install', { 'postfuncs': postfuncs })
+}
+
 INITSCRIPT_PACKAGES = "${PN}"
 INITSCRIPT_NAME = "apparmor"
 INITSCRIPT_PARAMS = "start 16 2 3 4 5 . stop 35 0 1 6 ."
 
 SYSTEMD_PACKAGES = "${PN}"
 SYSTEMD_SERVICE_${PN} = "apparmor.service"
-SYSTEMD_AUTO_ENABLE = "disable"
+SYSTEMD_AUTO_ENABLE ?= "enable"
 
 PACKAGES += "${@bb.utils.contains('PACKAGECONFIG', 'apache2', 'mod-${PN}', '', 
d)}"
 
-- 
2.17.1

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

[yocto] [meta-security][thud][PATCH 0/3] AppArmor fixes for Thud

[Anders Montonen]

This series backports two patches from master, and fixes one xargs
incompatibility. Together, this allows AppArmor run on an Arm target
under systemd.

Anders Montonen (1):
  apparmor: Fix xargs error

Armin Kuster (2):
  apparmor: ptest fail to build on arm
  apparmor: fix systemd support so it works

 recipes-security/AppArmor/apparmor_2.12.bb | 38 ++
 1 file changed, 31 insertions(+), 7 deletions(-)

-- 
2.17.1

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

[yocto] [meta-security][thud][PATCH 3/3] apparmor: Fix xargs error

[Anders Montonen]

The functions script uses flags specific to GNU xargs.
Add findutils to RDEPENDS.
Fixes: /lib/apparmor/functions: line 92: echo: write error: Broken pipe

Signed-off-by: Anders Montonen 
---
 recipes-security/AppArmor/apparmor_2.12.bb | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/recipes-security/AppArmor/apparmor_2.12.bb 
b/recipes-security/AppArmor/apparmor_2.12.bb
index ad7f94e..d2d83ca 100644
--- a/recipes-security/AppArmor/apparmor_2.12.bb
+++ b/recipes-security/AppArmor/apparmor_2.12.bb
@@ -177,7 +177,7 @@ FILES_mod-${PN} = "${libdir}/apache2/modules/*"
 
 ALLOW_EMPTY_${PN} = "1"
 
-RDEPENDS_${PN} += "bash lsb"
+RDEPENDS_${PN} += "bash lsb findutils"
 RDEPENDS_${PN} += "${@bb.utils.contains('PACKAGECONFIG','python','python3 
python3-modules','', d)}"
 RDEPENDS_${PN}_remove += 
"${@bb.utils.contains('PACKAGECONFIG','perl','','perl', d)}"
 RDEPENDS_${PN}-ptest += "perl coreutils dbus-lib"
-- 
2.17.1

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

Re: [yocto] Recurrent service file

[Anders Montonen]

On 26 Jul 2019, at 1:45, JH  wrote:
> 
> Hi,
> 
> I am running Yocto distroI am building a service file like a cron job
> to run every 10 minutes, I searched from Internet, there was tips to
> use Restart=always and RestartSec=10min, but that seems not quite
> right, the document said that RestartSec is for delaying 10min, any
> tips how to fix following format?

You probably want a timer unit that triggers the service unit: 
>

Regards,
Anders 

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

[yocto] Building on non-x86 hosts, wic and syslinux

[Anders Montonen]

Hi,

I was experimenting with building on an AArch64 host, and ran into the issue 
that image_types_wic.bbclass unconditionally adds syslinux-native to the 
dependencies, while syslinux is only compatible with x86 hosts. I didn’t look 
further into this, but is it possible to make this dependency chain dependent 
on the actual image types you’re trying to build?

After working around the problem by manually removing the dependency from the 
class, the build completed without issues (though I did not test the results).

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

Re: [yocto] tzdata overwrites existing localtime/zoneinfo?

[Anders Montonen]

Hi,

> On 28 Oct 2018, at 17:27, akuster808  wrote:
> On 10/25/18 5:43 PM, Anders Montonen wrote:
>> It seems to me that the tzdata package will overwrite whatever the current 
>> time zone is with its default. This is not great if you’re upgrading the 
>> package on an existing system. Should the creation of the file and link be 
>> removed from the do_install and only be done in the pkg_postinst?
> Timely email.. 2018g just got release. I will take a look at this issue
> shortly.

A colleague pointed out that although ${sysconfdir}/localtime is added to 
CONFFILES, the get_conffiles() function in package.bbclass explicitly removes 
symlinks from the list of configuration files.

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

[yocto] tzdata overwrites existing localtime/zoneinfo?

[Anders Montonen]

Hi,

It seems to me that the tzdata package will overwrite whatever the current time 
zone is with its default. This is not great if you’re upgrading the package on 
an existing system. Should the creation of the file and link be removed from 
the do_install and only be done in the pkg_postinst?

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

Re: [yocto] useradd-staticids

[Anders Montonen]

On 23 Feb 2018, at 19:30, Mark Hatle  wrote:
> On 2/23/18 10:37 AM, Anders Montonen wrote:
>> I'm looking into using the useradd-staticids class for reproducible 
>> builds. Is there any way to delay the warning/error about missing ids 
>> until a recipe is actually built rather than getting them during parsing? 
>> Having to generate tons of ids for packages you're not even using seems a 
>> bit nuts.
> The system used to do that, but then people started complaining that whenever
> they added items to their image they'd get more warnings -- and why don't we
> just tell them up-front.  :/

Thanks for the explanation. It’s not a huge deal, just a bit unexpected.

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

[yocto] useradd-staticids

[Anders Montonen]

Hi,

I'm looking into using the useradd-staticids class for reproducible 
builds. Is there any way to delay the warning/error about missing ids 
until a recipe is actually built rather than getting them during parsing? 
Having to generate tons of ids for packages you're not even using seems a 
bit nuts.


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

[yocto] /etc/resolv.conf symlink

[Anders Montonen]

Hi,

I'm hoping someone could clarify how the symlink generation from 
/etc/resolv.conf to systemd's runtime /run/systemd/resolve/resolv.conf is 
supposed to work when resolved is not enabled.


In the systemd do_install(), a directive for generating this symlink is 
inserted into /usr/lib/tmpfiles.d/etc.conf:


if ! ${@bb.utils.contains('PACKAGECONFIG', 'resolved', 'true', 'false', d)}; 
then
echo 'L! ${sysconfdir}/resolv.conf - - - - 
../run/systemd/resolve/resolv.conf' >>${D}${exec_prefix}/lib/tmpfiles.d/etc.conf

However, systemd also pulls in volatile-binds, which installs an override 
for etc.conf pointing to /dev/null, thereby preventing this link from 
being created:


# Suppress attempts to process some tmpfiles that are not temporary.
#
install -d ${D}${sysconfdir}/tmpfiles.d ${D}/var/cache
ln -s /dev/null ${D}${sysconfdir}/tmpfiles.d/etc.conf
ln -s /dev/null ${D}${sysconfdir}/tmpfiles.d/home.conf

Have I understood this correctly, and is this supposed to work?

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

[yocto] sstate and multiconfigs

[Anders Montonen]

Hi,

We've been trying out a setup using multiconfigs to select the source 
control branch some set of recipes to build. The building part goes well, 
but whenever we run package-index, the packages built using this scheme 
are deleted.


The basic setup is that we have one multiconfig per branch ('master', 
'staging' etc.) In addition to providing the name of the branch, they are 
also used to configure some variables like PACKAGE_FEED_URIS. Next, we 
have a class that basically looks like this (the 'master' config was 
originally called 'devel'):


"""
def select_branch(d):
branch = d.getVar('BB_CURRENT_MC', True)
if branch == 'default' or branch == 'devel':
branch = 'master'

if not branch:
branch = 'master'
return branch

MC_BRANCH ?= "${@select_branch(d)}"
"""

In the recipe we have something like the following:
inherit git-multiconfig # our class
inherit gitpkgv

SRCREV = "${AUTOREV}"
PV = "${FOO_VERSION}.0+gitr${SRCPV}"
PKGV = "${MC_BRANCH}-${FOO_VERSION}.0+${GITPKGV}"
SRC_URI += "gitsm://git@repo/foo.git;protocol=ssh;branch=${MC_BRANCH}"

As stated above, when a specific recipe is built (bitbake 
multiconfig:master:foo), everything looks fine, but whenever package-index 
is run (with or without multiconfig), all rpms built using this scheme 
will be deleted.


If the MC_BRANCH variable is hardcoded inside the class (eg. changing the 
body of select_branch() to a single return statement) things work as 
expected. Any suggestions on what's going on, and how to fix it (or do it 
in a better way)? The ultimate goal is being able to build multiple 
branches of our project without having to encode or duplicate that 
information, ideally receiving it as a parameter from the CI system.


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

Re: [yocto] AppArmor

[Anders Montonen]

Hi Tom,

On Thu, 22 Jun 2017, Tom Rini wrote:


I did fix the latter of these (along with the perl problem), but I'm
using sysvinit and needed apache2 in my project anyhow.


Your commit fixes most of the problems, but /usr/bin/aa-easyprof still 
gets installed with a shebang referring to the host python3 interpreter. 
The script is processed and installed by utils/python-tools-setup.py, 
which captures whatever $PYTHON is set to at the time.


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

Re: [yocto] AppArmor

[Anders Montonen]

On 21 Jun 2017, at 23:46, Khem Raj  wrote:
> On Tue, Jun 20, 2017 at 9:56 AM Anders Montonen  <mailto:anders.monto...@iki.fi>> wrote:
> Has anyone tried using AppArmor with Yocto? The recipe in the
> meta-security layer is broken, and when fixed so it actually builds, it
> turns out the installed init script relies on functions not found in
> Yocto's version of LSB.
> That seems a bug to me perhaps can be fixed in initscripts ?

I ended up replacing the recipe with one combining the one from meta-security 
and from the OpenSwitch project[1]. This allowed me to get rid of the sysvinit 
and apache2 dependencies. I’ll have to look for Tom Rini’s tweaks and see if he 
fixed the Python issues more elegantly.

IIRC the issues I ran into with the meta-security recipe were:
- The tools under binutils require the static library
- The systemd service file isn’t installed
- The Python apparmor module is built against Python 2.7, while the scripts 
that use it are Python 3. Commit 
89683b4fee4616a08d249bc7afd7be55f3fa71a3 is wrong, it papers over a QA warning 
without fixing the actual problem.
- The Python LibAppArmor module isn’t built at all.

Regards,
Anders

[1] 
<http://git.openswitch.net/cgit/openswitch/ops-build/tree/yocto/openswitch/meta-foss-openswitch/recipes-security/apparmor
 
<http://git.openswitch.net/cgit/openswitch/ops-build/tree/yocto/openswitch/meta-foss-openswitch/recipes-security/apparmor/apparmor_2.10.95.bb?h=master>>-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] AppArmor

[Anders Montonen]

Hi,

Has anyone tried using AppArmor with Yocto? The recipe in the 
meta-security layer is broken, and when fixed so it actually builds, it 
turns out the installed init script relies on functions not found in 
Yocto's version of LSB.


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