which Ubuntu 16.04.4 kernel would work with singularity 2.5.1?
177 views
Skip to first unread message
Igor Yakushin
May 14, 2018, 3:12:11 PM5/14/18
to singu...@lbl.gov
Hi All,
When running ./configure for singularity/2.5.1, I got the following errors:
=====
checking for feature: NO_NEW_PRIVS... no
ERROR!!!!!!
This host does not support the NO_NEW_PRIVS prctl functions!
The kernel must be updated to support Singularity securely.
ERROR!!!!!!
This host does not support the NO_NEW_PRIVS prctl functions!
The kernel must be updated to support Singularity securely.
=====
My kernel on Ubuntu 16.04 is
=====
uname -a
Linux ivy2-XPS-15 4.4.0-124-generic #148-Ubuntu SMP Wed May 2 13:00:18 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux
=====
What kernel version do I need?
Linux ivy2-XPS-15 4.4.0-124-generic #148-Ubuntu SMP Wed May 2 13:00:18 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux
=====
What kernel version do I need?
I did not have such problems with Scientific Linux 6 and 7 even though their kernel version seem to be much older (if the kernels are numbered the same way).
Thank you,
--
Igor Yakushin, Ph.D.
Computational Scientist
Kavli Institute for Cosmological Physics, ERC #413
Research Computing Center, room #2
The University of Chicago
Dave Godlove
May 15, 2018, 8:08:42 AM5/15/18
to singu...@lbl.gov
Hi Igor,
I wonder if your kernel has been modified in some way? Here is a script you can use to check whether you kernel supports these features. To run it with ease you can issue the following command:
curl -s https://www.sylabs.io/privtest/no_new_privs.sh | bash
Dave
--
You received this message because you are subscribed to the Google Groups "singularity" group.
To unsubscribe from this group and stop receiving emails from it, send an email to singularity+unsubscribe@lbl.gov.
Lars Viklund
May 15, 2018, 9:30:21 AM5/15/18
to singularity
Hi!
I'm a bit surprised that there's a blocking test for kernel capabilities on the build host, shouldn't that be a runtime concern?
I can't at find any override for these tests, which may be of use for people building on head/build nodes or preparing deb/RPM:s.
// Lars
To unsubscribe from this group and stop receiving emails from it, send an email to singularity...@lbl.gov.
Igor Yakushin
May 15, 2018, 10:01:10 AM5/15/18
to singu...@lbl.gov
Hi Dave,
I wonder if your kernel has been modified in some way?
It is installed from the regular Ubuntu repo.
Here is a script you can use to check whether you kernel supports these features. To run it with ease you can issue the following command:curl -s https://www.sylabs.io/privtest/no_new_privs.sh | bash
igor@ivy2-XPS-15:~$ curl -s https://www.sylabs.io/privtest/no_new_privs.sh | bash
NO_NEW_PRIVS_test.c: In function 'main':
NO_NEW_PRIVS_test.c:6:16: error: 'PR_SET_NO_NEW_PRIVS' undeclared (first use in this function); did you mean 'PR_SET_KE
EPCAPS'?
if ( prctl(PR_SET_NO_NEW_PRIVS, 1, 0, 0, 0) != 0 ) {
^~~~~~~~~~~~~~~~~~~
PR_SET_KEEPCAPS
NO_NEW_PRIVS_test.c:6:16: note: each undeclared identifier is reported only once for each function it appears in
NO_NEW_PRIVS_test.c:12:16: error: 'PR_GET_NO_NEW_PRIVS' undeclared (first use in this function); did you mean 'PR_SET_N
O_NEW_PRIVS'?
if ( prctl(PR_GET_NO_NEW_PRIVS, 0, 0, 0, 0) != 1 ) {
^~~~~~~~~~~~~~~~~~~
PR_SET_NO_NEW_PRIVS
bash: line 29: ./NO_NEW_PRIVS_test: No such file or directory
NO_NEW_PRIVS_test.c: In function 'main':
NO_NEW_PRIVS_test.c:6:16: error: 'PR_SET_NO_NEW_PRIVS' undeclared (first use in this function); did you mean 'PR_SET_KE
EPCAPS'?
if ( prctl(PR_SET_NO_NEW_PRIVS, 1, 0, 0, 0) != 0 ) {
^~~~~~~~~~~~~~~~~~~
PR_SET_KEEPCAPS
NO_NEW_PRIVS_test.c:6:16: note: each undeclared identifier is reported only once for each function it appears in
NO_NEW_PRIVS_test.c:12:16: error: 'PR_GET_NO_NEW_PRIVS' undeclared (first use in this function); did you mean 'PR_SET_N
O_NEW_PRIVS'?
if ( prctl(PR_GET_NO_NEW_PRIVS, 0, 0, 0, 0) != 1 ) {
^~~~~~~~~~~~~~~~~~~
PR_SET_NO_NEW_PRIVS
bash: line 29: ./NO_NEW_PRIVS_test: No such file or directory
Thank you,
Igor
David Godlove
May 15, 2018, 10:27:49 AM5/15/18
to singu...@lbl.gov
Hi Lars,
Here's my take on this.
If you really want to override the tests and build Singularity on a system that does not implement the NO_NEW_PRIVS features you can always modify the code. It shouldn't be too hard to figure out where the tests are occurring and what steps must be taken to disable them. I think this is better than providing a built-in override option. Running Singularity in any way shape or form on systems without NO_NEW_PRIVS is not supported. Nobody is going to be testing older versions of the kernel for undiscovered vulnerabilities that might still affect Singularity. If an admin just absolutely cannot be bothered to upgrade their head/build node to support this feature than they must do what they feel is right. But by modifying the source code they are stating that they know what they are doing and they are happy to be on their own.
Dave
To unsubscribe from this group and stop receiving emails from it, send an email to singularity+unsubscribe@lbl.gov.
David Godlove
May 15, 2018, 10:31:23 AM5/15/18
to singu...@lbl.gov
Hi Igor,
That is weird. This line should provide those variables.
#include <sys/prctl.h>So yes, it seems like your system is not supporting NO_NEW_PRIVS for some reason.
To unsubscribe from this group and stop receiving emails from it, send an email to singularity...@lbl.gov.
David Godlove
May 15, 2018, 10:32:43 AM5/15/18
to singu...@lbl.gov
I will spin up an Ubuntu 16.04 VM and try installing your version of the kernel for testing. But I'm dubious that I'll be able to replicate. My gut tells me there is probably something weird about your system.
Ryan Novosielski
May 15, 2018, 10:39:10 AM5/15/18
to singu...@lbl.gov
The numbering is done the same way, but new features and security patches (more commonly) are back ported to older RHEL kernels sometimes — one requires some more investigation to tell, in many cases.
--
____
|| \\UTGERS, |---------------------------*O*---------------------------
||_// the State | Ryan Novosielski - novo...@rutgers.edu
|| \\ University | Sr. Technologist - 973/972.0922 (2x0922) ~*~ RBHS Campus
|| \\ of NJ | Office of Advanced Research Computing - MSB C630, Newark
`'
--
____
|| \\UTGERS, |---------------------------*O*---------------------------
||_// the State | Ryan Novosielski - novo...@rutgers.edu
|| \\ University | Sr. Technologist - 973/972.0922 (2x0922) ~*~ RBHS Campus
|| \\ of NJ | Office of Advanced Research Computing - MSB C630, Newark
`'
Oliver Freyermuth
May 15, 2018, 11:00:54 AM5/15/18
to singu...@lbl.gov, David Godlove
Hi Dave,
Lars is completely right.
Checking for something at build time which matters at runtime is clearly a bug.
If you look around at Linux distros people are using, 99 % of the packages used in the world have *not* been compiled on the machine they are running on.
Hence, it's just the wrong approach checking in the build environment for something you want to ensure at runtime.
We already went down this road earlier, if you remember:
https://github.com/singularityware/singularity/issues/1044
For example, we build our RPMs and DEBs on the OpenBuildService. There's no reason the kernels there should match the kernels on the machines we deploy those DEBs / RPMs to.
If the official statement from Sylabs is, that nobody cares for packaging in RPMs and DEBs, that's of course a statement. Apparently, this is the case, since this kind of issues are repeated again and again.
It seems there are fundamental issues with how package deployment on Linux systems work in general.
That's completely unrelated to the fact that of course everybody should update their build machines to modern kernels. I fully agree with that. But please don't implement checks at the wrong place just because it seems easier.
There is a correct place, and the rest of the world is using it. There's no need to reinvent the wheel once more and repeat mistakes which have been solved ages ago.
Cheers,
Oliver
Am 15.05.2018 um 16:27 schrieb David Godlove:
> Hi Lars,
>
> Here's my take on this.
>
> If you really want to override the tests and build Singularity on a system that does not implement the NO_NEW_PRIVS features you can always modify the code. It shouldn't be too hard to figure out where the tests are occurring and what steps must be taken to disable them. I think this is better than providing a built-in override option. Running Singularity in any way shape or form on systems without NO_NEW_PRIVS is not supported. Nobody is going to be testing older versions of the kernel for undiscovered vulnerabilities that might still affect Singularity. If an admin just absolutely cannot be bothered to upgrade their head/build node to support this feature than they must do what they feel is right. But by modifying the source code they are stating that they know what they are doing and they are happy to be on their own.
>
> Dave
>
>
> curl -s https://www.sylabs.io/privtest/no_new_privs.sh <https://www.sylabs.io/privtest/no_new_privs.sh> | bash
> To unsubscribe from this group and stop receiving emails from it, send an email to singularity...@lbl.gov <mailto:singularity...@lbl.gov>.
Lars is completely right.
Checking for something at build time which matters at runtime is clearly a bug.
If you look around at Linux distros people are using, 99 % of the packages used in the world have *not* been compiled on the machine they are running on.
Hence, it's just the wrong approach checking in the build environment for something you want to ensure at runtime.
We already went down this road earlier, if you remember:
https://github.com/singularityware/singularity/issues/1044
For example, we build our RPMs and DEBs on the OpenBuildService. There's no reason the kernels there should match the kernels on the machines we deploy those DEBs / RPMs to.
If the official statement from Sylabs is, that nobody cares for packaging in RPMs and DEBs, that's of course a statement. Apparently, this is the case, since this kind of issues are repeated again and again.
It seems there are fundamental issues with how package deployment on Linux systems work in general.
That's completely unrelated to the fact that of course everybody should update their build machines to modern kernels. I fully agree with that. But please don't implement checks at the wrong place just because it seems easier.
There is a correct place, and the rest of the world is using it. There's no need to reinvent the wheel once more and repeat mistakes which have been solved ages ago.
Cheers,
Oliver
Am 15.05.2018 um 16:27 schrieb David Godlove:
> Hi Lars,
>
> Here's my take on this.
>
> If you really want to override the tests and build Singularity on a system that does not implement the NO_NEW_PRIVS features you can always modify the code. It shouldn't be too hard to figure out where the tests are occurring and what steps must be taken to disable them. I think this is better than providing a built-in override option. Running Singularity in any way shape or form on systems without NO_NEW_PRIVS is not supported. Nobody is going to be testing older versions of the kernel for undiscovered vulnerabilities that might still affect Singularity. If an admin just absolutely cannot be bothered to upgrade their head/build node to support this feature than they must do what they feel is right. But by modifying the source code they are stating that they know what they are doing and they are happy to be on their own.
>
> Dave
>
> On Tue, May 15, 2018 at 9:30 AM, Lars Viklund <zao...@gmail.com <mailto:zao...@gmail.com>> wrote:
>
> Hi!
>
> I'm a bit surprised that there's a blocking test for kernel capabilities on the build host, shouldn't that be a runtime concern?
> I can't at find any override for these tests, which may be of use for people building on head/build nodes or preparing deb/RPM:s.
>
> // Lars
>
> On Tuesday, May 15, 2018 at 2:08:42 PM UTC+2, Dave Godlove wrote:
>
> Hi Igor,
>
> I'm surprised that you got that error with such a new kernel. The NO_NEW_PRIVS functions should be supported since Linux 3.5 and even earlier in RHEL and it's derivatives.
>
> I wonder if your kernel has been modified in some way? Here is a script <https://www.sylabs.io/privtest/no_new_privs.sh> you can use to check whether you kernel supports these features. To run it with ease you can issue the following command:
>
> Hi!
>
> I'm a bit surprised that there's a blocking test for kernel capabilities on the build host, shouldn't that be a runtime concern?
> I can't at find any override for these tests, which may be of use for people building on head/build nodes or preparing deb/RPM:s.
>
> // Lars
>
> On Tuesday, May 15, 2018 at 2:08:42 PM UTC+2, Dave Godlove wrote:
>
> Hi Igor,
>
> I'm surprised that you got that error with such a new kernel. The NO_NEW_PRIVS functions should be supported since Linux 3.5 and even earlier in RHEL and it's derivatives.
>
>
> curl -s https://www.sylabs.io/privtest/no_new_privs.sh <https://www.sylabs.io/privtest/no_new_privs.sh> | bash
>
>
> --
> You received this message because you are subscribed to the Google Groups "singularity" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to singularity...@lbl.gov <mailto:singularity...@lbl.gov>.
>
> --
> You received this message because you are subscribed to the Google Groups "singularity" group.
Oliver Freyermuth
May 15, 2018, 11:22:24 AM5/15/18
to David Godlove, singularity
Hi Dave,
Am 15.05.2018 um 17:13 schrieb David Godlove:
> Hi Oliver,
>
> Please see my explanation to Lars above on why these checks matter at build time.
which ones?
The explanation I read only explained that you want to enforce people building singularity on older environments have to patch out the misplaced checks themselves.
There was no explanation at all why the checks are done at build time instead of at the correct place, i.e. at post-install of the deb / rpm packages or at runtime.
It seems there are common misconceptions about how packaging on Linux in general works amongst the Singularity devs.
I hope that's discussed at some point in Sylabs, including @gmk, who (as one of the experienced persons from CentOS) should be able to point out to the others why build-time checks for run-time functionality
are *not* done for any Linux package, and if they are for the rare exceptions where upstream devs do not understand the implications,
are generally patched out at distro level.
If Singularity want's to make packaging harder by violating established best practices, that's a statement on its own. Maybe the goal is not anymore to see widespread adoptiona and enter Debian / RedHat main repositories,
but to rather sell off Singularity Pro packages?
Cheers,
Oliver
>
> Hi Igor,
>
> Just as I suspected, I am unable to replicate your issue. Don't really know what to say.
>
> vagrant@ubuntu-xenial:~$ cat /etc/os-release
> NAME="Ubuntu"
> VERSION="16.04.4 LTS (Xenial Xerus)"
> ID=ubuntu
> ID_LIKE=debian
> PRETTY_NAME="Ubuntu 16.04.4 LTS"
> VERSION_ID="16.04"
> HOME_URL="http://www.ubuntu.com/"
> SUPPORT_URL="http://help.ubuntu.com/"
> BUG_REPORT_URL="http://bugs.launchpad.net/ubuntu/"
> VERSION_CODENAME=xenial
> UBUNTU_CODENAME=xenial
>
> vagrant@ubuntu-xenial:~$ uname -a
> Linux ubuntu-xenial 4.4.0-124-generic #148-Ubuntu SMP Wed May 2 13:00:18 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux
>
> vagrant@ubuntu-xenial:~$ curl -s https://www.sylabs.io/privtest/no_new_privs.sh | bash
> Good news! This kernel supports the PR_SET_NO_NEW_PRIVS feature!
> >
> > curl -s https://www.sylabs.io/privtest/no_new_privs.sh <https://www.sylabs.io/privtest/no_new_privs.sh> <https://www.sylabs.io/privtest/no_new_privs.sh <https://www.sylabs.io/privtest/no_new_privs.sh>> | bash
>
>
>
Am 15.05.2018 um 17:13 schrieb David Godlove:
> Hi Oliver,
>
> Please see my explanation to Lars above on why these checks matter at build time.
which ones?
The explanation I read only explained that you want to enforce people building singularity on older environments have to patch out the misplaced checks themselves.
There was no explanation at all why the checks are done at build time instead of at the correct place, i.e. at post-install of the deb / rpm packages or at runtime.
It seems there are common misconceptions about how packaging on Linux in general works amongst the Singularity devs.
I hope that's discussed at some point in Sylabs, including @gmk, who (as one of the experienced persons from CentOS) should be able to point out to the others why build-time checks for run-time functionality
are *not* done for any Linux package, and if they are for the rare exceptions where upstream devs do not understand the implications,
are generally patched out at distro level.
If Singularity want's to make packaging harder by violating established best practices, that's a statement on its own. Maybe the goal is not anymore to see widespread adoptiona and enter Debian / RedHat main repositories,
but to rather sell off Singularity Pro packages?
Cheers,
Oliver
>
> Hi Igor,
>
> Just as I suspected, I am unable to replicate your issue. Don't really know what to say.
>
> vagrant@ubuntu-xenial:~$ cat /etc/os-release
> NAME="Ubuntu"
> VERSION="16.04.4 LTS (Xenial Xerus)"
> ID=ubuntu
> ID_LIKE=debian
> PRETTY_NAME="Ubuntu 16.04.4 LTS"
> VERSION_ID="16.04"
> HOME_URL="http://www.ubuntu.com/"
> SUPPORT_URL="http://help.ubuntu.com/"
> BUG_REPORT_URL="http://bugs.launchpad.net/ubuntu/"
> VERSION_CODENAME=xenial
> UBUNTU_CODENAME=xenial
>
> vagrant@ubuntu-xenial:~$ uname -a
> Linux ubuntu-xenial 4.4.0-124-generic #148-Ubuntu SMP Wed May 2 13:00:18 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux
>
> vagrant@ubuntu-xenial:~$ curl -s https://www.sylabs.io/privtest/no_new_privs.sh | bash
> Good news! This kernel supports the PR_SET_NO_NEW_PRIVS feature!
>
> On Tue, May 15, 2018 at 11:00 AM, Oliver Freyermuth <o.frey...@googlemail.com <mailto:o.frey...@googlemail.com>> wrote:
>
> Hi Dave,
>
> Lars is completely right.
>
> Checking for something at build time which matters at runtime is clearly a bug.
> If you look around at Linux distros people are using, 99 % of the packages used in the world have *not* been compiled on the machine they are running on.
> Hence, it's just the wrong approach checking in the build environment for something you want to ensure at runtime.
>
> We already went down this road earlier, if you remember:
> https://github.com/singularityware/singularity/issues/1044 <https://github.com/singularityware/singularity/issues/1044>
> On Tue, May 15, 2018 at 11:00 AM, Oliver Freyermuth <o.frey...@googlemail.com <mailto:o.frey...@googlemail.com>> wrote:
>
> Hi Dave,
>
> Lars is completely right.
>
> Checking for something at build time which matters at runtime is clearly a bug.
> If you look around at Linux distros people are using, 99 % of the packages used in the world have *not* been compiled on the machine they are running on.
> Hence, it's just the wrong approach checking in the build environment for something you want to ensure at runtime.
>
> We already went down this road earlier, if you remember:
>
> For example, we build our RPMs and DEBs on the OpenBuildService. There's no reason the kernels there should match the kernels on the machines we deploy those DEBs / RPMs to.
> If the official statement from Sylabs is, that nobody cares for packaging in RPMs and DEBs, that's of course a statement. Apparently, this is the case, since this kind of issues are repeated again and again.
> It seems there are fundamental issues with how package deployment on Linux systems work in general.
>
> That's completely unrelated to the fact that of course everybody should update their build machines to modern kernels. I fully agree with that. But please don't implement checks at the wrong place just because it seems easier.
> There is a correct place, and the rest of the world is using it. There's no need to reinvent the wheel once more and repeat mistakes which have been solved ages ago.
>
> Cheers,
> Oliver
>
> Am 15.05.2018 um 16:27 schrieb David Godlove:
> > Hi Lars,
> >
> > Here's my take on this.
> >
> > If you really want to override the tests and build Singularity on a system that does not implement the NO_NEW_PRIVS features you can always modify the code. It shouldn't be too hard to figure out where the tests are occurring and what steps must be taken to disable them. I think this is better than providing a built-in override option. Running Singularity in any way shape or form on systems without NO_NEW_PRIVS is not supported. Nobody is going to be testing older versions of the kernel for undiscovered vulnerabilities that might still affect Singularity. If an admin just absolutely cannot be bothered to upgrade their head/build node to support this feature than they must do what they feel is right. But by modifying the source code they are stating that they know what they are doing and they are happy to be on their own.
> >
> > Dave
> >
> > On Tue, May 15, 2018 at 9:30 AM, Lars Viklund <zao...@gmail.com <mailto:zao...@gmail.com> <mailto:zao...@gmail.com <mailto:zao...@gmail.com>>> wrote:
> >
> > Hi!
> >
> > I'm a bit surprised that there's a blocking test for kernel capabilities on the build host, shouldn't that be a runtime concern?
> > I can't at find any override for these tests, which may be of use for people building on head/build nodes or preparing deb/RPM:s.
> >
> > // Lars
> >
> > On Tuesday, May 15, 2018 at 2:08:42 PM UTC+2, Dave Godlove wrote:
> >
> > Hi Igor,
> >
> > I'm surprised that you got that error with such a new kernel. The NO_NEW_PRIVS functions should be supported since Linux 3.5 and even earlier in RHEL and it's derivatives.
> >
> > I wonder if your kernel has been modified in some way? Here is a script <https://www.sylabs.io/privtest/no_new_privs.sh <https://www.sylabs.io/privtest/no_new_privs.sh>> you can use to check whether you kernel supports these features. To run it with ease you can issue the following command:
> For example, we build our RPMs and DEBs on the OpenBuildService. There's no reason the kernels there should match the kernels on the machines we deploy those DEBs / RPMs to.
> If the official statement from Sylabs is, that nobody cares for packaging in RPMs and DEBs, that's of course a statement. Apparently, this is the case, since this kind of issues are repeated again and again.
> It seems there are fundamental issues with how package deployment on Linux systems work in general.
>
> That's completely unrelated to the fact that of course everybody should update their build machines to modern kernels. I fully agree with that. But please don't implement checks at the wrong place just because it seems easier.
> There is a correct place, and the rest of the world is using it. There's no need to reinvent the wheel once more and repeat mistakes which have been solved ages ago.
>
> Cheers,
> Oliver
>
> Am 15.05.2018 um 16:27 schrieb David Godlove:
> > Hi Lars,
> >
> > Here's my take on this.
> >
> > If you really want to override the tests and build Singularity on a system that does not implement the NO_NEW_PRIVS features you can always modify the code. It shouldn't be too hard to figure out where the tests are occurring and what steps must be taken to disable them. I think this is better than providing a built-in override option. Running Singularity in any way shape or form on systems without NO_NEW_PRIVS is not supported. Nobody is going to be testing older versions of the kernel for undiscovered vulnerabilities that might still affect Singularity. If an admin just absolutely cannot be bothered to upgrade their head/build node to support this feature than they must do what they feel is right. But by modifying the source code they are stating that they know what they are doing and they are happy to be on their own.
> >
> > Dave
> >
> > On Tue, May 15, 2018 at 9:30 AM, Lars Viklund <zao...@gmail.com <mailto:zao...@gmail.com> <mailto:zao...@gmail.com <mailto:zao...@gmail.com>>> wrote:
> >
> > Hi!
> >
> > I'm a bit surprised that there's a blocking test for kernel capabilities on the build host, shouldn't that be a runtime concern?
> > I can't at find any override for these tests, which may be of use for people building on head/build nodes or preparing deb/RPM:s.
> >
> > // Lars
> >
> > On Tuesday, May 15, 2018 at 2:08:42 PM UTC+2, Dave Godlove wrote:
> >
> > Hi Igor,
> >
> > I'm surprised that you got that error with such a new kernel. The NO_NEW_PRIVS functions should be supported since Linux 3.5 and even earlier in RHEL and it's derivatives.
> >
> >
> > curl -s https://www.sylabs.io/privtest/no_new_privs.sh <https://www.sylabs.io/privtest/no_new_privs.sh> <https://www.sylabs.io/privtest/no_new_privs.sh <https://www.sylabs.io/privtest/no_new_privs.sh>> | bash
> > To unsubscribe from this group and stop receiving emails from it, send an email to singularity...@lbl.gov <mailto:singularity...@lbl.gov>.
> >
> >
> > --
> > You received this message because you are subscribed to the Google Groups "singularity" group.
> > To unsubscribe from this group and stop receiving emails from it, send an email to singularity...@lbl.gov <mailto:singularity%2Bunsu...@lbl.gov> <mailto:singularity...@lbl.gov <mailto:singularity%2Bunsu...@lbl.gov>>.
> >
> >
> > --
> > You received this message because you are subscribed to the Google Groups "singularity" group.
> >
> >
> > --
> > You received this message because you are subscribed to the Google Groups "singularity" group.
> > To unsubscribe from this group and stop receiving emails from it, send an email to singularity...@lbl.gov <mailto:singularity%2Bunsu...@lbl.gov> <mailto:singularity...@lbl.gov <mailto:singularity%2Bunsu...@lbl.gov>>.
> >
> > --
> > You received this message because you are subscribed to the Google Groups "singularity" group.
>
>
>
David Godlove
May 15, 2018, 12:05:07 PM5/15/18
to singu...@lbl.gov
---------- Forwarded message ----------
From: David Godlove <davidg...@gmail.com>
Date: Tue, May 15, 2018 at 11:13 AM
Subject: Re: [Singularity] which Ubuntu 16.04.4 kernel would work with singularity 2.5.1?
To: Oliver Freyermuth <o.frey...@googlemail.com>
From: David Godlove <davidg...@gmail.com>
Date: Tue, May 15, 2018 at 11:13 AM
Subject: Re: [Singularity] which Ubuntu 16.04.4 kernel would work with singularity 2.5.1?
To: Oliver Freyermuth <o.frey...@googlemail.com>
Hi Oliver,
Please see my explanation to Lars above on why these checks matter at build time.
Hi Igor,
Just as I suspected, I am unable to replicate your issue. Don't really know what to say.
vagrant@ubuntu-xenial:~$ cat /etc/os-release
NAME="Ubuntu"
VERSION="16.04.4 LTS (Xenial Xerus)"
ID=ubuntu
ID_LIKE=debian
PRETTY_NAME="Ubuntu 16.04.4 LTS"
VERSION_ID="16.04"
HOME_URL="http://www.ubuntu.com/"
SUPPORT_URL="http://help.ubuntu.com/"
BUG_REPORT_URL="http://bugs.launchpad.net/ubuntu/"
VERSION_CODENAME=xenial
UBUNTU_CODENAME=xenial
vagrant@ubuntu-xenial:~$ uname -a
Linux ubuntu-xenial 4.4.0-124-generic #148-Ubuntu SMP Wed May 2 13:00:18 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux
vagrant@ubuntu-xenial:~$ curl -s https://www.sylabs.io/privtest/no_new_privs.sh | bash
Good news! This kernel supports the PR_SET_NO_NEW_PRIVS feature!
> To unsubscribe from this group and stop receiving emails from it, send an email to singularity...@lbl.gov <mailto:singularity+unsubscribe...@lbl.gov>.
>
>
> --
> You received this message because you are subscribed to the Google Groups "singularity" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to singularity...@lbl.gov <mailto:singularity+unsubscribe...@lbl.gov>.
David Godlove
May 15, 2018, 12:05:49 PM5/15/18
to singu...@lbl.gov
---------- Forwarded message ----------
From: David Godlove <davidg...@gmail.com>
Date: Tue, May 15, 2018 at 11:56 AM
Subject: Re: [Singularity] which Ubuntu 16.04.4 kernel would work with singularity 2.5.1?
To: Oliver Freyermuth <o.frey...@googlemail.com>
From: David Godlove <davidg...@gmail.com>
Date: Tue, May 15, 2018 at 11:56 AM
Subject: Re: [Singularity] which Ubuntu 16.04.4 kernel would work with singularity 2.5.1?
To: Oliver Freyermuth <o.frey...@googlemail.com>
Hi Oliver,
I think the relevant line from above is:
> Running Singularity in any way shape or form on systems without NO_NEW_PRIVS is not supported. Nobody is going to be testing older versions of the kernel for undiscovered vulnerabilities that might still affect Singularity.
In other words we cannot ensure that the runtime checks are the relevant checks in this case. The runtime checks (which do also exist btw) are only in response to the vulnerabilities we have already discovered. Kernels without PR_NO_NEW_PRIVS are inherently insecure for many of the operations carried out by Singularity and those kernels are just not supported.
I don't think it is fair for you to attribute malicious intent to what you view as an incorrect packaging decision. But it is true that Sylabs doesn't have any distro maintainers on staff. The way I see it, we are really supplying the files for rpm and deb packaging as a courtesy. You can look at them as a template for how you might write your own (if you really don't want to install from source for some reason), but they shouldn't be used as is by distro maintainers. We've actually had some discussions about stripping those files down, making them very basic, and explicitly stating that they are templates provided as a courtesy and we are not accepting PRs on them. You've no-doubt noticed that we don't have a lot of resources for reviewing and merging packaging-related PRs. It's not that we are uninterested in this, it just doesn't happen to be our main expertise and focus. And I think that is OK.
Dave
> > To unsubscribe from this group and stop receiving emails from it, send an email to singularity...@lbl.gov <mailto:singularity%2Bunsubscri...@lbl.gov> <mailto:singularity+unsubscribe...@lbl.gov <mailto:singularity%2Bunsubscri...@lbl.gov>>.
> >
> >
> > --
> > You received this message because you are subscribed to the Google Groups "singularity" group.
> > To unsubscribe from this group and stop receiving emails from it, send an email to singularity...@lbl.gov <mailto:singularity%2Bunsubscri...@lbl.gov> <mailto:singularity+unsubscribe...@lbl.gov <mailto:singularity%2Bunsubscri...@lbl.gov>>.
>
>
>
David Godlove
May 15, 2018, 12:06:51 PM5/15/18
to singu...@lbl.gov
Sorry for the out of order duplicates and quoted text. I just realized that I was replying directly back to Oliver rather than posting on the group.
Oliver Freyermuth
May 15, 2018, 12:17:25 PM5/15/18
to singularity, David Godlove
Hi Dave,
ok, understood.
Am 15.05.2018 um 17:56 schrieb David Godlove:
> Hi Oliver,
>
So in other words, you say if I build on a modern kernel (i.e. "passing the build time check") and then run on a system with an older kernel, checks may be nought?
So what's the build time check good for? Only those few others compiling on the same system they are executing on?
If building on a system which is more modern than the execute node is unsafe, this should certainly be documented!
> I don't think it is fair for you to attribute malicious intent to what you view as an incorrect packaging decision. But it is true that Sylabs doesn't have any distro maintainers on staff.
That's true, but you have people experienced with distro packaging, I believe. So it might be good to include them in such decisions.
> The way I see it, we are really supplying the files for rpm and deb packaging as a courtesy. You can look at them as a template for how you might write your own (if you really don't want to install from source for some reason),
Well, my reason is the one pointed out by your CEO in his mail from 04.04.2018 00:02, let's quote:
"My own personal note/comment.... Singularity is a system package, and should be installed into the operating system, not on a shared file system with modules. This is because typically that usage model is really good for when you have lots of different versions of applications installed and the user can pick which one they want. In general, you don't want to do this with any SETUID enabled codebase. RPM/DEB packages are your friend here, [...]"
I'm sorry, but I agree with him on this, for the SETUID enabled codebase at least (which is exactly what he says).
> but they shouldn't be used as is by distro maintainers. We've actually had some discussions about stripping those files down, making them very basic, and explicitly stating that they are templates provided as a courtesy and we are not accepting PRs on them. You've > no-doubt noticed that we don't have a lot of resources for reviewing and merging packaging-related PRs. It's not that we are uninterested in this, it just doesn't happen to be our main expertise and focus. And I think that is OK.
Let's continue the quote:
"[...] and if you need/want access to prebuilt, tested, and signed versions available via YUM, go here: http://www.sylabs.io/singularity"
How will Sylabs provide these if packaging for distros is not your expertise?
But I agree, the packaging files in the Singularity repo are only out of courtesy, and that's fine.
Still, it's not nice that packaging is made harder by introducing a build-time check which only helps the few people running in the very same environment in which they build (which usually only developers do...).
It also means, taking your statement literally, that people with a more up-to-date build node than their execute nodes may be granted a false sense of security.
Cheers,
Oliver
>
> Dave
> > SUPPORT_URL="http://help.ubuntu.com/ <http://help.ubuntu.com/>"
> > BUG_REPORT_URL="http://bugs.launchpad.net/ubuntu/ <http://bugs.launchpad.net/ubuntu/>"
> > >
> > > curl -s https://www.sylabs.io/privtest/no_new_privs.sh <https://www.sylabs.io/privtest/no_new_privs.sh> <https://www.sylabs.io/privtest/no_new_privs.sh <https://www.sylabs.io/privtest/no_new_privs.sh>> <https://www.sylabs.io/privtest/no_new_privs.sh <https://www.sylabs.io/privtest/no_new_privs.sh> <https://www.sylabs.io/privtest/no_new_privs.sh <https://www.sylabs.io/privtest/no_new_privs.sh>>> | bash
> > > To unsubscribe from this group and stop receiving emails from it, send an email to singularity...@lbl.gov <mailto:singularity...@lbl.gov> <mailto:singularity...@lbl.gov <mailto:singularity...@lbl.gov>>.
> >
> >
> >
>
>
ok, understood.
Am 15.05.2018 um 17:56 schrieb David Godlove:
> Hi Oliver,
>
> I think the relevant line from above is:
>
>
>> Running Singularity in any way shape or form on systems without NO_NEW_PRIVS is not supported. Nobody is going to be testing older versions of the kernel for undiscovered vulnerabilities that might still affect Singularity.
>
> In other words we cannot ensure that the runtime checks are the relevant checks in this case. The runtime checks (which do also exist btw) are only in response to the vulnerabilities we have already discovered. Kernels without PR_NO_NEW_PRIVSare inherently insecure for many of the operations carried out by Singularity and those kernels are just not supported.
>
So in other words, you say if I build on a modern kernel (i.e. "passing the build time check") and then run on a system with an older kernel, checks may be nought?
So what's the build time check good for? Only those few others compiling on the same system they are executing on?
If building on a system which is more modern than the execute node is unsafe, this should certainly be documented!
> I don't think it is fair for you to attribute malicious intent to what you view as an incorrect packaging decision. But it is true that Sylabs doesn't have any distro maintainers on staff.
> The way I see it, we are really supplying the files for rpm and deb packaging as a courtesy. You can look at them as a template for how you might write your own (if you really don't want to install from source for some reason),
"My own personal note/comment.... Singularity is a system package, and should be installed into the operating system, not on a shared file system with modules. This is because typically that usage model is really good for when you have lots of different versions of applications installed and the user can pick which one they want. In general, you don't want to do this with any SETUID enabled codebase. RPM/DEB packages are your friend here, [...]"
I'm sorry, but I agree with him on this, for the SETUID enabled codebase at least (which is exactly what he says).
> but they shouldn't be used as is by distro maintainers. We've actually had some discussions about stripping those files down, making them very basic, and explicitly stating that they are templates provided as a courtesy and we are not accepting PRs on them. You've > no-doubt noticed that we don't have a lot of resources for reviewing and merging packaging-related PRs. It's not that we are uninterested in this, it just doesn't happen to be our main expertise and focus. And I think that is OK.
"[...] and if you need/want access to prebuilt, tested, and signed versions available via YUM, go here: http://www.sylabs.io/singularity"
How will Sylabs provide these if packaging for distros is not your expertise?
But I agree, the packaging files in the Singularity repo are only out of courtesy, and that's fine.
Still, it's not nice that packaging is made harder by introducing a build-time check which only helps the few people running in the very same environment in which they build (which usually only developers do...).
It also means, taking your statement literally, that people with a more up-to-date build node than their execute nodes may be granted a false sense of security.
Cheers,
Oliver
>
> Dave
>
> On Tue, May 15, 2018 at 11:22 AM, Oliver Freyermuth <o.frey...@googlemail.com <mailto:o.frey...@googlemail.com>> wrote:
>
> Hi Dave,
>
> On Tue, May 15, 2018 at 11:22 AM, Oliver Freyermuth <o.frey...@googlemail.com <mailto:o.frey...@googlemail.com>> wrote:
>
> Hi Dave,
>
> Am 15.05.2018 um 17:13 schrieb David Godlove:
> > Hi Oliver,
> >
> > Please see my explanation to Lars above on why these checks matter at build time.
>
> which ones?
> The explanation I read only explained that you want to enforce people building singularity on older environments have to patch out the misplaced checks themselves.
> There was no explanation at all why the checks are done at build time instead of at the correct place, i.e. at post-install of the deb / rpm packages or at runtime.
>
> It seems there are common misconceptions about how packaging on Linux in general works amongst the Singularity devs.
> I hope that's discussed at some point in Sylabs, including @gmk, who (as one of the experienced persons from CentOS) should be able to point out to the others why build-time checks for run-time functionality
> are *not* done for any Linux package, and if they are for the rare exceptions where upstream devs do not understand the implications,
> are generally patched out at distro level.
>
> If Singularity want's to make packaging harder by violating established best practices, that's a statement on its own. Maybe the goal is not anymore to see widespread adoptiona and enter Debian / RedHat main repositories,
> but to rather sell off Singularity Pro packages?
>
> Cheers,
> Oliver
>
> >
> > Hi Igor,
> >
> > Just as I suspected, I am unable to replicate your issue. Don't really know what to say.
> >
> > vagrant@ubuntu-xenial:~$ cat /etc/os-release
> > NAME="Ubuntu"
> > VERSION="16.04.4 LTS (Xenial Xerus)"
> > ID=ubuntu
> > ID_LIKE=debian
> > PRETTY_NAME="Ubuntu 16.04.4 LTS"
> > VERSION_ID="16.04"
> > HOME_URL="http://www.ubuntu.com/ <http://www.ubuntu.com/>"
> > Hi Oliver,
> >
> > Please see my explanation to Lars above on why these checks matter at build time.
>
> which ones?
> The explanation I read only explained that you want to enforce people building singularity on older environments have to patch out the misplaced checks themselves.
> There was no explanation at all why the checks are done at build time instead of at the correct place, i.e. at post-install of the deb / rpm packages or at runtime.
>
> It seems there are common misconceptions about how packaging on Linux in general works amongst the Singularity devs.
> I hope that's discussed at some point in Sylabs, including @gmk, who (as one of the experienced persons from CentOS) should be able to point out to the others why build-time checks for run-time functionality
> are *not* done for any Linux package, and if they are for the rare exceptions where upstream devs do not understand the implications,
> are generally patched out at distro level.
>
> If Singularity want's to make packaging harder by violating established best practices, that's a statement on its own. Maybe the goal is not anymore to see widespread adoptiona and enter Debian / RedHat main repositories,
> but to rather sell off Singularity Pro packages?
>
> Cheers,
> Oliver
>
> >
> > Hi Igor,
> >
> > Just as I suspected, I am unable to replicate your issue. Don't really know what to say.
> >
> > vagrant@ubuntu-xenial:~$ cat /etc/os-release
> > NAME="Ubuntu"
> > VERSION="16.04.4 LTS (Xenial Xerus)"
> > ID=ubuntu
> > ID_LIKE=debian
> > PRETTY_NAME="Ubuntu 16.04.4 LTS"
> > VERSION_ID="16.04"
> > SUPPORT_URL="http://help.ubuntu.com/ <http://help.ubuntu.com/>"
> > BUG_REPORT_URL="http://bugs.launchpad.net/ubuntu/ <http://bugs.launchpad.net/ubuntu/>"
> > VERSION_CODENAME=xenial
> > UBUNTU_CODENAME=xenial
> >
> > vagrant@ubuntu-xenial:~$ uname -a
> > Linux ubuntu-xenial 4.4.0-124-generic #148-Ubuntu SMP Wed May 2 13:00:18 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux
> >
> > vagrant@ubuntu-xenial:~$ curl -s https://www.sylabs.io/privtest/no_new_privs.sh <https://www.sylabs.io/privtest/no_new_privs.sh> | bash
> > UBUNTU_CODENAME=xenial
> >
> > vagrant@ubuntu-xenial:~$ uname -a
> > Linux ubuntu-xenial 4.4.0-124-generic #148-Ubuntu SMP Wed May 2 13:00:18 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux
> >
> > Good news! This kernel supports the PR_SET_NO_NEW_PRIVS feature!
> >
> > On Tue, May 15, 2018 at 11:00 AM, Oliver Freyermuth <o.frey...@googlemail.com <mailto:o.frey...@googlemail.com> <mailto:o.frey...@googlemail.com <mailto:o.frey...@googlemail.com>>> wrote:
> >
> > Hi Dave,
> >
> > Lars is completely right.
> >
> > Checking for something at build time which matters at runtime is clearly a bug.
> > If you look around at Linux distros people are using, 99 % of the packages used in the world have *not* been compiled on the machine they are running on.
> > Hence, it's just the wrong approach checking in the build environment for something you want to ensure at runtime.
> >
> > We already went down this road earlier, if you remember:
> > https://github.com/singularityware/singularity/issues/1044 <https://github.com/singularityware/singularity/issues/1044> <https://github.com/singularityware/singularity/issues/1044 <https://github.com/singularityware/singularity/issues/1044>>
> >
> > On Tue, May 15, 2018 at 11:00 AM, Oliver Freyermuth <o.frey...@googlemail.com <mailto:o.frey...@googlemail.com> <mailto:o.frey...@googlemail.com <mailto:o.frey...@googlemail.com>>> wrote:
> >
> > Hi Dave,
> >
> > Lars is completely right.
> >
> > Checking for something at build time which matters at runtime is clearly a bug.
> > If you look around at Linux distros people are using, 99 % of the packages used in the world have *not* been compiled on the machine they are running on.
> > Hence, it's just the wrong approach checking in the build environment for something you want to ensure at runtime.
> >
> > We already went down this road earlier, if you remember:
> >
> > For example, we build our RPMs and DEBs on the OpenBuildService. There's no reason the kernels there should match the kernels on the machines we deploy those DEBs / RPMs to.
> > If the official statement from Sylabs is, that nobody cares for packaging in RPMs and DEBs, that's of course a statement. Apparently, this is the case, since this kind of issues are repeated again and again.
> > It seems there are fundamental issues with how package deployment on Linux systems work in general.
> >
> > That's completely unrelated to the fact that of course everybody should update their build machines to modern kernels. I fully agree with that. But please don't implement checks at the wrong place just because it seems easier.
> > There is a correct place, and the rest of the world is using it. There's no need to reinvent the wheel once more and repeat mistakes which have been solved ages ago.
> >
> > Cheers,
> > Oliver
> >
> > Am 15.05.2018 um 16:27 schrieb David Godlove:
> > > Hi Lars,
> > >
> > > Here's my take on this.
> > >
> > > If you really want to override the tests and build Singularity on a system that does not implement the NO_NEW_PRIVS features you can always modify the code. It shouldn't be too hard to figure out where the tests are occurring and what steps must be taken to disable them. I think this is better than providing a built-in override option. Running Singularity in any way shape or form on systems without NO_NEW_PRIVS is not supported. Nobody is going to be testing older versions of the kernel for undiscovered vulnerabilities that might still affect Singularity. If an admin just absolutely cannot be bothered to upgrade their head/build node to support this feature than they must do what they feel is right. But by modifying the source code they are stating that they know what they are doing and they are happy to be on their own.
> > >
> > > Dave
> > >
> > > On Tue, May 15, 2018 at 9:30 AM, Lars Viklund <zao...@gmail.com <mailto:zao...@gmail.com> <mailto:zao...@gmail.com <mailto:zao...@gmail.com>> <mailto:zao...@gmail.com <mailto:zao...@gmail.com> <mailto:zao...@gmail.com <mailto:zao...@gmail.com>>>> wrote:
> > >
> > > Hi!
> > >
> > > I'm a bit surprised that there's a blocking test for kernel capabilities on the build host, shouldn't that be a runtime concern?
> > > I can't at find any override for these tests, which may be of use for people building on head/build nodes or preparing deb/RPM:s.
> > >
> > > // Lars
> > >
> > > On Tuesday, May 15, 2018 at 2:08:42 PM UTC+2, Dave Godlove wrote:
> > >
> > > Hi Igor,
> > >
> > > I'm surprised that you got that error with such a new kernel. The NO_NEW_PRIVS functions should be supported since Linux 3.5 and even earlier in RHEL and it's derivatives.
> > >
> > > I wonder if your kernel has been modified in some way? Here is a script <https://www.sylabs.io/privtest/no_new_privs.sh <https://www.sylabs.io/privtest/no_new_privs.sh> <https://www.sylabs.io/privtest/no_new_privs.sh <https://www.sylabs.io/privtest/no_new_privs.sh>>> you can use to check whether you kernel supports these features. To run it with ease you can issue the following command:
> > For example, we build our RPMs and DEBs on the OpenBuildService. There's no reason the kernels there should match the kernels on the machines we deploy those DEBs / RPMs to.
> > If the official statement from Sylabs is, that nobody cares for packaging in RPMs and DEBs, that's of course a statement. Apparently, this is the case, since this kind of issues are repeated again and again.
> > It seems there are fundamental issues with how package deployment on Linux systems work in general.
> >
> > That's completely unrelated to the fact that of course everybody should update their build machines to modern kernels. I fully agree with that. But please don't implement checks at the wrong place just because it seems easier.
> > There is a correct place, and the rest of the world is using it. There's no need to reinvent the wheel once more and repeat mistakes which have been solved ages ago.
> >
> > Cheers,
> > Oliver
> >
> > Am 15.05.2018 um 16:27 schrieb David Godlove:
> > > Hi Lars,
> > >
> > > Here's my take on this.
> > >
> > > If you really want to override the tests and build Singularity on a system that does not implement the NO_NEW_PRIVS features you can always modify the code. It shouldn't be too hard to figure out where the tests are occurring and what steps must be taken to disable them. I think this is better than providing a built-in override option. Running Singularity in any way shape or form on systems without NO_NEW_PRIVS is not supported. Nobody is going to be testing older versions of the kernel for undiscovered vulnerabilities that might still affect Singularity. If an admin just absolutely cannot be bothered to upgrade their head/build node to support this feature than they must do what they feel is right. But by modifying the source code they are stating that they know what they are doing and they are happy to be on their own.
> > >
> > > Dave
> > >
> > > On Tue, May 15, 2018 at 9:30 AM, Lars Viklund <zao...@gmail.com <mailto:zao...@gmail.com> <mailto:zao...@gmail.com <mailto:zao...@gmail.com>> <mailto:zao...@gmail.com <mailto:zao...@gmail.com> <mailto:zao...@gmail.com <mailto:zao...@gmail.com>>>> wrote:
> > >
> > > Hi!
> > >
> > > I'm a bit surprised that there's a blocking test for kernel capabilities on the build host, shouldn't that be a runtime concern?
> > > I can't at find any override for these tests, which may be of use for people building on head/build nodes or preparing deb/RPM:s.
> > >
> > > // Lars
> > >
> > > On Tuesday, May 15, 2018 at 2:08:42 PM UTC+2, Dave Godlove wrote:
> > >
> > > Hi Igor,
> > >
> > > I'm surprised that you got that error with such a new kernel. The NO_NEW_PRIVS functions should be supported since Linux 3.5 and even earlier in RHEL and it's derivatives.
> > >
> > >
> > > curl -s https://www.sylabs.io/privtest/no_new_privs.sh <https://www.sylabs.io/privtest/no_new_privs.sh> <https://www.sylabs.io/privtest/no_new_privs.sh <https://www.sylabs.io/privtest/no_new_privs.sh>> <https://www.sylabs.io/privtest/no_new_privs.sh <https://www.sylabs.io/privtest/no_new_privs.sh> <https://www.sylabs.io/privtest/no_new_privs.sh <https://www.sylabs.io/privtest/no_new_privs.sh>>> | bash
> > >
> > >
> > > --
> > > You received this message because you are subscribed to the Google Groups "singularity" group.
> > > To unsubscribe from this group and stop receiving emails from it, send an email to singularity...@lbl.gov <mailto:singularity%2Bunsu...@lbl.gov> <mailto:singularity%2Bunsu...@lbl.gov <mailto:singularity%252Buns...@lbl.gov>> <mailto:singularity...@lbl.gov <mailto:singularity%2Bunsu...@lbl.gov> <mailto:singularity%2Bunsu...@lbl.gov <mailto:singularity%252Buns...@lbl.gov>>>.
> > >
> > > --
> > > You received this message because you are subscribed to the Google Groups "singularity" group.
> > >
> > >
> > > --
> > > You received this message because you are subscribed to the Google Groups "singularity" group.
> > > To unsubscribe from this group and stop receiving emails from it, send an email to singularity...@lbl.gov <mailto:singularity%2Bunsu...@lbl.gov> <mailto:singularity%2Bunsu...@lbl.gov <mailto:singularity%252Buns...@lbl.gov>> <mailto:singularity...@lbl.gov <mailto:singularity%2Bunsu...@lbl.gov> <mailto:singularity%2Bunsu...@lbl.gov <mailto:singularity%252Buns...@lbl.gov>>>.
> > >
> > > --
> > > You received this message because you are subscribed to the Google Groups "singularity" group.
> >
> >
> >
>
>
David Godlove
May 15, 2018, 12:41:13 PM5/15/18
to singularity
Hi Oliver,
I think you are making some assumptions and running down some rabbit holes here.
> That's true, but you have people experienced with distro packaging, I believe. So it might be good to include them in such decisions.
Greg and jms are probably the two people most experienced with packaging at Sylabs and they were both tightly included in this decision.
> So in other words, you say if I build on a modern kernel (i.e. "passing the build time check") and then run on a system with an older kernel, checks may be nought?
Don't really know where you are getting that. We have both build and runtime checks which are independent of one other. I encourage you to read the code and raise issues/PRs if you see anything that might cause a problem.
As for the decision to install via rpm/deb or from source, the NO_NEW_PRIVS check is not preventing a user from building and installing a package via the supplied spec files. And it will be just as difficult to install on an outdated kernel if one is doing so from source because the checks occur at the configure stage. So I think that discussion is not relevant to this issue.
Dave
> > > To unsubscribe from this group and stop receiving emails from it, send an email to singularity+unsubscribe@lbl.gov <mailto:singularity%2Bunsu...@lbl.gov> <mailto:singularity%2Bunsu...@lbl.gov <mailto:singularity%252Buns...@lbl.gov>> <mailto:singularity+unsub...@lbl.gov <mailto:singularity%2Bunsu...@lbl.gov> <mailto:singularity%2Bunsu...@lbl.gov <mailto:singularity%252Buns...@lbl.gov>>>.
> > >
> > >
> > > --
> > > You received this message because you are subscribed to the Google Groups "singularity" group.
> > > To unsubscribe from this group and stop receiving emails from it, send an email to singularity+unsubscribe@lbl.gov <mailto:singularity%2Bunsu...@lbl.gov> <mailto:singularity%2Bunsu...@lbl.gov <mailto:singularity%252Buns...@lbl.gov>> <mailto:singularity+unsub...@lbl.gov <mailto:singularity%2Bunsu...@lbl.gov> <mailto:singularity%2Bunsu...@lbl.gov <mailto:singularity%252Buns...@lbl.gov>>>.
> >
> >
> >
>
>
Oliver Freyermuth
May 15, 2018, 1:21:27 PM5/15/18
to singu...@lbl.gov
Hi Dave,
Am 15.05.2018 um 18:40 schrieb David Godlove:
> Hi Oliver,
>
But indeed, checking the code, the checks are exactly the same both at configure and at runtime.
So I wonder again why the configure-checks are needed. What good do they do?
> As for the decision to install via rpm/deb or from source, the NO_NEW_PRIVS check is not preventing a user from building and installing a package via the supplied spec files. And it will be just as difficult to install on an outdated kernel if one is doing so from source because the checks occur at the configure stage. So I think that discussion is not relevant to this issue.
Probably you misunderstood me: I'm entirely happy about the runtime checks. I just don't see the point of the configure-time checks. What's the reasoning behind assuming the build-machine is in any case related to the execute-machine?
In general, that's not the case, unless you are a developer. But Singularity is supposed to be used in production.
I'm currently only involved directly in Gentoo packaging, and to quote from their docs:
" In general, most checks should be non-fatal. The only time fatal checks should be used is for building kernel modules or cases that a compile will fail without the option. "
( https://devmanual.gentoo.org/eclass-reference/linux-info.eclass/index.html )
And this is meant for checks done at the pre-compile-stage by the distro packager. Kernel-feature-checks done during configure-stage of a package within the package's code itself are not even considered -
it's just not done, I don't understand where this idea came from.
But let's drop the argument, I give up. Packagers know how to patch broken upstream code well enough. I slowly start to understand why so many downstream patches are kept in distros - discussing with some upstream's is just not worth the effort.
Cheers,
Oliver
>
> Dave
> > > HOME_URL="http://www.ubuntu.com/ <http://www.ubuntu.com/> <http://www.ubuntu.com/>"
> > > SUPPORT_URL="http://help.ubuntu.com/ <http://help.ubuntu.com/> <http://help.ubuntu.com/>"
> > > BUG_REPORT_URL="http://bugs.launchpad.net/ubuntu/ <http://bugs.launchpad.net/ubuntu/> <http://bugs.launchpad.net/ubuntu/ <http://bugs.launchpad.net/ubuntu/>>"
> > > >
> > > > curl -s https://www.sylabs.io/privtest/no_new_privs.sh <https://www.sylabs.io/privtest/no_new_privs.sh> <https://www.sylabs.io/privtest/no_new_privs.sh <https://www.sylabs.io/privtest/no_new_privs.sh>> <https://www.sylabs.io/privtest/no_new_privs.sh <https://www.sylabs.io/privtest/no_new_privs.sh> <https://www.sylabs.io/privtest/no_new_privs.sh <https://www.sylabs.io/privtest/no_new_privs.sh>>> <https://www.sylabs.io/privtest/no_new_privs.sh <https://www.sylabs.io/privtest/no_new_privs.sh> <https://www.sylabs.io/privtest/no_new_privs.sh <https://www.sylabs.io/privtest/no_new_privs.sh>> <https://www.sylabs.io/privtest/no_new_privs.sh <https://www.sylabs.io/privtest/no_new_privs.sh> <https://www.sylabs.io/privtest/no_new_privs.sh <https://www.sylabs.io/privtest/no_new_privs.sh>>>> | bash
> > > > To unsubscribe from this group and stop receiving emails from it, send an email to singularity...@lbl.gov <mailto:singularity...@lbl.gov> <mailto:singularity...@lbl.gov <mailto:singularity...@lbl.gov>> <mailto:singularity...@lbl.gov <mailto:singularity...@lbl.gov> <mailto:singularity...@lbl.gov <mailto:singularity...@lbl.gov>>>.
--
Oliver Freyermuth
Universität Bonn
Physikalisches Institut, Raum 1.047
Nußallee 12
53115 Bonn
--
Tel.: +49 228 73 2367
Fax: +49 228 73 7869
--
Am 15.05.2018 um 18:40 schrieb David Godlove:
> Hi Oliver,
>
> I think you are making some assumptions and running down some rabbit holes here.
>
>> That's true, but you have people experienced with distro packaging, I believe. So it might be good to include them in such decisions.
>
> Greg and jms are probably the two people most experienced with packaging at Sylabs and they were both tightly included in this decision.
>
>> So in other words, you say if I build on a modern kernel (i.e. "passing the build time check") and then run on a system with an older kernel, checks may be nought?
>
> Don't really know where you are getting that. We have both build and runtime checks which are independent of one other. I encourage you to read the code and raise issues/PRs if you see anything that might cause a problem.
From your statement " we cannot ensure that the runtime checks are the relevant checks in this case ", which made me think the build time checks would be different in any way.
>
>> That's true, but you have people experienced with distro packaging, I believe. So it might be good to include them in such decisions.
>
> Greg and jms are probably the two people most experienced with packaging at Sylabs and they were both tightly included in this decision.
>
>> So in other words, you say if I build on a modern kernel (i.e. "passing the build time check") and then run on a system with an older kernel, checks may be nought?
>
> Don't really know where you are getting that. We have both build and runtime checks which are independent of one other. I encourage you to read the code and raise issues/PRs if you see anything that might cause a problem.
But indeed, checking the code, the checks are exactly the same both at configure and at runtime.
So I wonder again why the configure-checks are needed. What good do they do?
> As for the decision to install via rpm/deb or from source, the NO_NEW_PRIVS check is not preventing a user from building and installing a package via the supplied spec files. And it will be just as difficult to install on an outdated kernel if one is doing so from source because the checks occur at the configure stage. So I think that discussion is not relevant to this issue.
In general, that's not the case, unless you are a developer. But Singularity is supposed to be used in production.
I'm currently only involved directly in Gentoo packaging, and to quote from their docs:
" In general, most checks should be non-fatal. The only time fatal checks should be used is for building kernel modules or cases that a compile will fail without the option. "
( https://devmanual.gentoo.org/eclass-reference/linux-info.eclass/index.html )
And this is meant for checks done at the pre-compile-stage by the distro packager. Kernel-feature-checks done during configure-stage of a package within the package's code itself are not even considered -
it's just not done, I don't understand where this idea came from.
But let's drop the argument, I give up. Packagers know how to patch broken upstream code well enough. I slowly start to understand why so many downstream patches are kept in distros - discussing with some upstream's is just not worth the effort.
Cheers,
Oliver
>
> Dave
>
> On Tue, May 15, 2018 at 12:17 PM, Oliver Freyermuth <o.frey...@googlemail.com <mailto:o.frey...@googlemail.com>> wrote:
>
> Hi Dave,
>
> ok, understood.
>
> Am 15.05.2018 um 17:56 schrieb David Godlove:
> > Hi Oliver,
> >
> > I think the relevant line from above is:
> >
> >> Running Singularity in any way shape or form on systems without NO_NEW_PRIVS is not supported. Nobody is going to be testing older versions of the kernel for undiscovered vulnerabilities that might still affect Singularity.
> >
> > In other words we cannot ensure that the runtime checks are the relevant checks in this case. The runtime checks (which do also exist btw) are only in response to the vulnerabilities we have already discovered. Kernels without PR_NO_NEW_PRIVSare inherently insecure for many of the operations carried out by Singularity and those kernels are just not supported.
>
> So in other words, you say if I build on a modern kernel (i.e. "passing the build time check") and then run on a system with an older kernel, checks may be nought?
> So what's the build time check good for? Only those few others compiling on the same system they are executing on?
>
> If building on a system which is more modern than the execute node is unsafe, this should certainly be documented!
>
> > I don't think it is fair for you to attribute malicious intent to what you view as an incorrect packaging decision. But it is true that Sylabs doesn't have any distro maintainers on staff.
>
> That's true, but you have people experienced with distro packaging, I believe. So it might be good to include them in such decisions.
>
> > The way I see it, we are really supplying the files for rpm and deb packaging as a courtesy. You can look at them as a template for how you might write your own (if you really don't want to install from source for some reason),
>
> Well, my reason is the one pointed out by your CEO in his mail from 04.04.2018 00:02, let's quote:
> "My own personal note/comment.... Singularity is a system package, and should be installed into the operating system, not on a shared file system with modules. This is because typically that usage model is really good for when you have lots of different versions of applications installed and the user can pick which one they want. In general, you don't want to do this with any SETUID enabled codebase. RPM/DEB packages are your friend here, [...]"
>
> I'm sorry, but I agree with him on this, for the SETUID enabled codebase at least (which is exactly what he says).
>
> > but they shouldn't be used as is by distro maintainers. We've actually had some discussions about stripping those files down, making them very basic, and explicitly stating that they are templates provided as a courtesy and we are not accepting PRs on them. You've > no-doubt noticed that we don't have a lot of resources for reviewing and merging packaging-related PRs. It's not that we are uninterested in this, it just doesn't happen to be our main expertise and focus. And I think that is OK.
>
> Let's continue the quote:
> "[...] and if you need/want access to prebuilt, tested, and signed versions available via YUM, go here: http://www.sylabs.io/singularity <http://www.sylabs.io/singularity>"
> On Tue, May 15, 2018 at 12:17 PM, Oliver Freyermuth <o.frey...@googlemail.com <mailto:o.frey...@googlemail.com>> wrote:
>
> Hi Dave,
>
> ok, understood.
>
> Am 15.05.2018 um 17:56 schrieb David Godlove:
> > Hi Oliver,
> >
> > I think the relevant line from above is:
> >
> >> Running Singularity in any way shape or form on systems without NO_NEW_PRIVS is not supported. Nobody is going to be testing older versions of the kernel for undiscovered vulnerabilities that might still affect Singularity.
> >
> > In other words we cannot ensure that the runtime checks are the relevant checks in this case. The runtime checks (which do also exist btw) are only in response to the vulnerabilities we have already discovered. Kernels without PR_NO_NEW_PRIVSare inherently insecure for many of the operations carried out by Singularity and those kernels are just not supported.
>
> So in other words, you say if I build on a modern kernel (i.e. "passing the build time check") and then run on a system with an older kernel, checks may be nought?
> So what's the build time check good for? Only those few others compiling on the same system they are executing on?
>
> If building on a system which is more modern than the execute node is unsafe, this should certainly be documented!
>
> > I don't think it is fair for you to attribute malicious intent to what you view as an incorrect packaging decision. But it is true that Sylabs doesn't have any distro maintainers on staff.
>
> That's true, but you have people experienced with distro packaging, I believe. So it might be good to include them in such decisions.
>
> > The way I see it, we are really supplying the files for rpm and deb packaging as a courtesy. You can look at them as a template for how you might write your own (if you really don't want to install from source for some reason),
>
> Well, my reason is the one pointed out by your CEO in his mail from 04.04.2018 00:02, let's quote:
> "My own personal note/comment.... Singularity is a system package, and should be installed into the operating system, not on a shared file system with modules. This is because typically that usage model is really good for when you have lots of different versions of applications installed and the user can pick which one they want. In general, you don't want to do this with any SETUID enabled codebase. RPM/DEB packages are your friend here, [...]"
>
> I'm sorry, but I agree with him on this, for the SETUID enabled codebase at least (which is exactly what he says).
>
> > but they shouldn't be used as is by distro maintainers. We've actually had some discussions about stripping those files down, making them very basic, and explicitly stating that they are templates provided as a courtesy and we are not accepting PRs on them. You've > no-doubt noticed that we don't have a lot of resources for reviewing and merging packaging-related PRs. It's not that we are uninterested in this, it just doesn't happen to be our main expertise and focus. And I think that is OK.
>
> Let's continue the quote:
> > > SUPPORT_URL="http://help.ubuntu.com/ <http://help.ubuntu.com/> <http://help.ubuntu.com/>"
> > > BUG_REPORT_URL="http://bugs.launchpad.net/ubuntu/ <http://bugs.launchpad.net/ubuntu/> <http://bugs.launchpad.net/ubuntu/ <http://bugs.launchpad.net/ubuntu/>>"
> > > VERSION_CODENAME=xenial
> > > UBUNTU_CODENAME=xenial
> > >
> > > vagrant@ubuntu-xenial:~$ uname -a
> > > Linux ubuntu-xenial 4.4.0-124-generic #148-Ubuntu SMP Wed May 2 13:00:18 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux
> > >
> > > vagrant@ubuntu-xenial:~$ curl -s https://www.sylabs.io/privtest/no_new_privs.sh <https://www.sylabs.io/privtest/no_new_privs.sh> <https://www.sylabs.io/privtest/no_new_privs.sh <https://www.sylabs.io/privtest/no_new_privs.sh>> | bash
> > > UBUNTU_CODENAME=xenial
> > >
> > > vagrant@ubuntu-xenial:~$ uname -a
> > > Linux ubuntu-xenial 4.4.0-124-generic #148-Ubuntu SMP Wed May 2 13:00:18 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux
> > >
> > > Good news! This kernel supports the PR_SET_NO_NEW_PRIVS feature!
> > >
> > > On Tue, May 15, 2018 at 11:00 AM, Oliver Freyermuth <o.frey...@googlemail.com <mailto:o.frey...@googlemail.com> <mailto:o.frey...@googlemail.com <mailto:o.frey...@googlemail.com>> <mailto:o.frey...@googlemail.com <mailto:o.frey...@googlemail.com> <mailto:o.frey...@googlemail.com <mailto:o.frey...@googlemail.com>>>> wrote:
> > >
> > > Hi Dave,
> > >
> > > Lars is completely right.
> > >
> > > Checking for something at build time which matters at runtime is clearly a bug.
> > > If you look around at Linux distros people are using, 99 % of the packages used in the world have *not* been compiled on the machine they are running on.
> > > Hence, it's just the wrong approach checking in the build environment for something you want to ensure at runtime.
> > >
> > > We already went down this road earlier, if you remember:
> > > https://github.com/singularityware/singularity/issues/1044 <https://github.com/singularityware/singularity/issues/1044> <https://github.com/singularityware/singularity/issues/1044 <https://github.com/singularityware/singularity/issues/1044>> <https://github.com/singularityware/singularity/issues/1044 <https://github.com/singularityware/singularity/issues/1044> <https://github.com/singularityware/singularity/issues/1044 <https://github.com/singularityware/singularity/issues/1044>>>
> > >
> > > On Tue, May 15, 2018 at 11:00 AM, Oliver Freyermuth <o.frey...@googlemail.com <mailto:o.frey...@googlemail.com> <mailto:o.frey...@googlemail.com <mailto:o.frey...@googlemail.com>> <mailto:o.frey...@googlemail.com <mailto:o.frey...@googlemail.com> <mailto:o.frey...@googlemail.com <mailto:o.frey...@googlemail.com>>>> wrote:
> > >
> > > Hi Dave,
> > >
> > > Lars is completely right.
> > >
> > > Checking for something at build time which matters at runtime is clearly a bug.
> > > If you look around at Linux distros people are using, 99 % of the packages used in the world have *not* been compiled on the machine they are running on.
> > > Hence, it's just the wrong approach checking in the build environment for something you want to ensure at runtime.
> > >
> > > We already went down this road earlier, if you remember:
> > >
> > > For example, we build our RPMs and DEBs on the OpenBuildService. There's no reason the kernels there should match the kernels on the machines we deploy those DEBs / RPMs to.
> > > If the official statement from Sylabs is, that nobody cares for packaging in RPMs and DEBs, that's of course a statement. Apparently, this is the case, since this kind of issues are repeated again and again.
> > > It seems there are fundamental issues with how package deployment on Linux systems work in general.
> > >
> > > That's completely unrelated to the fact that of course everybody should update their build machines to modern kernels. I fully agree with that. But please don't implement checks at the wrong place just because it seems easier.
> > > There is a correct place, and the rest of the world is using it. There's no need to reinvent the wheel once more and repeat mistakes which have been solved ages ago.
> > >
> > > Cheers,
> > > Oliver
> > >
> > > Am 15.05.2018 um 16:27 schrieb David Godlove:
> > > > Hi Lars,
> > > >
> > > > Here's my take on this.
> > > >
> > > > If you really want to override the tests and build Singularity on a system that does not implement the NO_NEW_PRIVS features you can always modify the code. It shouldn't be too hard to figure out where the tests are occurring and what steps must be taken to disable them. I think this is better than providing a built-in override option. Running Singularity in any way shape or form on systems without NO_NEW_PRIVS is not supported. Nobody is going to be testing older versions of the kernel for undiscovered vulnerabilities that might still affect Singularity. If an admin just absolutely cannot be bothered to upgrade their head/build node to support this feature than they must do what they feel is right. But by modifying the source code they are stating that they know what they are doing and they are happy to be on their own.
> > > >
> > > > Dave
> > > >
> > > > On Tue, May 15, 2018 at 9:30 AM, Lars Viklund <zao...@gmail.com <mailto:zao...@gmail.com> <mailto:zao...@gmail.com <mailto:zao...@gmail.com>> <mailto:zao...@gmail.com <mailto:zao...@gmail.com> <mailto:zao...@gmail.com <mailto:zao...@gmail.com>>> <mailto:zao...@gmail.com <mailto:zao...@gmail.com> <mailto:zao...@gmail.com <mailto:zao...@gmail.com>> <mailto:zao...@gmail.com <mailto:zao...@gmail.com> <mailto:zao...@gmail.com <mailto:zao...@gmail.com>>>>> wrote:
> > > >
> > > > Hi!
> > > >
> > > > I'm a bit surprised that there's a blocking test for kernel capabilities on the build host, shouldn't that be a runtime concern?
> > > > I can't at find any override for these tests, which may be of use for people building on head/build nodes or preparing deb/RPM:s.
> > > >
> > > > // Lars
> > > >
> > > > On Tuesday, May 15, 2018 at 2:08:42 PM UTC+2, Dave Godlove wrote:
> > > >
> > > > Hi Igor,
> > > >
> > > > I'm surprised that you got that error with such a new kernel. The NO_NEW_PRIVS functions should be supported since Linux 3.5 and even earlier in RHEL and it's derivatives.
> > > >
> > > > I wonder if your kernel has been modified in some way? Here is a script <https://www.sylabs.io/privtest/no_new_privs.sh <https://www.sylabs.io/privtest/no_new_privs.sh> <https://www.sylabs.io/privtest/no_new_privs.sh <https://www.sylabs.io/privtest/no_new_privs.sh>> <https://www.sylabs.io/privtest/no_new_privs.sh <https://www.sylabs.io/privtest/no_new_privs.sh> <https://www.sylabs.io/privtest/no_new_privs.sh <https://www.sylabs.io/privtest/no_new_privs.sh>>>> you can use to check whether you kernel supports these features. To run it with ease you can issue the following command:
> > > For example, we build our RPMs and DEBs on the OpenBuildService. There's no reason the kernels there should match the kernels on the machines we deploy those DEBs / RPMs to.
> > > If the official statement from Sylabs is, that nobody cares for packaging in RPMs and DEBs, that's of course a statement. Apparently, this is the case, since this kind of issues are repeated again and again.
> > > It seems there are fundamental issues with how package deployment on Linux systems work in general.
> > >
> > > That's completely unrelated to the fact that of course everybody should update their build machines to modern kernels. I fully agree with that. But please don't implement checks at the wrong place just because it seems easier.
> > > There is a correct place, and the rest of the world is using it. There's no need to reinvent the wheel once more and repeat mistakes which have been solved ages ago.
> > >
> > > Cheers,
> > > Oliver
> > >
> > > Am 15.05.2018 um 16:27 schrieb David Godlove:
> > > > Hi Lars,
> > > >
> > > > Here's my take on this.
> > > >
> > > > If you really want to override the tests and build Singularity on a system that does not implement the NO_NEW_PRIVS features you can always modify the code. It shouldn't be too hard to figure out where the tests are occurring and what steps must be taken to disable them. I think this is better than providing a built-in override option. Running Singularity in any way shape or form on systems without NO_NEW_PRIVS is not supported. Nobody is going to be testing older versions of the kernel for undiscovered vulnerabilities that might still affect Singularity. If an admin just absolutely cannot be bothered to upgrade their head/build node to support this feature than they must do what they feel is right. But by modifying the source code they are stating that they know what they are doing and they are happy to be on their own.
> > > >
> > > > Dave
> > > >
> > > > On Tue, May 15, 2018 at 9:30 AM, Lars Viklund <zao...@gmail.com <mailto:zao...@gmail.com> <mailto:zao...@gmail.com <mailto:zao...@gmail.com>> <mailto:zao...@gmail.com <mailto:zao...@gmail.com> <mailto:zao...@gmail.com <mailto:zao...@gmail.com>>> <mailto:zao...@gmail.com <mailto:zao...@gmail.com> <mailto:zao...@gmail.com <mailto:zao...@gmail.com>> <mailto:zao...@gmail.com <mailto:zao...@gmail.com> <mailto:zao...@gmail.com <mailto:zao...@gmail.com>>>>> wrote:
> > > >
> > > > Hi!
> > > >
> > > > I'm a bit surprised that there's a blocking test for kernel capabilities on the build host, shouldn't that be a runtime concern?
> > > > I can't at find any override for these tests, which may be of use for people building on head/build nodes or preparing deb/RPM:s.
> > > >
> > > > // Lars
> > > >
> > > > On Tuesday, May 15, 2018 at 2:08:42 PM UTC+2, Dave Godlove wrote:
> > > >
> > > > Hi Igor,
> > > >
> > > > I'm surprised that you got that error with such a new kernel. The NO_NEW_PRIVS functions should be supported since Linux 3.5 and even earlier in RHEL and it's derivatives.
> > > >
> > > >
> > > > curl -s https://www.sylabs.io/privtest/no_new_privs.sh <https://www.sylabs.io/privtest/no_new_privs.sh> <https://www.sylabs.io/privtest/no_new_privs.sh <https://www.sylabs.io/privtest/no_new_privs.sh>> <https://www.sylabs.io/privtest/no_new_privs.sh <https://www.sylabs.io/privtest/no_new_privs.sh> <https://www.sylabs.io/privtest/no_new_privs.sh <https://www.sylabs.io/privtest/no_new_privs.sh>>> <https://www.sylabs.io/privtest/no_new_privs.sh <https://www.sylabs.io/privtest/no_new_privs.sh> <https://www.sylabs.io/privtest/no_new_privs.sh <https://www.sylabs.io/privtest/no_new_privs.sh>> <https://www.sylabs.io/privtest/no_new_privs.sh <https://www.sylabs.io/privtest/no_new_privs.sh> <https://www.sylabs.io/privtest/no_new_privs.sh <https://www.sylabs.io/privtest/no_new_privs.sh>>>> | bash
> > > >
> > > >
> > > > --
> > > > You received this message because you are subscribed to the Google Groups "singularity" group.
> > > > To unsubscribe from this group and stop receiving emails from it, send an email to singularity...@lbl.gov <mailto:singularity%2Bunsu...@lbl.gov> <mailto:singularity%2Bunsu...@lbl.gov <mailto:singularity%252Buns...@lbl.gov>> <mailto:singularity%2Bunsu...@lbl.gov <mailto:singularity%252Buns...@lbl.gov> <mailto:singularity%252Buns...@lbl.gov <mailto:singularity%25252Bun...@lbl.gov>>> <mailto:singularity...@lbl.gov <mailto:singularity%2Bunsu...@lbl.gov> <mailto:singularity%2Bunsu...@lbl.gov <mailto:singularity%252Buns...@lbl.gov>> <mailto:singularity%2Bunsu...@lbl.gov <mailto:singularity%252Buns...@lbl.gov> <mailto:singularity%252Buns...@lbl.gov <mailto:singularity%25252Bun...@lbl.gov>>>>.
> > > >
> > > > --
> > > > You received this message because you are subscribed to the Google Groups "singularity" group.
> > > >
> > > >
> > > > --
> > > > You received this message because you are subscribed to the Google Groups "singularity" group.
> > > > To unsubscribe from this group and stop receiving emails from it, send an email to singularity...@lbl.gov <mailto:singularity%2Bunsu...@lbl.gov> <mailto:singularity%2Bunsu...@lbl.gov <mailto:singularity%252Buns...@lbl.gov>> <mailto:singularity%2Bunsu...@lbl.gov <mailto:singularity%252Buns...@lbl.gov> <mailto:singularity%252Buns...@lbl.gov <mailto:singularity%25252Bun...@lbl.gov>>> <mailto:singularity...@lbl.gov <mailto:singularity%2Bunsu...@lbl.gov> <mailto:singularity%2Bunsu...@lbl.gov <mailto:singularity%252Buns...@lbl.gov>> <mailto:singularity%2Bunsu...@lbl.gov <mailto:singularity%252Buns...@lbl.gov> <mailto:singularity%252Buns...@lbl.gov <mailto:singularity%25252Bun...@lbl.gov>>>>.
> > > >
> > > > --
> > > > You received this message because you are subscribed to the Google Groups "singularity" group.
> > >
> > >
> > >
> >
> >
>
>
> --
> You received this message because you are subscribed to the Google Groups "singularity" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to singularity...@lbl.gov <mailto:singularity...@lbl.gov>.
> > >
> > >
> >
> >
>
>
> --
> You received this message because you are subscribed to the Google Groups "singularity" group.
--
Oliver Freyermuth
Universität Bonn
Physikalisches Institut, Raum 1.047
Nußallee 12
53115 Bonn
--
Tel.: +49 228 73 2367
Fax: +49 228 73 7869
--
Jason Stover
May 15, 2018, 2:18:30 PM5/15/18
to singu...@lbl.gov
Hi Oliver,
On Tue, May 15, 2018 at 12:21 PM, 'Oliver Freyermuth' via singularity
<singu...@lbl.gov> wrote:
>
> So I wonder again why the configure-checks are needed. What good do they do?
>
It was decided that we weren't going to support systems that do not
support the NO_NEW_PRIVS flag. So for us, we fail during the configure
stage when trying to build. Now, if someone builds a binary, then
tries to run it on a host that doesn't support it, we fail with the
runtime check as well.
As the upstream, we're saying "We don't support this" -- both during
configure and run. We don't see it as an optional check, but a
mandatory one that must pass. But that is coming from *us*, what we
think. We think that having the check for PR_(S|G)ET_NO_NEW_PRIVS is
important enough to fail the configure stage if the test for it fails.
>
> I'm currently only involved directly in Gentoo packaging, and to quote from their docs:
> " In general, most checks should be non-fatal. The only time fatal checks should be used is for building
> kernel modules or cases that a compile will fail without the option. "
> ( https://devmanual.gentoo.org/eclass-reference/linux-info.eclass/index.html )
> And this is meant for checks done at the pre-compile-stage by the distro packager. Kernel-feature-checks
> done during configure-stage of a package within the package's code itself are not even considered -
> it's just not done, I don't understand where this idea came from.
>
And that's Gentoo. We aren't distro package maintainers, and each
distro has their own way of handling things. What we're providing is
what *we* think should be done... no one else. We threw in the towel
on trying to securely support systems that don't support NO_NEW_PRIVS.
And so to enforce this we put in checks to cause Singularity to fail
to execute a container *and* during the configure stage on the systems
that are no longer supported. For us, as the maintainer, it makes
sense to fail at both configure and runtime on these systems.
>
> But let's drop the argument, I give up. Packagers know how to patch broken upstream code well enough. I
> slowly start to understand why so many downstream patches are kept in distros - discussing with some
> upstream's is just not worth the effort.
>
You can patch it how you see fit for your use case, nothing is
stopping you from doing so. But we aren't going to change what we
provide without an overriding reason to do so. We made the decision to
make it a fatal error during configuration to be sure that people
understood that this wasn't supported anymore. Not everyone uses a
distro provided package when installing. If you want to support
_building_ on hosts that don't support the NO_NEW_PRIVS flag, you can
rip out the configure.ac check and that will leave you with only the
runtime check in place, and it's your option to do so.
That's not to say we can't come back to this and discuss it, and if
things change then we could modify how we handle it. But at this
moment, for us, it is an important enough flag we feel needs to exists
that we want to fail if we don't see it. At *both* configure and
runtime.
-J
On Tue, May 15, 2018 at 12:21 PM, 'Oliver Freyermuth' via singularity
<singu...@lbl.gov> wrote:
>
> So I wonder again why the configure-checks are needed. What good do they do?
>
support the NO_NEW_PRIVS flag. So for us, we fail during the configure
stage when trying to build. Now, if someone builds a binary, then
tries to run it on a host that doesn't support it, we fail with the
runtime check as well.
As the upstream, we're saying "We don't support this" -- both during
configure and run. We don't see it as an optional check, but a
mandatory one that must pass. But that is coming from *us*, what we
think. We think that having the check for PR_(S|G)ET_NO_NEW_PRIVS is
important enough to fail the configure stage if the test for it fails.
>
> I'm currently only involved directly in Gentoo packaging, and to quote from their docs:
> " In general, most checks should be non-fatal. The only time fatal checks should be used is for building
> kernel modules or cases that a compile will fail without the option. "
> ( https://devmanual.gentoo.org/eclass-reference/linux-info.eclass/index.html )
> And this is meant for checks done at the pre-compile-stage by the distro packager. Kernel-feature-checks
> done during configure-stage of a package within the package's code itself are not even considered -
> it's just not done, I don't understand where this idea came from.
>
distro has their own way of handling things. What we're providing is
what *we* think should be done... no one else. We threw in the towel
on trying to securely support systems that don't support NO_NEW_PRIVS.
And so to enforce this we put in checks to cause Singularity to fail
to execute a container *and* during the configure stage on the systems
that are no longer supported. For us, as the maintainer, it makes
sense to fail at both configure and runtime on these systems.
>
> But let's drop the argument, I give up. Packagers know how to patch broken upstream code well enough. I
> slowly start to understand why so many downstream patches are kept in distros - discussing with some
> upstream's is just not worth the effort.
>
stopping you from doing so. But we aren't going to change what we
provide without an overriding reason to do so. We made the decision to
make it a fatal error during configuration to be sure that people
understood that this wasn't supported anymore. Not everyone uses a
distro provided package when installing. If you want to support
_building_ on hosts that don't support the NO_NEW_PRIVS flag, you can
rip out the configure.ac check and that will leave you with only the
runtime check in place, and it's your option to do so.
That's not to say we can't come back to this and discuss it, and if
things change then we could modify how we handle it. But at this
moment, for us, it is an important enough flag we feel needs to exists
that we want to fail if we don't see it. At *both* configure and
runtime.
-J
Oliver Freyermuth
May 15, 2018, 2:28:44 PM5/15/18
to singu...@lbl.gov, Dave Godlove
Hi together,
Am 15.05.2018 um 14:08 schrieb Dave Godlove:
> Hi Igor,
>
> I'm surprised that you got that error with such a new kernel. The NO_NEW_PRIVS functions should be supported since Linux 3.5 and even earlier in RHEL and it's derivatives.
>
> I wonder if your kernel has been modified in some way? Here is a script <https://www.sylabs.io/privtest/no_new_privs.sh> you can use to check whether you kernel supports these features. To run it with ease you can issue the following command:
just to add to my security concerns from earlier on this list...
*Never* send around magic commandlines such as these, and certainly *never* execute them, since:
a) Sending those around will make people feel "this is the right way" and feel safe executing it.
b) In the end, they grant the person who wrote that shell-script full power over your machine (with the privileges of your account).
It would be much safer and more educational to just point to the page containing the script, or describe what to do.
Just to highlight one issue: Even checking the page beforehand with a browser will not make it any more safe. A malicious person may change the contents depending e.g. on the user agent.
Contents may also be exchanged over time. Even for a company not intending to harm people, a hacker may break into the web server and exchange the shell script with something malicious.
While the linked example seems save *now* (I would not have expected otherwise), that's just bad practice, and encourages people to trust such "try with ease" commandlines.
Sorry, but I would have expected otherwise from a company focussing on a software where security is essential, since it runs with root privileges in the standard configuration.
Just my two cents,
Oliver
>
> Dave
> To unsubscribe from this group and stop receiving emails from it, send an email to singularity...@lbl.gov <mailto:singularity...@lbl.gov>.
Am 15.05.2018 um 14:08 schrieb Dave Godlove:
> Hi Igor,
>
> I'm surprised that you got that error with such a new kernel. The NO_NEW_PRIVS functions should be supported since Linux 3.5 and even earlier in RHEL and it's derivatives.
>
just to add to my security concerns from earlier on this list...
*Never* send around magic commandlines such as these, and certainly *never* execute them, since:
a) Sending those around will make people feel "this is the right way" and feel safe executing it.
b) In the end, they grant the person who wrote that shell-script full power over your machine (with the privileges of your account).
It would be much safer and more educational to just point to the page containing the script, or describe what to do.
Just to highlight one issue: Even checking the page beforehand with a browser will not make it any more safe. A malicious person may change the contents depending e.g. on the user agent.
Contents may also be exchanged over time. Even for a company not intending to harm people, a hacker may break into the web server and exchange the shell script with something malicious.
While the linked example seems save *now* (I would not have expected otherwise), that's just bad practice, and encourages people to trust such "try with ease" commandlines.
Sorry, but I would have expected otherwise from a company focussing on a software where security is essential, since it runs with root privileges in the standard configuration.
Just my two cents,
Oliver
>
> Dave
>
>
> --
> You received this message because you are subscribed to the Google Groups "singularity" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to singularity...@lbl.gov <mailto:singularity...@lbl.gov>.
>
> --
> You received this message because you are subscribed to the Google Groups "singularity" group.
Oliver Freyermuth
May 15, 2018, 2:38:23 PM5/15/18
to singu...@lbl.gov, Jason Stover
Hi Jason,
Am 15.05.2018 um 20:18 schrieb Jason Stover:
> Hi Oliver,
>
> On Tue, May 15, 2018 at 12:21 PM, 'Oliver Freyermuth' via singularity
> <singu...@lbl.gov> wrote:
>>
>> So I wonder again why the configure-checks are needed. What good do they do?
>>
>
> It was decided that we weren't going to support systems that do not
> support the NO_NEW_PRIVS flag. So for us, we fail during the configure
> stage when trying to build. Now, if someone builds a binary, then
> tries to run it on a host that doesn't support it, we fail with the
> runtime check as well.
>
> As the upstream, we're saying "We don't support this" -- both during
> configure and run. We don't see it as an optional check, but a
> mandatory one that must pass. But that is coming from *us*, what we
> think. We think that having the check for PR_(S|G)ET_NO_NEW_PRIVS is
> important enough to fail the configure stage if the test for it fails.
well said. What I'm still missing, though, as end user trying to understand the implications...
In which case does the check at configure-time protect me?
>>
>> I'm currently only involved directly in Gentoo packaging, and to quote from their docs:
>> " In general, most checks should be non-fatal. The only time fatal checks should be used is for building
>> kernel modules or cases that a compile will fail without the option. "
>> ( https://devmanual.gentoo.org/eclass-reference/linux-info.eclass/index.html )
>> And this is meant for checks done at the pre-compile-stage by the distro packager. Kernel-feature-checks
>> done during configure-stage of a package within the package's code itself are not even considered -
>> it's just not done, I don't understand where this idea came from.
>>
>
> And that's Gentoo. We aren't distro package maintainers, and each
> distro has their own way of handling things. What we're providing is
> what *we* think should be done... no one else. We threw in the towel
> on trying to securely support systems that don't support NO_NEW_PRIVS.
> And so to enforce this we put in checks to cause Singularity to fail
> to execute a container *and* during the configure stage on the systems
> that are no longer supported. For us, as the maintainer, it makes
> sense to fail at both configure and runtime on these systems.
Yes, sorry, I only know packaging guidelines for Gentoo. They are less strict than other distros.
And still, I am looking for the explanation *why* it has been decided to fail at configure time.
Facts have never been given. I fully understand the runtime check, but nobody explained to me the reason for the configure check.
>
>>
>> But let's drop the argument, I give up. Packagers know how to patch broken upstream code well enough. I
>> slowly start to understand why so many downstream patches are kept in distros - discussing with some
>> upstream's is just not worth the effort.
>>
>
> You can patch it how you see fit for your use case, nothing is
> stopping you from doing so. But we aren't going to change what we
> provide without an overriding reason to do so. We made the decision to
> make it a fatal error during configuration to be sure that people
> understood that this wasn't supported anymore. Not everyone uses a
> distro provided package when installing. If you want to support
> _building_ on hosts that don't support the NO_NEW_PRIVS flag, you can
> rip out the configure.ac check and that will leave you with only the
> runtime check in place, and it's your option to do so.
>
> That's not to say we can't come back to this and discuss it, and if
> things change then we could modify how we handle it. But at this
> moment, for us, it is an important enough flag we feel needs to exists
> that we want to fail if we don't see it. At *both* configure and
> runtime.
So the reason is to warn people self-compiling the package "earlier", before they run the resulting binary / tests?
That's the first valid reason which was mentioned in this whole thread - again, I have to wonder why it has to be fatal, but that's your decision of course.
Again, I'm out of this discussion and will wait until that "overriding reason" arrives.
Cheers and thanks,
Oliver
>
> -J
>
Am 15.05.2018 um 20:18 schrieb Jason Stover:
> Hi Oliver,
>
> On Tue, May 15, 2018 at 12:21 PM, 'Oliver Freyermuth' via singularity
> <singu...@lbl.gov> wrote:
>>
>> So I wonder again why the configure-checks are needed. What good do they do?
>>
>
> It was decided that we weren't going to support systems that do not
> support the NO_NEW_PRIVS flag. So for us, we fail during the configure
> stage when trying to build. Now, if someone builds a binary, then
> tries to run it on a host that doesn't support it, we fail with the
> runtime check as well.
>
> As the upstream, we're saying "We don't support this" -- both during
> configure and run. We don't see it as an optional check, but a
> mandatory one that must pass. But that is coming from *us*, what we
> think. We think that having the check for PR_(S|G)ET_NO_NEW_PRIVS is
> important enough to fail the configure stage if the test for it fails.
In which case does the check at configure-time protect me?
>>
>> I'm currently only involved directly in Gentoo packaging, and to quote from their docs:
>> " In general, most checks should be non-fatal. The only time fatal checks should be used is for building
>> kernel modules or cases that a compile will fail without the option. "
>> ( https://devmanual.gentoo.org/eclass-reference/linux-info.eclass/index.html )
>> And this is meant for checks done at the pre-compile-stage by the distro packager. Kernel-feature-checks
>> done during configure-stage of a package within the package's code itself are not even considered -
>> it's just not done, I don't understand where this idea came from.
>>
>
> And that's Gentoo. We aren't distro package maintainers, and each
> distro has their own way of handling things. What we're providing is
> what *we* think should be done... no one else. We threw in the towel
> on trying to securely support systems that don't support NO_NEW_PRIVS.
> And so to enforce this we put in checks to cause Singularity to fail
> to execute a container *and* during the configure stage on the systems
> that are no longer supported. For us, as the maintainer, it makes
> sense to fail at both configure and runtime on these systems.
And still, I am looking for the explanation *why* it has been decided to fail at configure time.
Facts have never been given. I fully understand the runtime check, but nobody explained to me the reason for the configure check.
>
>>
>> But let's drop the argument, I give up. Packagers know how to patch broken upstream code well enough. I
>> slowly start to understand why so many downstream patches are kept in distros - discussing with some
>> upstream's is just not worth the effort.
>>
>
> You can patch it how you see fit for your use case, nothing is
> stopping you from doing so. But we aren't going to change what we
> provide without an overriding reason to do so. We made the decision to
> make it a fatal error during configuration to be sure that people
> understood that this wasn't supported anymore. Not everyone uses a
> distro provided package when installing. If you want to support
> _building_ on hosts that don't support the NO_NEW_PRIVS flag, you can
> rip out the configure.ac check and that will leave you with only the
> runtime check in place, and it's your option to do so.
>
> That's not to say we can't come back to this and discuss it, and if
> things change then we could modify how we handle it. But at this
> moment, for us, it is an important enough flag we feel needs to exists
> that we want to fail if we don't see it. At *both* configure and
> runtime.
That's the first valid reason which was mentioned in this whole thread - again, I have to wonder why it has to be fatal, but that's your decision of course.
Again, I'm out of this discussion and will wait until that "overriding reason" arrives.
Cheers and thanks,
Oliver
>
> -J
>
Igor Yakushin
May 16, 2018, 4:58:43 PM5/16/18
to singu...@lbl.gov
On Tue, May 15, 2018 at 9:30 AM, David Godlove <davidg...@gmail.com> wrote:
Hi Igor,That is weird. This line should provide those variables.
Hi Dave,
This does not look right (on 64 bit system), does it?
$ dpkg -S /usr/include/sys/prctl.h
libc6-dev-i386: /usr/include/sys/prctl.h
To what package package should prctl.h belong to on Ubuntu?
libc6-dev-i386: /usr/include/sys/prctl.h
To what package package should prctl.h belong to on Ubuntu?
I guess, I should uninstall libc6-dev-i386 and make sure that libc6-dev is installed?
Thank you,
Igor
To unsubscribe from this group and stop receiving emails from it, send an email to singularity+unsubscribe@lbl.gov.
Igor Yakushin
May 16, 2018, 5:15:38 PM5/16/18
to singu...@lbl.gov
Uninstalling 32 version of libc6-dev and trying to use 64 bit version still does not seem to help to compile the program:
igor@ivy2-XPS-15:~$ dpkg -S /usr/include/x86_64-linux-gnu/sys/prctl.h
libc6-dev:amd64: /usr/include/x86_64-linux-gnu/sys/prctl.h
cc -I/usr/include/x86_64-linux-gnu NO_NEW_PRIVS_test.c -o NO_NEW_PRIVS_test
======
libc6-dev:amd64: /usr/include/x86_64-linux-gnu/sys/prctl.h
cc -I/usr/include/x86_64-linux-gnu NO_NEW_PRIVS_test.c -o NO_NEW_PRIVS_test
======
NO_NEW_PRIVS_test.c: In function 'main':
NO_NEW_PRIVS_test.c:6:14: error: 'PR_SET_NO_NEW_PRIVS' undeclared (first use in this function); did you mean 'PR_SET_KEEPCAPS'?
NO_NEW_PRIVS_test.c:6:14: error: 'PR_SET_NO_NEW_PRIVS' undeclared (first use in this function); did you mean 'PR_SET_KEEPCAPS'?
if ( prctl(PR_SET_NO_NEW_PRIVS, 1, 0, 0, 0) != 0 ) {
^~~~~~~~~~~~~~~~~~~
PR_SET_KEEPCAPS
^~~~~~~~~~~~~~~~~~~
PR_SET_KEEPCAPS
NO_NEW_PRIVS_test.c:6:14: note: each undeclared identifier is reported only once for each function it appears in
NO_NEW_PRIVS_test.c:12:14: error: 'PR_GET_NO_NEW_PRIVS' undeclared (first use in this function); did you mean 'PR_SET_NO_NEW_PR
NO_NEW_PRIVS_test.c:12:14: error: 'PR_GET_NO_NEW_PRIVS' undeclared (first use in this function); did you mean 'PR_SET_NO_NEW_PR
IVS'?
if ( prctl(PR_GET_NO_NEW_PRIVS, 0, 0, 0, 0) != 1 ) {
^~~~~~~~~~~~~~~~~~~
PR_SET_NO_NEW_PRIVS
======
I might have some other 32 bit things interfering, perhaps:
======
$ dpkg -l | grep libc6
ii libc6:amd64 2.23-0ubuntu10 amd64
GNU C Library: Shared libraries
ii libc6:i386 2.23-0ubuntu10 i386
GNU C Library: Shared libraries
ii libc6-dbg:amd64 2.23-0ubuntu10 amd64
GNU C Library: detached debugging symbols
ii libc6-dev:amd64 2.23-0ubuntu10 amd64
GNU C Library: Development Libraries and Header Files
ii libc6-i386 2.23-0ubuntu10 amd64
GNU C Library: 32-bit shared libraries for AMD64
ii libc6-pic:amd64 2.23-0ubuntu10 amd64
GNU C Library: PIC archive library
ii libc6-x32 2.23-0ubuntu10 amd64
GNU C Library: X32 ABI Shared libraries for AMD64
ii libc6:amd64 2.23-0ubuntu10 amd64
GNU C Library: Shared libraries
ii libc6:i386 2.23-0ubuntu10 i386
GNU C Library: Shared libraries
ii libc6-dbg:amd64 2.23-0ubuntu10 amd64
GNU C Library: detached debugging symbols
ii libc6-dev:amd64 2.23-0ubuntu10 amd64
GNU C Library: Development Libraries and Header Files
ii libc6-i386 2.23-0ubuntu10 amd64
GNU C Library: 32-bit shared libraries for AMD64
ii libc6-pic:amd64 2.23-0ubuntu10 amd64
GNU C Library: PIC archive library
ii libc6-x32 2.23-0ubuntu10 amd64
GNU C Library: X32 ABI Shared libraries for AMD64
======
To unsubscribe from this group and stop receiving emails from it, send an email to singularity...@lbl.gov.
--Igor Yakushin, Ph.D.Computational ScientistKavli Institute for Cosmological Physics, ERC #413Research Computing Center, room #2The University of Chicago
Igor Yakushin
May 16, 2018, 5:20:49 PM5/16/18
to singu...@lbl.gov
OK, I found yet another problem:
$ which cc
/usr/local/Anaconda3-5.1/bin/cc
/usr/local/Anaconda3-5.1/bin/cc
Now it compiles.
Jason Stover
May 16, 2018, 5:22:38 PM5/16/18
to singu...@lbl.gov
Hrmmm... I'm confused here... Why on that first instance of
PR_SET_NO_NEW_PRIVS does it not know what it is, but then a few lines
later it suggests PR_SET_NO_NEW_PRIVS as a replacement to
PR_GET_NO_NEW_PRIVS....
Can you try putting in the full path to cc? i.e. /usr/bin/cc
-I/usr/include/x86_64-linux-gnu NO_NEW_PRIVS_test.c -o
NO_NEW_PRIVS_test
-J
PR_SET_NO_NEW_PRIVS does it not know what it is, but then a few lines
later it suggests PR_SET_NO_NEW_PRIVS as a replacement to
PR_GET_NO_NEW_PRIVS....
Can you try putting in the full path to cc? i.e. /usr/bin/cc
-I/usr/include/x86_64-linux-gnu NO_NEW_PRIVS_test.c -o
NO_NEW_PRIVS_test
-J
Reply all
Reply to author
Forward
0 new messages