I am building my own APKs for local use, targeting alpine 3.13.
It seems that abuild causes package contents to inherit security
xattrs from the host OS (if present). This is tripping me up as these
packages fail to install on a container hosted by an OS that doesn't
have security contexts enabled.
I use Bitbucket for source control and am trying to set up
containerised CI in Bitbucket pipelines.
When I build my container using Bitbucket Pipelines the APK is
different from when I build locally!
When built on-cloud, the files in the APK contain security.selinux
xattrs. When built locally, they don't. (I have a script that runs the
Bitbucket pipeline in a local container, so I'm pretty sure the same
build steps are being followed.)
Installing an APK built on the cloud to a container on my local machine fails:
/here # apk add --allow-untrusted date_h-dev-3.0.0-r2.apk
(1/1) Installing date_h-dev (3.0.0-r2)
ERROR: Failed to set xattrs on
usr/include/date/.apk.13d8a17d6f42822d457261eae2fa9ea9ba43faf2c673bf68:
Operation not permitted
[...]
1 error; 211 MiB in 53 packages
I have dug far enough to find that abuild explicitly calls `tar
--xattrs ...' when creating the package, and that `apk add' is simply
attempting to preserve that.
Is there any chance that that `tar --xattrs' in abuild might one day
change to --no-xattrs, or to something more complex that filters out
selinux xattrs? Perhaps you have a good reason for explicitly
including xattrs.
Or am I better off using something other than Bitbucket? Are there any
CI services you recommend (or disrecommend) for building APKs?
Thanks for your attention.
Ross
Hi,
There are multiple reasons why we want the xattrs. Originally it was
introduced to store the grsec kernel pax flags, and some packages also
use it to set capabilities for some executables. APK also internally
uses XATTRs for the file hash, but that happens transparently and never
hits the disk surface.
It might make sense an abuild option to not include the on-disk xattrs,
or be able to filter them. Currently, you could perhaps just strip the
xattrs manually in APKBUILD build() or package() stage?
Timo
On Wed, 5 May 2021 17:05:57 +1200
Ross Younger <crazyscot@gmail.com> wrote:
> I am building my own APKs for local use, targeting alpine 3.13.> > It seems that abuild causes package contents to inherit security> xattrs from the host OS (if present). This is tripping me up as these> packages fail to install on a container hosted by an OS that doesn't> have security contexts enabled.> > I use Bitbucket for source control and am trying to set up> containerised CI in Bitbucket pipelines.> When I build my container using Bitbucket Pipelines the APK is> different from when I build locally!> > When built on-cloud, the files in the APK contain security.selinux> xattrs. When built locally, they don't. (I have a script that runs the> Bitbucket pipeline in a local container, so I'm pretty sure the same> build steps are being followed.)> > Installing an APK built on the cloud to a container on my local> machine fails:> > /here # apk add --allow-untrusted date_h-dev-3.0.0-r2.apk> (1/1) Installing date_h-dev (3.0.0-r2)> ERROR: Failed to set xattrs on> usr/include/date/.apk.13d8a17d6f42822d457261eae2fa9ea9ba43faf2c673bf68:> Operation not permitted> [...]> 1 error; 211 MiB in 53 packages> > I have dug far enough to find that abuild explicitly calls `tar> --xattrs ...' when creating the package, and that `apk add' is simply> attempting to preserve that.> > Is there any chance that that `tar --xattrs' in abuild might one day> change to --no-xattrs, or to something more complex that filters out> selinux xattrs? Perhaps you have a good reason for explicitly> including xattrs.> > Or am I better off using something other than Bitbucket? Are there any> CI services you recommend (or disrecommend) for building APKs?> > Thanks for your attention.> > Ross
Some packages also use libcap to enable servers to listen on port 80
without root privs.
On Wed, May 5, 2021 at 9:20 AM Timo Teras <timo.teras@iki.fi> wrote:
>> Hi,>> There are multiple reasons why we want the xattrs. Originally it was> introduced to store the grsec kernel pax flags, and some packages also> use it to set capabilities for some executables. APK also internally> uses XATTRs for the file hash, but that happens transparently and never> hits the disk surface.>> It might make sense an abuild option to not include the on-disk xattrs,> or be able to filter them. Currently, you could perhaps just strip the> xattrs manually in APKBUILD build() or package() stage?>> Timo>> On Wed, 5 May 2021 17:05:57 +1200> Ross Younger <crazyscot@gmail.com> wrote:>> > I am building my own APKs for local use, targeting alpine 3.13.> >> > It seems that abuild causes package contents to inherit security> > xattrs from the host OS (if present). This is tripping me up as these> > packages fail to install on a container hosted by an OS that doesn't> > have security contexts enabled.> >> > I use Bitbucket for source control and am trying to set up> > containerised CI in Bitbucket pipelines.> > When I build my container using Bitbucket Pipelines the APK is> > different from when I build locally!> >> > When built on-cloud, the files in the APK contain security.selinux> > xattrs. When built locally, they don't. (I have a script that runs the> > Bitbucket pipeline in a local container, so I'm pretty sure the same> > build steps are being followed.)> >> > Installing an APK built on the cloud to a container on my local> > machine fails:> >> > /here # apk add --allow-untrusted date_h-dev-3.0.0-r2.apk> > (1/1) Installing date_h-dev (3.0.0-r2)> > ERROR: Failed to set xattrs on> > usr/include/date/.apk.13d8a17d6f42822d457261eae2fa9ea9ba43faf2c673bf68:> > Operation not permitted> > [...]> > 1 error; 211 MiB in 53 packages> >> > I have dug far enough to find that abuild explicitly calls `tar> > --xattrs ...' when creating the package, and that `apk add' is simply> > attempting to preserve that.> >> > Is there any chance that that `tar --xattrs' in abuild might one day> > change to --no-xattrs, or to something more complex that filters out> > selinux xattrs? Perhaps you have a good reason for explicitly> > including xattrs.> >> > Or am I better off using something other than Bitbucket? Are there any> > CI services you recommend (or disrecommend) for building APKs?> >> > Thanks for your attention.> >> > Ross>
Hi Timo,
> It might make sense an abuild option to not include the on-disk xattrs,> or be able to filter them.
I think either of these would work for me. Filtering sounds like the
safer option in case other xattrs are needed. Meanwhile, I am going to
try hacking on abuild locally.
> Currently, you could perhaps just strip the> xattrs manually in APKBUILD build() or package() stage?
Do you mean something like `setfattr -x security.selinux ...file...' ?
I have tried that within package() but this fails with EPERM. Commands
are executed as root within the container but I presume the container
itself is in unprivileged mode.
Ross
Hi,
On Wed, 5 May 2021, Ross Younger wrote:
> Hi Timo,>>> It might make sense an abuild option to not include the on-disk xattrs,>> or be able to filter them.>> I think either of these would work for me. Filtering sounds like the> safer option in case other xattrs are needed. Meanwhile, I am going to> try hacking on abuild locally.>>> Currently, you could perhaps just strip the>> xattrs manually in APKBUILD build() or package() stage?>> Do you mean something like `setfattr -x security.selinux ...file...' ?> I have tried that within package() but this fails with EPERM. Commands> are executed as root within the container but I presume the container> itself is in unprivileged mode.
Alpine itself does not use SELinux, so there should not be anything in
abuild adding selinux label attributes to anything. It might be worth it
to see why SELinux labels from the host environment are leaking into the
container FS? If you can stop that somehow, it would save you a lot of
time.
Ariadne
Hi,
On Thu, 6 May 2021 at 02:26, Ariadne Conill <ariadne@dereferenced.org>
wrote:
> Alpine itself does not use SELinux, so there should not be anything in> abuild adding selinux label attributes to anything.
The obvious workaround seems to be to patch abuild to not include selinux
labels in built packages. This certainly fits my use case, and is almost
trivial: https://gitlab.alpinelinux.org/alpine/abuild/-/merge_requests/99> It might be worth it> to see why SELinux labels from the host environment are leaking into the> container FS? If you can stop that somehow, it would save you a lot of> time.
Unfortunately, I was not able to persuade Bitbucket to make any changes
here.
Ross
Hi,
On Thu, 6 May 2021 at 02:26, Ariadne Conill <ariadne@dereferenced.org> wrote:
> Alpine itself does not use SELinux, so there should not be anything in> abuild adding selinux label attributes to anything.
The obvious workaround seems to be to patch abuild to not include
selinux labels in built packages. This certainly fits my use case, and
is almost trivial:
https://gitlab.alpinelinux.org/alpine/abuild/-/merge_requests/99> It might be worth it> to see why SELinux labels from the host environment are leaking into the> container FS? If you can stop that somehow, it would save you a lot of> time.
Unfortunately, I was not able to persuade Bitbucket to make any changes here.
Ross