| 2016-04-07 18:27:39 |
Jamie Strandboge |
bug |
|
|
added bug |
| 2016-04-07 18:27:50 |
Jamie Strandboge |
snappy: status |
New |
Confirmed |
|
| 2016-04-15 15:50:36 |
Jamie Strandboge |
bug task added |
|
libseccomp (Ubuntu) |
|
| 2016-04-15 15:51:08 |
Jamie Strandboge |
summary |
support 'complain mode' for developer mode with snaps |
implement 'complain mode' in seccomp for developer mode with snaps |
|
| 2016-04-15 15:52:27 |
Jamie Strandboge |
description |
A requirement for snappy is that a snap may be placed in developer mode which will put the security sandbox in complain mode such that violations against policy are logged, but permitted. In this manner learning tools can be written to parse the logs, etc and make developing on snappy easier.
Unfortunately with seccomp only SCMP_ACT_KILL logs to dmesg and while we can set complain mode to permit all calls, they are not logged at this time. I've discussed this with upstream and we are working together on the approach. This may require a kernel patch and an update to libseccomp, to filing this bug for now as a placeholder and we'll add other tasks as necessary. |
A requirement for snappy is that a snap may be placed in developer mode which will put the security sandbox in complain mode such that violations against policy are logged, but permitted. In this manner learning tools can be written to parse the logs, etc and make developing on snappy easier.
Unfortunately with seccomp only SCMP_ACT_KILL logs to dmesg and while we can set complain mode to permit all calls, they are not logged at this time. I've discussed this with upstream and we are working together on the approach. This may require a kernel patch and an update to libseccomp, to filing this bug for now as a placeholder and we'll add other tasks as necessary.
UPDATE: ubuntu-core-launcher now supports the '@complain' directive that is a synonym for '@unrestricted' so people can at least turn on developer mode and not be blocked by seccomp. Proper complain mode for seccomp needs to still be implemented (this bug). |
|
| 2016-04-20 14:35:57 |
Michael Vogt |
snappy: importance |
Undecided |
Medium |
|
| 2016-05-03 20:29:38 |
Jamie Strandboge |
libseccomp (Ubuntu): status |
New |
Confirmed |
|
| 2016-08-08 13:59:12 |
Tyler Hicks |
snappy: assignee |
|
Tyler Hicks (tyhicks) |
|
| 2016-08-08 13:59:16 |
Tyler Hicks |
snappy: status |
Confirmed |
In Progress |
|
| 2017-05-10 15:45:20 |
Olivier Tilloy |
bug |
|
|
added subscriber Olivier Tilloy |
| 2017-05-10 19:58:33 |
Kyle Fazzari |
bug |
|
|
added subscriber Kyle Fazzari |
| 2017-08-25 22:55:27 |
Tyler Hicks |
bug task added |
|
linux (Ubuntu) |
|
| 2017-08-25 22:55:37 |
Tyler Hicks |
linux (Ubuntu): status |
New |
In Progress |
|
| 2017-08-25 22:55:39 |
Tyler Hicks |
linux (Ubuntu): assignee |
|
Tyler Hicks (tyhicks) |
|
| 2017-08-25 22:55:44 |
Tyler Hicks |
libseccomp (Ubuntu): assignee |
|
Tyler Hicks (tyhicks) |
|
| 2017-08-28 13:15:18 |
Tyler Hicks |
linux (Ubuntu): status |
In Progress |
Fix Committed |
|
| 2017-09-05 14:56:57 |
Tyler Hicks |
bug |
|
|
added subscriber Tyler Hicks |
| 2017-09-11 15:21:59 |
Launchpad Janitor |
linux (Ubuntu): status |
Fix Committed |
Fix Released |
|
| 2017-09-19 23:00:57 |
Tyler Hicks |
description |
A requirement for snappy is that a snap may be placed in developer mode which will put the security sandbox in complain mode such that violations against policy are logged, but permitted. In this manner learning tools can be written to parse the logs, etc and make developing on snappy easier.
Unfortunately with seccomp only SCMP_ACT_KILL logs to dmesg and while we can set complain mode to permit all calls, they are not logged at this time. I've discussed this with upstream and we are working together on the approach. This may require a kernel patch and an update to libseccomp, to filing this bug for now as a placeholder and we'll add other tasks as necessary.
UPDATE: ubuntu-core-launcher now supports the '@complain' directive that is a synonym for '@unrestricted' so people can at least turn on developer mode and not be blocked by seccomp. Proper complain mode for seccomp needs to still be implemented (this bug). |
A requirement for snappy is that a snap may be placed in developer mode which will put the security sandbox in complain mode such that violations against policy are logged, but permitted. In this manner learning tools can be written to parse the logs, etc and make developing on snappy easier.
Unfortunately with seccomp only SCMP_ACT_KILL logs to dmesg and while we can set complain mode to permit all calls, they are not logged at this time. I've discussed this with upstream and we are working together on the approach. This may require a kernel patch and an update to libseccomp, to filing this bug for now as a placeholder and we'll add other tasks as necessary.
UPDATE: ubuntu-core-launcher now supports the '@complain' directive that is a synonym for '@unrestricted' so people can at least turn on developer mode and not be blocked by seccomp. Proper complain mode for seccomp needs to still be implemented (this bug).
[Impact]
Snapd needs a way to log seccomp actions without blocking any syscalls in order to have a more useful complain mode. Such functionality has been acked upstream and patches are on their way into the Linux 4.14 kernel (backported to 4.12.0-13.14 in artful).
The corresponding libseccomp changes are still undergoing review (https://github.com/seccomp/libseccomp/pull/92). The pull request adds a number of new symbols and probably isn't appropriate to backport until upstream has acked the pull request. However, only a small part of that larger pull request is needed by snapd and that change can be safely backported since the only added symbol, the SCMP_ACT_LOG macro, must match the SECCOMP_RET_LOG macro that has already been approved and merged in the upstream Linux kernel.
[Test Case]
A large number of tests are ran as part of the libseccomp build. However, the "live" tests which test libseccomp with actual kernel enforcement are not ran at that time. They can be manually exercised to help catch any regressions. Note that on Artful, there's an existing test failure (20-live-basic_die%%002-00001):
$ sudo apt build-dep -y libseccomp
$ sudo apt install -y cython
$ apt source libseccomp
$ autoreconf -ivf && ./configure --enable-python && make check-build
$ (cd tests && ./regression -T live)
...
Test 20-live-basic_die%%002-00001 result: FAILURE 20-live-basic_die TRAP rc=159
...
Regression Test Summary
tests run: 12
tests skipped: 0
tests passed: 11
tests failed: 1
tests errored: 0
============================================================
Now we can build and run a small test program to test the SCMP_ACT_LOG action in the way that snapd wants to use it for developer mode:
$ sudo apt install -y libseccomp-dev
$ gcc -o lp1567597-test lp1567597-test.c -lseccomp
$ ./lp1567597-test
You should have an entry in the system log that looks like this:
audit: type=1326 audit(1505859630.994:69): auid=1000 uid=1000 gid=1000 ses=2 pid=18451 comm="lp1567597-test" exe="/home/tyhicks/lp1567597-test" sig=0 arch=c000003e syscall=2 compat=0 ip=0x7f547352c5c0 code=0x7ffc0000
[Regression Potential]
Relatively small since the core logic is in the kernel and we're only exposing the new action through libseccomp. The changes include smarts to query the kernel to see if the action is available in the kernel. Calling applications will not be able to use the action on older kernels that don't support it. |
|
| 2017-09-19 23:03:00 |
Tyler Hicks |
summary |
implement 'complain mode' in seccomp for developer mode with snaps |
[FFe] implement 'complain mode' in seccomp for developer mode with snaps |
|
| 2017-09-19 23:03:45 |
Tyler Hicks |
attachment added |
|
lp1567597-test.c https://bugs.launchpad.net/snappy/+bug/1567597/+attachment/4953120/+files/lp1567597-test.c |
|
| 2017-09-19 23:04:15 |
Tyler Hicks |
description |
A requirement for snappy is that a snap may be placed in developer mode which will put the security sandbox in complain mode such that violations against policy are logged, but permitted. In this manner learning tools can be written to parse the logs, etc and make developing on snappy easier.
Unfortunately with seccomp only SCMP_ACT_KILL logs to dmesg and while we can set complain mode to permit all calls, they are not logged at this time. I've discussed this with upstream and we are working together on the approach. This may require a kernel patch and an update to libseccomp, to filing this bug for now as a placeholder and we'll add other tasks as necessary.
UPDATE: ubuntu-core-launcher now supports the '@complain' directive that is a synonym for '@unrestricted' so people can at least turn on developer mode and not be blocked by seccomp. Proper complain mode for seccomp needs to still be implemented (this bug).
[Impact]
Snapd needs a way to log seccomp actions without blocking any syscalls in order to have a more useful complain mode. Such functionality has been acked upstream and patches are on their way into the Linux 4.14 kernel (backported to 4.12.0-13.14 in artful).
The corresponding libseccomp changes are still undergoing review (https://github.com/seccomp/libseccomp/pull/92). The pull request adds a number of new symbols and probably isn't appropriate to backport until upstream has acked the pull request. However, only a small part of that larger pull request is needed by snapd and that change can be safely backported since the only added symbol, the SCMP_ACT_LOG macro, must match the SECCOMP_RET_LOG macro that has already been approved and merged in the upstream Linux kernel.
[Test Case]
A large number of tests are ran as part of the libseccomp build. However, the "live" tests which test libseccomp with actual kernel enforcement are not ran at that time. They can be manually exercised to help catch any regressions. Note that on Artful, there's an existing test failure (20-live-basic_die%%002-00001):
$ sudo apt build-dep -y libseccomp
$ sudo apt install -y cython
$ apt source libseccomp
$ autoreconf -ivf && ./configure --enable-python && make check-build
$ (cd tests && ./regression -T live)
...
Test 20-live-basic_die%%002-00001 result: FAILURE 20-live-basic_die TRAP rc=159
...
Regression Test Summary
tests run: 12
tests skipped: 0
tests passed: 11
tests failed: 1
tests errored: 0
============================================================
Now we can build and run a small test program to test the SCMP_ACT_LOG action in the way that snapd wants to use it for developer mode:
$ sudo apt install -y libseccomp-dev
$ gcc -o lp1567597-test lp1567597-test.c -lseccomp
$ ./lp1567597-test
You should have an entry in the system log that looks like this:
audit: type=1326 audit(1505859630.994:69): auid=1000 uid=1000 gid=1000 ses=2 pid=18451 comm="lp1567597-test" exe="/home/tyhicks/lp1567597-test" sig=0 arch=c000003e syscall=2 compat=0 ip=0x7f547352c5c0 code=0x7ffc0000
[Regression Potential]
Relatively small since the core logic is in the kernel and we're only exposing the new action through libseccomp. The changes include smarts to query the kernel to see if the action is available in the kernel. Calling applications will not be able to use the action on older kernels that don't support it. |
A requirement for snappy is that a snap may be placed in developer mode which will put the security sandbox in complain mode such that violations against policy are logged, but permitted. In this manner learning tools can be written to parse the logs, etc and make developing on snappy easier.
Unfortunately with seccomp only SCMP_ACT_KILL logs to dmesg and while we can set complain mode to permit all calls, they are not logged at this time. I've discussed this with upstream and we are working together on the approach. This may require a kernel patch and an update to libseccomp, to filing this bug for now as a placeholder and we'll add other tasks as necessary.
UPDATE: ubuntu-core-launcher now supports the '@complain' directive that is a synonym for '@unrestricted' so people can at least turn on developer mode and not be blocked by seccomp. Proper complain mode for seccomp needs to still be implemented (this bug).
[Impact]
Snapd needs a way to log seccomp actions without blocking any syscalls in order to have a more useful complain mode. Such functionality has been acked upstream and patches are on their way into the Linux 4.14 kernel (backported to 4.12.0-13.14 in artful).
The corresponding libseccomp changes are still undergoing review (https://github.com/seccomp/libseccomp/pull/92). The pull request adds a number of new symbols and probably isn't appropriate to backport until upstream has acked the pull request. However, only a small part of that larger pull request is needed by snapd and that change can be safely backported since the only added symbol, the SCMP_ACT_LOG macro, must match the SECCOMP_RET_LOG macro that has already been approved and merged in the upstream Linux kernel.
[Test Case]
A large number of tests are ran as part of the libseccomp build. However, the "live" tests which test libseccomp with actual kernel enforcement are not ran at that time. They can be manually exercised to help catch any regressions. Note that on Artful, there's an existing test failure (20-live-basic_die%%002-00001):
$ sudo apt build-dep -y libseccomp
$ sudo apt install -y cython
$ apt source libseccomp
$ autoreconf -ivf && ./configure --enable-python && make check-build
$ (cd tests && ./regression -T live)
...
Test 20-live-basic_die%%002-00001 result: FAILURE 20-live-basic_die TRAP rc=159
...
Regression Test Summary
tests run: 12
tests skipped: 0
tests passed: 11
tests failed: 1
tests errored: 0
============================================================
Now we can build and run a small test program to test the SCMP_ACT_LOG action in the way that snapd wants to use it for developer mode:
$ sudo apt install -y libseccomp-dev
$ gcc -o lp1567597-test lp1567597-test.c -lseccomp
$ ./lp1567597-test
The exit code should be 0 and you should have an entry in the system log that looks like this:
audit: type=1326 audit(1505859630.994:69): auid=1000 uid=1000 gid=1000 ses=2 pid=18451 comm="lp1567597-test" exe="/home/tyhicks/lp1567597-test" sig=0 arch=c000003e syscall=2 compat=0 ip=0x7f547352c5c0 code=0x7ffc0000
[Regression Potential]
Relatively small since the core logic is in the kernel and we're only exposing the new action through libseccomp. The changes include smarts to query the kernel to see if the action is available in the kernel. Calling applications will not be able to use the action on older kernels that don't support it. |
|
| 2017-09-19 23:05:35 |
Tyler Hicks |
attachment added |
|
libseccomp_2.3.1-2.1ubuntu2.debdiff https://bugs.launchpad.net/snappy/+bug/1567597/+attachment/4953121/+files/libseccomp_2.3.1-2.1ubuntu2.debdiff |
|
| 2017-09-19 23:06:41 |
Tyler Hicks |
attachment added |
|
libseccomp_2.3.1-2.1ubuntu2_amd64.build https://bugs.launchpad.net/snappy/+bug/1567597/+attachment/4953122/+files/libseccomp_2.3.1-2.1ubuntu2_amd64.build |
|
| 2017-09-19 23:07:24 |
Tyler Hicks |
bug |
|
|
added subscriber Ubuntu Release Team |
| 2017-09-19 23:07:31 |
Tyler Hicks |
libseccomp (Ubuntu): status |
Confirmed |
In Progress |
|
| 2017-09-19 23:07:41 |
Tyler Hicks |
snappy: status |
In Progress |
Confirmed |
|
| 2017-09-20 13:50:48 |
Tyler Hicks |
libseccomp (Ubuntu): status |
In Progress |
New |
|
| 2017-09-20 19:02:44 |
Tyler Hicks |
attachment removed |
lp1567597-test.c https://bugs.launchpad.net/snappy/+bug/1567597/+attachment/4953120/+files/lp1567597-test.c |
|
|
| 2017-09-20 19:04:06 |
Tyler Hicks |
attachment added |
|
lp1567597-test.c https://bugs.launchpad.net/snappy/+bug/1567597/+attachment/4954002/+files/lp1567597-test.c |
|
| 2017-09-21 20:40:20 |
Stéphane Graber |
libseccomp (Ubuntu): status |
New |
Triaged |
|
| 2017-09-22 01:23:35 |
Tyler Hicks |
libseccomp (Ubuntu): status |
Triaged |
Fix Committed |
|
| 2017-09-22 06:27:36 |
Launchpad Janitor |
libseccomp (Ubuntu): status |
Fix Committed |
Fix Released |
|
| 2017-10-05 04:07:11 |
Tyler Hicks |
description |
A requirement for snappy is that a snap may be placed in developer mode which will put the security sandbox in complain mode such that violations against policy are logged, but permitted. In this manner learning tools can be written to parse the logs, etc and make developing on snappy easier.
Unfortunately with seccomp only SCMP_ACT_KILL logs to dmesg and while we can set complain mode to permit all calls, they are not logged at this time. I've discussed this with upstream and we are working together on the approach. This may require a kernel patch and an update to libseccomp, to filing this bug for now as a placeholder and we'll add other tasks as necessary.
UPDATE: ubuntu-core-launcher now supports the '@complain' directive that is a synonym for '@unrestricted' so people can at least turn on developer mode and not be blocked by seccomp. Proper complain mode for seccomp needs to still be implemented (this bug).
[Impact]
Snapd needs a way to log seccomp actions without blocking any syscalls in order to have a more useful complain mode. Such functionality has been acked upstream and patches are on their way into the Linux 4.14 kernel (backported to 4.12.0-13.14 in artful).
The corresponding libseccomp changes are still undergoing review (https://github.com/seccomp/libseccomp/pull/92). The pull request adds a number of new symbols and probably isn't appropriate to backport until upstream has acked the pull request. However, only a small part of that larger pull request is needed by snapd and that change can be safely backported since the only added symbol, the SCMP_ACT_LOG macro, must match the SECCOMP_RET_LOG macro that has already been approved and merged in the upstream Linux kernel.
[Test Case]
A large number of tests are ran as part of the libseccomp build. However, the "live" tests which test libseccomp with actual kernel enforcement are not ran at that time. They can be manually exercised to help catch any regressions. Note that on Artful, there's an existing test failure (20-live-basic_die%%002-00001):
$ sudo apt build-dep -y libseccomp
$ sudo apt install -y cython
$ apt source libseccomp
$ autoreconf -ivf && ./configure --enable-python && make check-build
$ (cd tests && ./regression -T live)
...
Test 20-live-basic_die%%002-00001 result: FAILURE 20-live-basic_die TRAP rc=159
...
Regression Test Summary
tests run: 12
tests skipped: 0
tests passed: 11
tests failed: 1
tests errored: 0
============================================================
Now we can build and run a small test program to test the SCMP_ACT_LOG action in the way that snapd wants to use it for developer mode:
$ sudo apt install -y libseccomp-dev
$ gcc -o lp1567597-test lp1567597-test.c -lseccomp
$ ./lp1567597-test
The exit code should be 0 and you should have an entry in the system log that looks like this:
audit: type=1326 audit(1505859630.994:69): auid=1000 uid=1000 gid=1000 ses=2 pid=18451 comm="lp1567597-test" exe="/home/tyhicks/lp1567597-test" sig=0 arch=c000003e syscall=2 compat=0 ip=0x7f547352c5c0 code=0x7ffc0000
[Regression Potential]
Relatively small since the core logic is in the kernel and we're only exposing the new action through libseccomp. The changes include smarts to query the kernel to see if the action is available in the kernel. Calling applications will not be able to use the action on older kernels that don't support it. |
A requirement for snappy is that a snap may be placed in developer mode which will put the security sandbox in complain mode such that violations against policy are logged, but permitted. In this manner learning tools can be written to parse the logs, etc and make developing on snappy easier.
Unfortunately with seccomp only SCMP_ACT_KILL logs to dmesg and while we can set complain mode to permit all calls, they are not logged at this time. I've discussed this with upstream and we are working together on the approach. This may require a kernel patch and an update to libseccomp, to filing this bug for now as a placeholder and we'll add other tasks as necessary.
UPDATE: ubuntu-core-launcher now supports the '@complain' directive that is a synonym for '@unrestricted' so people can at least turn on developer mode and not be blocked by seccomp. Proper complain mode for seccomp needs to still be implemented (this bug).
[Impact]
Snapd needs a way to log seccomp actions without blocking any syscalls in order to have a more useful complain mode. Such functionality has been acked upstream and patches are on their way into the Linux 4.14 kernel (backported to 4.12.0-13.14 in artful).
The corresponding libseccomp changes are still undergoing review (https://github.com/seccomp/libseccomp/pull/92). The pull request adds a number of new symbols and probably isn't appropriate to backport until upstream has acked the pull request. However, only a small part of that larger pull request is needed by snapd and that change can be safely backported since the only added symbol, the SCMP_ACT_LOG macro, must match the SECCOMP_RET_LOG macro that has already been approved and merged in the upstream Linux kernel.
[Test Case]
A large number of tests are ran as part of the libseccomp build. However, the "live" tests which test libseccomp with actual kernel enforcement are not ran at that time. They can be manually exercised to help catch any regressions. Note that on Artful, there's an existing test failure (20-live-basic_die%%002-00001):
$ sudo apt build-dep -y libseccomp
$ sudo apt install -y cython
$ apt source libseccomp
$ cd libseccomp-*
$ autoreconf -ivf && ./configure --enable-python && make check-build
$ (cd tests && ./regression -T live)
...
Test 20-live-basic_die%%002-00001 result: FAILURE 20-live-basic_die TRAP rc=159
...
Regression Test Summary
tests run: 12
tests skipped: 0
tests passed: 11
tests failed: 1
tests errored: 0
============================================================
Now we can build and run a small test program to test the SCMP_ACT_LOG action in the way that snapd wants to use it for developer mode:
$ sudo apt install -y libseccomp-dev
$ gcc -o lp1567597-test lp1567597-test.c -lseccomp
$ ./lp1567597-test
The exit code should be 0 and you should have an entry in the system log that looks like this:
audit: type=1326 audit(1505859630.994:69): auid=1000 uid=1000 gid=1000 ses=2 pid=18451 comm="lp1567597-test" exe="/home/tyhicks/lp1567597-test" sig=0 arch=c000003e syscall=2 compat=0 ip=0x7f547352c5c0 code=0x7ffc0000
[Regression Potential]
Relatively small since the core logic is in the kernel and we're only exposing the new action through libseccomp. The changes include smarts to query the kernel to see if the action is available in the kernel. Calling applications will not be able to use the action on older kernels that don't support it. |
|
| 2017-10-05 04:07:39 |
Tyler Hicks |
summary |
[FFe] implement 'complain mode' in seccomp for developer mode with snaps |
implement 'complain mode' in seccomp for developer mode with snaps |
|
| 2017-10-05 04:10:39 |
Tyler Hicks |
nominated for series |
|
Ubuntu Zesty |
|
| 2017-10-05 04:10:39 |
Tyler Hicks |
bug task added |
|
linux (Ubuntu Zesty) |
|
| 2017-10-05 04:10:39 |
Tyler Hicks |
bug task added |
|
libseccomp (Ubuntu Zesty) |
|
| 2017-10-05 04:10:39 |
Tyler Hicks |
nominated for series |
|
Ubuntu Xenial |
|
| 2017-10-05 04:10:39 |
Tyler Hicks |
bug task added |
|
linux (Ubuntu Xenial) |
|
| 2017-10-05 04:10:39 |
Tyler Hicks |
bug task added |
|
libseccomp (Ubuntu Xenial) |
|
| 2017-10-05 04:10:48 |
Tyler Hicks |
libseccomp (Ubuntu Xenial): assignee |
|
Tyler Hicks (tyhicks) |
|
| 2017-10-05 04:10:50 |
Tyler Hicks |
libseccomp (Ubuntu Zesty): assignee |
|
Tyler Hicks (tyhicks) |
|
| 2017-10-05 04:10:54 |
Tyler Hicks |
libseccomp (Ubuntu Xenial): status |
New |
In Progress |
|
| 2017-10-05 04:10:58 |
Tyler Hicks |
libseccomp (Ubuntu Zesty): status |
New |
In Progress |
|
| 2017-10-05 04:11:00 |
Tyler Hicks |
linux (Ubuntu Xenial): assignee |
|
Tyler Hicks (tyhicks) |
|
| 2017-10-05 04:11:02 |
Tyler Hicks |
linux (Ubuntu Zesty): assignee |
|
Tyler Hicks (tyhicks) |
|
| 2017-10-05 04:11:07 |
Tyler Hicks |
linux (Ubuntu Xenial): status |
New |
In Progress |
|
| 2017-10-05 04:11:11 |
Tyler Hicks |
linux (Ubuntu Zesty): status |
New |
In Progress |
|
| 2017-10-05 04:14:05 |
Tyler Hicks |
description |
A requirement for snappy is that a snap may be placed in developer mode which will put the security sandbox in complain mode such that violations against policy are logged, but permitted. In this manner learning tools can be written to parse the logs, etc and make developing on snappy easier.
Unfortunately with seccomp only SCMP_ACT_KILL logs to dmesg and while we can set complain mode to permit all calls, they are not logged at this time. I've discussed this with upstream and we are working together on the approach. This may require a kernel patch and an update to libseccomp, to filing this bug for now as a placeholder and we'll add other tasks as necessary.
UPDATE: ubuntu-core-launcher now supports the '@complain' directive that is a synonym for '@unrestricted' so people can at least turn on developer mode and not be blocked by seccomp. Proper complain mode for seccomp needs to still be implemented (this bug).
[Impact]
Snapd needs a way to log seccomp actions without blocking any syscalls in order to have a more useful complain mode. Such functionality has been acked upstream and patches are on their way into the Linux 4.14 kernel (backported to 4.12.0-13.14 in artful).
The corresponding libseccomp changes are still undergoing review (https://github.com/seccomp/libseccomp/pull/92). The pull request adds a number of new symbols and probably isn't appropriate to backport until upstream has acked the pull request. However, only a small part of that larger pull request is needed by snapd and that change can be safely backported since the only added symbol, the SCMP_ACT_LOG macro, must match the SECCOMP_RET_LOG macro that has already been approved and merged in the upstream Linux kernel.
[Test Case]
A large number of tests are ran as part of the libseccomp build. However, the "live" tests which test libseccomp with actual kernel enforcement are not ran at that time. They can be manually exercised to help catch any regressions. Note that on Artful, there's an existing test failure (20-live-basic_die%%002-00001):
$ sudo apt build-dep -y libseccomp
$ sudo apt install -y cython
$ apt source libseccomp
$ cd libseccomp-*
$ autoreconf -ivf && ./configure --enable-python && make check-build
$ (cd tests && ./regression -T live)
...
Test 20-live-basic_die%%002-00001 result: FAILURE 20-live-basic_die TRAP rc=159
...
Regression Test Summary
tests run: 12
tests skipped: 0
tests passed: 11
tests failed: 1
tests errored: 0
============================================================
Now we can build and run a small test program to test the SCMP_ACT_LOG action in the way that snapd wants to use it for developer mode:
$ sudo apt install -y libseccomp-dev
$ gcc -o lp1567597-test lp1567597-test.c -lseccomp
$ ./lp1567597-test
The exit code should be 0 and you should have an entry in the system log that looks like this:
audit: type=1326 audit(1505859630.994:69): auid=1000 uid=1000 gid=1000 ses=2 pid=18451 comm="lp1567597-test" exe="/home/tyhicks/lp1567597-test" sig=0 arch=c000003e syscall=2 compat=0 ip=0x7f547352c5c0 code=0x7ffc0000
[Regression Potential]
Relatively small since the core logic is in the kernel and we're only exposing the new action through libseccomp. The changes include smarts to query the kernel to see if the action is available in the kernel. Calling applications will not be able to use the action on older kernels that don't support it. |
A requirement for snappy is that a snap may be placed in developer mode which will put the security sandbox in complain mode such that violations against policy are logged, but permitted. In this manner learning tools can be written to parse the logs, etc and make developing on snappy easier.
Unfortunately with seccomp only SCMP_ACT_KILL logs to dmesg and while we can set complain mode to permit all calls, they are not logged at this time. I've discussed this with upstream and we are working together on the approach. This may require a kernel patch and an update to libseccomp, to filing this bug for now as a placeholder and we'll add other tasks as necessary.
UPDATE: ubuntu-core-launcher now supports the '@complain' directive that is a synonym for '@unrestricted' so people can at least turn on developer mode and not be blocked by seccomp. Proper complain mode for seccomp needs to still be implemented (this bug).
[Impact]
Snapd needs a way to log seccomp actions without blocking any syscalls in order to have a more useful complain mode. Such functionality has been acked upstream and patches are on their way into the Linux 4.14 kernel (backported to 4.12.0-13.14 in artful).
The corresponding libseccomp changes are still undergoing review (https://github.com/seccomp/libseccomp/pull/92). The pull request adds a number of new symbols and probably isn't appropriate to backport until upstream has acked the pull request. However, only a small part of that larger pull request is needed by snapd and that change can be safely backported since the only added symbol, the SCMP_ACT_LOG macro, must match the SECCOMP_RET_LOG macro that has already been approved and merged in the upstream Linux kernel.
[Test Case]
A large number of tests are ran as part of the libseccomp build. However, the "live" tests which test libseccomp with actual kernel enforcement are not ran at that time. They can be manually exercised to help catch any regressions. Note that on Artful, there's an existing test failure (20-live-basic_die%%002-00001):
$ sudo apt build-dep -y libseccomp
$ sudo apt install -y cython
$ apt source libseccomp
$ cd libseccomp-*
$ autoreconf -ivf && ./configure --enable-python && make check-build
$ (cd tests && ./regression -T live)
All tests should pass on zesty (12 tests) and xenial (10 tests). On artful, you'll see one pre-existing failure:
...
Test 20-live-basic_die%%002-00001 result: FAILURE 20-live-basic_die TRAP rc=159
...
Regression Test Summary
tests run: 12
tests skipped: 0
tests passed: 11
tests failed: 1
tests errored: 0
============================================================
Now we can build and run a small test program to test the SCMP_ACT_LOG action in the way that snapd wants to use it for developer mode:
$ sudo apt install -y libseccomp-dev
$ gcc -o lp1567597-test lp1567597-test.c -lseccomp
$ ./lp1567597-test
The exit code should be 0 and you should have an entry in the system log that looks like this:
audit: type=1326 audit(1505859630.994:69): auid=1000 uid=1000 gid=1000 ses=2 pid=18451 comm="lp1567597-test" exe="/home/tyhicks/lp1567597-test" sig=0 arch=c000003e syscall=2 compat=0 ip=0x7f547352c5c0 code=0x7ffc0000
[Regression Potential]
Relatively small since the core logic is in the kernel and we're only exposing the new action through libseccomp. The changes include smarts to query the kernel to see if the action is available in the kernel. Calling applications will not be able to use the action on older kernels that don't support it. |
|
| 2017-10-05 05:57:56 |
Tyler Hicks |
description |
A requirement for snappy is that a snap may be placed in developer mode which will put the security sandbox in complain mode such that violations against policy are logged, but permitted. In this manner learning tools can be written to parse the logs, etc and make developing on snappy easier.
Unfortunately with seccomp only SCMP_ACT_KILL logs to dmesg and while we can set complain mode to permit all calls, they are not logged at this time. I've discussed this with upstream and we are working together on the approach. This may require a kernel patch and an update to libseccomp, to filing this bug for now as a placeholder and we'll add other tasks as necessary.
UPDATE: ubuntu-core-launcher now supports the '@complain' directive that is a synonym for '@unrestricted' so people can at least turn on developer mode and not be blocked by seccomp. Proper complain mode for seccomp needs to still be implemented (this bug).
[Impact]
Snapd needs a way to log seccomp actions without blocking any syscalls in order to have a more useful complain mode. Such functionality has been acked upstream and patches are on their way into the Linux 4.14 kernel (backported to 4.12.0-13.14 in artful).
The corresponding libseccomp changes are still undergoing review (https://github.com/seccomp/libseccomp/pull/92). The pull request adds a number of new symbols and probably isn't appropriate to backport until upstream has acked the pull request. However, only a small part of that larger pull request is needed by snapd and that change can be safely backported since the only added symbol, the SCMP_ACT_LOG macro, must match the SECCOMP_RET_LOG macro that has already been approved and merged in the upstream Linux kernel.
[Test Case]
A large number of tests are ran as part of the libseccomp build. However, the "live" tests which test libseccomp with actual kernel enforcement are not ran at that time. They can be manually exercised to help catch any regressions. Note that on Artful, there's an existing test failure (20-live-basic_die%%002-00001):
$ sudo apt build-dep -y libseccomp
$ sudo apt install -y cython
$ apt source libseccomp
$ cd libseccomp-*
$ autoreconf -ivf && ./configure --enable-python && make check-build
$ (cd tests && ./regression -T live)
All tests should pass on zesty (12 tests) and xenial (10 tests). On artful, you'll see one pre-existing failure:
...
Test 20-live-basic_die%%002-00001 result: FAILURE 20-live-basic_die TRAP rc=159
...
Regression Test Summary
tests run: 12
tests skipped: 0
tests passed: 11
tests failed: 1
tests errored: 0
============================================================
Now we can build and run a small test program to test the SCMP_ACT_LOG action in the way that snapd wants to use it for developer mode:
$ sudo apt install -y libseccomp-dev
$ gcc -o lp1567597-test lp1567597-test.c -lseccomp
$ ./lp1567597-test
The exit code should be 0 and you should have an entry in the system log that looks like this:
audit: type=1326 audit(1505859630.994:69): auid=1000 uid=1000 gid=1000 ses=2 pid=18451 comm="lp1567597-test" exe="/home/tyhicks/lp1567597-test" sig=0 arch=c000003e syscall=2 compat=0 ip=0x7f547352c5c0 code=0x7ffc0000
[Regression Potential]
Relatively small since the core logic is in the kernel and we're only exposing the new action through libseccomp. The changes include smarts to query the kernel to see if the action is available in the kernel. Calling applications will not be able to use the action on older kernels that don't support it. |
A requirement for snappy is that a snap may be placed in developer mode which will put the security sandbox in complain mode such that violations against policy are logged, but permitted. In this manner learning tools can be written to parse the logs, etc and make developing on snappy easier.
Unfortunately with seccomp only SCMP_ACT_KILL logs to dmesg and while we can set complain mode to permit all calls, they are not logged at this time. I've discussed this with upstream and we are working together on the approach. This may require a kernel patch and an update to libseccomp, to filing this bug for now as a placeholder and we'll add other tasks as necessary.
UPDATE: ubuntu-core-launcher now supports the '@complain' directive that is a synonym for '@unrestricted' so people can at least turn on developer mode and not be blocked by seccomp. Proper complain mode for seccomp needs to still be implemented (this bug).
[Impact]
Snapd needs a way to log seccomp actions without blocking any syscalls in order to have a more useful complain mode. Such functionality has been acked upstream and patches are on their way into the Linux 4.14 kernel (backported to 4.12.0-13.14 in artful).
The corresponding libseccomp changes are still undergoing review (https://github.com/seccomp/libseccomp/pull/92). The pull request adds a number of new symbols and probably isn't appropriate to backport until upstream has acked the pull request. However, only a small part of that larger pull request is needed by snapd and that change can be safely backported since the only added symbol, the SCMP_ACT_LOG macro, must match the SECCOMP_RET_LOG macro that has already been approved and merged in the upstream Linux kernel.
[Test Case]
A large number of tests are ran as part of the libseccomp build. However, the "live" tests which test libseccomp with actual kernel enforcement are not ran at that time. They can be manually exercised to help catch any regressions. Note that on Artful, there's an existing test failure (20-live-basic_die%%002-00001):
$ sudo apt build-dep -y libseccomp
$ sudo apt install -y cython
$ apt source libseccomp
$ cd libseccomp-*
$ autoreconf -ivf && ./configure --enable-python && make check-build
$ (cd tests && ./regression -T live)
All tests should pass on zesty (12 tests) and xenial (10 tests). On artful, you'll see one pre-existing failure:
...
Test 20-live-basic_die%%002-00001 result: FAILURE 20-live-basic_die TRAP rc=159
...
Regression Test Summary
tests run: 12
tests skipped: 0
tests passed: 11
tests failed: 1
tests errored: 0
============================================================
Now we can build and run a small test program to test the SCMP_ACT_LOG action in the way that snapd wants to use it for developer mode:
$ sudo apt install -y libseccomp-dev
$ gcc -o lp1567597-test lp1567597-test.c -lseccomp
$ ./lp1567597-test
With a kernel that contains the logging patches and an updated libseccomp, the exit code should be 0 and you should have an entry in the system log that looks like this:
audit: type=1326 audit(1505859630.994:69): auid=1000 uid=1000 gid=1000 ses=2 pid=18451 comm="lp1567597-test" exe="/home/tyhicks/lp1567597-test" sig=0 arch=c000003e syscall=2 compat=0 ip=0x7f547352c5c0 code=0x7ffc0000
If you have an updated libseccomp with an old kernel, you'll see that seccomp_init() fails due to the added compatibility check inside of libseccomp determines that the kernel doesn't have proper support for the new log action:
$ ./lp1567597-test
ERROR: seccomp_init: Invalid argument
[Regression Potential]
Relatively small since the core logic is in the kernel and we're only exposing the new action through libseccomp. The changes include smarts to query the kernel to see if the action is available in the kernel. Calling applications will not be able to use the action on older kernels that don't support it. |
|
| 2017-10-06 02:15:21 |
Tyler Hicks |
snappy: status |
Confirmed |
In Progress |
|
| 2017-10-06 02:28:18 |
Tyler Hicks |
removed subscriber Ubuntu Release Team |
|
|
|
| 2017-10-06 04:02:20 |
Tyler Hicks |
description |
A requirement for snappy is that a snap may be placed in developer mode which will put the security sandbox in complain mode such that violations against policy are logged, but permitted. In this manner learning tools can be written to parse the logs, etc and make developing on snappy easier.
Unfortunately with seccomp only SCMP_ACT_KILL logs to dmesg and while we can set complain mode to permit all calls, they are not logged at this time. I've discussed this with upstream and we are working together on the approach. This may require a kernel patch and an update to libseccomp, to filing this bug for now as a placeholder and we'll add other tasks as necessary.
UPDATE: ubuntu-core-launcher now supports the '@complain' directive that is a synonym for '@unrestricted' so people can at least turn on developer mode and not be blocked by seccomp. Proper complain mode for seccomp needs to still be implemented (this bug).
[Impact]
Snapd needs a way to log seccomp actions without blocking any syscalls in order to have a more useful complain mode. Such functionality has been acked upstream and patches are on their way into the Linux 4.14 kernel (backported to 4.12.0-13.14 in artful).
The corresponding libseccomp changes are still undergoing review (https://github.com/seccomp/libseccomp/pull/92). The pull request adds a number of new symbols and probably isn't appropriate to backport until upstream has acked the pull request. However, only a small part of that larger pull request is needed by snapd and that change can be safely backported since the only added symbol, the SCMP_ACT_LOG macro, must match the SECCOMP_RET_LOG macro that has already been approved and merged in the upstream Linux kernel.
[Test Case]
A large number of tests are ran as part of the libseccomp build. However, the "live" tests which test libseccomp with actual kernel enforcement are not ran at that time. They can be manually exercised to help catch any regressions. Note that on Artful, there's an existing test failure (20-live-basic_die%%002-00001):
$ sudo apt build-dep -y libseccomp
$ sudo apt install -y cython
$ apt source libseccomp
$ cd libseccomp-*
$ autoreconf -ivf && ./configure --enable-python && make check-build
$ (cd tests && ./regression -T live)
All tests should pass on zesty (12 tests) and xenial (10 tests). On artful, you'll see one pre-existing failure:
...
Test 20-live-basic_die%%002-00001 result: FAILURE 20-live-basic_die TRAP rc=159
...
Regression Test Summary
tests run: 12
tests skipped: 0
tests passed: 11
tests failed: 1
tests errored: 0
============================================================
Now we can build and run a small test program to test the SCMP_ACT_LOG action in the way that snapd wants to use it for developer mode:
$ sudo apt install -y libseccomp-dev
$ gcc -o lp1567597-test lp1567597-test.c -lseccomp
$ ./lp1567597-test
With a kernel that contains the logging patches and an updated libseccomp, the exit code should be 0 and you should have an entry in the system log that looks like this:
audit: type=1326 audit(1505859630.994:69): auid=1000 uid=1000 gid=1000 ses=2 pid=18451 comm="lp1567597-test" exe="/home/tyhicks/lp1567597-test" sig=0 arch=c000003e syscall=2 compat=0 ip=0x7f547352c5c0 code=0x7ffc0000
If you have an updated libseccomp with an old kernel, you'll see that seccomp_init() fails due to the added compatibility check inside of libseccomp determines that the kernel doesn't have proper support for the new log action:
$ ./lp1567597-test
ERROR: seccomp_init: Invalid argument
[Regression Potential]
Relatively small since the core logic is in the kernel and we're only exposing the new action through libseccomp. The changes include smarts to query the kernel to see if the action is available in the kernel. Calling applications will not be able to use the action on older kernels that don't support it. |
A requirement for snappy is that a snap may be placed in developer mode which will put the security sandbox in complain mode such that violations against policy are logged, but permitted. In this manner learning tools can be written to parse the logs, etc and make developing on snappy easier.
Unfortunately with seccomp only SCMP_ACT_KILL logs to dmesg and while we can set complain mode to permit all calls, they are not logged at this time. I've discussed this with upstream and we are working together on the approach. This may require a kernel patch and an update to libseccomp, to filing this bug for now as a placeholder and we'll add other tasks as necessary.
UPDATE: ubuntu-core-launcher now supports the '@complain' directive that is a synonym for '@unrestricted' so people can at least turn on developer mode and not be blocked by seccomp. Proper complain mode for seccomp needs to still be implemented (this bug).
[Impact]
Snapd needs a way to log seccomp actions without blocking any syscalls in order to have a more useful complain mode. Such functionality has been acked upstream and patches are on their way into the Linux 4.14 kernel (backported to 4.12.0-13.14 in artful).
The corresponding libseccomp changes are still undergoing review (https://github.com/seccomp/libseccomp/pull/92). The pull request adds a number of new symbols and probably isn't appropriate to backport until upstream has acked the pull request. However, only a small part of that larger pull request is needed by snapd and that change can be safely backported since the only added symbol, the SCMP_ACT_LOG macro, must match the SECCOMP_RET_LOG macro that has already been approved and merged in the upstream Linux kernel.
[libseccomp Test Case]
A large number of tests are ran as part of the libseccomp build. However, the "live" tests which test libseccomp with actual kernel enforcement are not ran at that time. They can be manually exercised to help catch any regressions. Note that on Artful, there's an existing test failure (20-live-basic_die%%002-00001):
$ sudo apt build-dep -y libseccomp
$ sudo apt install -y cython
$ apt source libseccomp
$ cd libseccomp-*
$ autoreconf -ivf && ./configure --enable-python && make check-build
$ (cd tests && ./regression -T live)
All tests should pass on zesty (12 tests) and xenial (10 tests). On artful, you'll see one pre-existing failure:
...
Test 20-live-basic_die%%002-00001 result: FAILURE 20-live-basic_die TRAP rc=159
...
Regression Test Summary
tests run: 12
tests skipped: 0
tests passed: 11
tests failed: 1
tests errored: 0
============================================================
----------------------------
Now we can build and run a small test program to test the SCMP_ACT_LOG action in the way that snapd wants to use it for developer mode:
$ sudo apt install -y libseccomp-dev
$ gcc -o lp1567597-test lp1567597-test.c -lseccomp
$ ./lp1567597-test
With a kernel that contains the logging patches and an updated libseccomp, the exit code should be 0 and you should have an entry in the system log that looks like this:
audit: type=1326 audit(1505859630.994:69): auid=1000 uid=1000 gid=1000 ses=2 pid=18451 comm="lp1567597-test" exe="/home/tyhicks/lp1567597-test" sig=0 arch=c000003e syscall=2 compat=0 ip=0x7f547352c5c0 code=0x7ffc0000
If you have an updated libseccomp with an old kernel, you'll see that seccomp_init() fails due to the added compatibility check inside of libseccomp determines that the kernel doesn't have proper support for the new log action:
$ ./lp1567597-test
ERROR: seccomp_init: Invalid argument
[Linux Kernel Test Case]
All of the libseccomp test cases apply here.
----------------------------
Running the seccomp kernel selftests is also a great to exercise seccomp and the kernel patch set proposed for the SRU includes additional seccomp selftests. To build, enter into the root of the kernel source tree and build the seccomp test binary:
$ make -C tools/testing/selftests TARGETS=seccomp
Now you can execute tools/testing/selftests/seccomp/seccomp_bpf or even copy it to a test machine and run it there. On Xenial, 54/54 tests should pass and 58/58 should pass on Zesty.
[Regression Potential]
Relatively small since the core logic is in the kernel and we're only exposing the new action through libseccomp. The changes include smarts to query the kernel to see if the action is available in the kernel. Calling applications will not be able to use the action on older kernels that don't support it. |
|
| 2017-10-06 04:21:04 |
Tyler Hicks |
description |
A requirement for snappy is that a snap may be placed in developer mode which will put the security sandbox in complain mode such that violations against policy are logged, but permitted. In this manner learning tools can be written to parse the logs, etc and make developing on snappy easier.
Unfortunately with seccomp only SCMP_ACT_KILL logs to dmesg and while we can set complain mode to permit all calls, they are not logged at this time. I've discussed this with upstream and we are working together on the approach. This may require a kernel patch and an update to libseccomp, to filing this bug for now as a placeholder and we'll add other tasks as necessary.
UPDATE: ubuntu-core-launcher now supports the '@complain' directive that is a synonym for '@unrestricted' so people can at least turn on developer mode and not be blocked by seccomp. Proper complain mode for seccomp needs to still be implemented (this bug).
[Impact]
Snapd needs a way to log seccomp actions without blocking any syscalls in order to have a more useful complain mode. Such functionality has been acked upstream and patches are on their way into the Linux 4.14 kernel (backported to 4.12.0-13.14 in artful).
The corresponding libseccomp changes are still undergoing review (https://github.com/seccomp/libseccomp/pull/92). The pull request adds a number of new symbols and probably isn't appropriate to backport until upstream has acked the pull request. However, only a small part of that larger pull request is needed by snapd and that change can be safely backported since the only added symbol, the SCMP_ACT_LOG macro, must match the SECCOMP_RET_LOG macro that has already been approved and merged in the upstream Linux kernel.
[libseccomp Test Case]
A large number of tests are ran as part of the libseccomp build. However, the "live" tests which test libseccomp with actual kernel enforcement are not ran at that time. They can be manually exercised to help catch any regressions. Note that on Artful, there's an existing test failure (20-live-basic_die%%002-00001):
$ sudo apt build-dep -y libseccomp
$ sudo apt install -y cython
$ apt source libseccomp
$ cd libseccomp-*
$ autoreconf -ivf && ./configure --enable-python && make check-build
$ (cd tests && ./regression -T live)
All tests should pass on zesty (12 tests) and xenial (10 tests). On artful, you'll see one pre-existing failure:
...
Test 20-live-basic_die%%002-00001 result: FAILURE 20-live-basic_die TRAP rc=159
...
Regression Test Summary
tests run: 12
tests skipped: 0
tests passed: 11
tests failed: 1
tests errored: 0
============================================================
----------------------------
Now we can build and run a small test program to test the SCMP_ACT_LOG action in the way that snapd wants to use it for developer mode:
$ sudo apt install -y libseccomp-dev
$ gcc -o lp1567597-test lp1567597-test.c -lseccomp
$ ./lp1567597-test
With a kernel that contains the logging patches and an updated libseccomp, the exit code should be 0 and you should have an entry in the system log that looks like this:
audit: type=1326 audit(1505859630.994:69): auid=1000 uid=1000 gid=1000 ses=2 pid=18451 comm="lp1567597-test" exe="/home/tyhicks/lp1567597-test" sig=0 arch=c000003e syscall=2 compat=0 ip=0x7f547352c5c0 code=0x7ffc0000
If you have an updated libseccomp with an old kernel, you'll see that seccomp_init() fails due to the added compatibility check inside of libseccomp determines that the kernel doesn't have proper support for the new log action:
$ ./lp1567597-test
ERROR: seccomp_init: Invalid argument
[Linux Kernel Test Case]
All of the libseccomp test cases apply here.
----------------------------
Running the seccomp kernel selftests is also a great to exercise seccomp and the kernel patch set proposed for the SRU includes additional seccomp selftests. To build, enter into the root of the kernel source tree and build the seccomp test binary:
$ make -C tools/testing/selftests TARGETS=seccomp
Now you can execute tools/testing/selftests/seccomp/seccomp_bpf or even copy it to a test machine and run it there. On Xenial, 54/54 tests should pass and 58/58 should pass on Zesty.
[Regression Potential]
Relatively small since the core logic is in the kernel and we're only exposing the new action through libseccomp. The changes include smarts to query the kernel to see if the action is available in the kernel. Calling applications will not be able to use the action on older kernels that don't support it. |
A requirement for snappy is that a snap may be placed in developer mode which will put the security sandbox in complain mode such that violations against policy are logged, but permitted. In this manner learning tools can be written to parse the logs, etc and make developing on snappy easier.
Unfortunately with seccomp only SCMP_ACT_KILL logs to dmesg and while we can set complain mode to permit all calls, they are not logged at this time. I've discussed this with upstream and we are working together on the approach. This may require a kernel patch and an update to libseccomp, to filing this bug for now as a placeholder and we'll add other tasks as necessary.
UPDATE: ubuntu-core-launcher now supports the '@complain' directive that is a synonym for '@unrestricted' so people can at least turn on developer mode and not be blocked by seccomp. Proper complain mode for seccomp needs to still be implemented (this bug).
[Impact]
Snapd needs a way to log seccomp actions without blocking any syscalls in order to have a more useful complain mode. Such functionality has been acked upstream and patches are on their way into the Linux 4.14 kernel (backported to 4.12.0-13.14 in artful).
The corresponding libseccomp changes are still undergoing review (https://github.com/seccomp/libseccomp/pull/92). The pull request adds a number of new symbols and probably isn't appropriate to backport until upstream has acked the pull request. However, only a small part of that larger pull request is needed by snapd and that change can be safely backported since the only added symbol, the SCMP_ACT_LOG macro, must match the SECCOMP_RET_LOG macro that has already been approved and merged in the upstream Linux kernel.
[libseccomp Test Case]
A large number of tests are ran as part of the libseccomp build. However, the "live" tests which test libseccomp with actual kernel enforcement are not ran at that time. They can be manually exercised to help catch any regressions. Note that on Artful, there's an existing test failure (20-live-basic_die%%002-00001):
$ sudo apt build-dep -y libseccomp
$ sudo apt install -y cython
$ apt source libseccomp
$ cd libseccomp-*
$ autoreconf -ivf && ./configure --enable-python && make check-build
$ (cd tests && ./regression -T live)
All tests should pass on zesty (12 tests) and xenial (10 tests). On artful, you'll see one pre-existing failure:
...
Test 20-live-basic_die%%002-00001 result: FAILURE 20-live-basic_die TRAP rc=159
...
Regression Test Summary
tests run: 12
tests skipped: 0
tests passed: 11
tests failed: 1
tests errored: 0
============================================================
----------------------------
Now we can build and run a small test program to test the SCMP_ACT_LOG action in the way that snapd wants to use it for developer mode:
$ sudo apt install -y libseccomp-dev
$ gcc -o lp1567597-test lp1567597-test.c -lseccomp
$ ./lp1567597-test
With a kernel that contains the logging patches and an updated libseccomp, the exit code should be 0 and you should have an entry in the system log that looks like this:
audit: type=1326 audit(1505859630.994:69): auid=1000 uid=1000 gid=1000 ses=2 pid=18451 comm="lp1567597-test" exe="/home/tyhicks/lp1567597-test" sig=0 arch=c000003e syscall=2 compat=0 ip=0x7f547352c5c0 code=0x7ffc0000
If you have an updated libseccomp with an old kernel, you'll see that seccomp_init() fails due to the added compatibility check inside of libseccomp determines that the kernel doesn't have proper support for the new log action:
$ ./lp1567597-test
ERROR: seccomp_init: Invalid argument
[Linux Kernel Test Case]
All of the libseccomp test cases apply here.
----------------------------
Running the seccomp kernel selftests is also a great to exercise seccomp and the kernel patch set proposed for the SRU includes additional seccomp selftests. To build, enter into the root of the kernel source tree and build the seccomp test binary:
$ make -C tools/testing/selftests TARGETS=seccomp
Now you can execute tools/testing/selftests/seccomp/seccomp_bpf or even copy it to a test machine and run it there. On Xenial, 54/54 tests should pass and 58/58 should pass on Zesty.
----------------------------
Now we can run a single test to verify that SECCOMP_RET_LOG is logged when the seccomp BPF evaluates to that action. First, verify that "log" is listed in the actions_logged sysctl:
$ cat /proc/sys/kernel/seccomp/actions_logged
kill trap errno trace log
Now, build and run the test program:
$ gcc -o lp1567597-kernel-test lp1567597-kernel-test.c
$ ./1567597-kernel-test
SUCCESS!
It should have generated a message like this in /var/log/syslog:
audit: type=1326 audit(1507263417.752:60): auid=1000 uid=1000 gid=1000 ses=2 pid=3117 comm="lp1567597-kerne" exe="/home/tyhicks/lp1567597-kernel-test" sig=0 arch=c000003e syscall=39 compat=0 ip=0x7f1d2d8409f9 code=0x7ffc0000
Disable "log" logging in the sysctl:
$ echo kill trap errno trace | sudo tee /proc/sys/kernel/seccomp/actions_logged
kill trap errno trace
Rerun the test program and ensure that nothing was logged this time.
[Regression Potential]
Relatively small for libseccomp since the core logic is in the kernel and we're only exposing the new action through libseccomp. The changes include smarts to query the kernel to see if the action is available in the kernel. Calling applications will not be able to use the action on older kernels that don't support it.
The kernel patches received a lot of review between Kees and some others interested in improved seccomp logging. I authored the patches and feel comfortable/confident with my backported versions. They do not change the behavior of seccomp logging by default but offer ways applications to opt into more logging and, on the flipside, ways for the administrator to quiet any additional logging. |
|
| 2017-10-06 18:21:39 |
Thadeu Lima de Souza Cascardo |
linux (Ubuntu Xenial): status |
In Progress |
Fix Committed |
|
| 2017-10-06 18:27:18 |
Thadeu Lima de Souza Cascardo |
linux (Ubuntu Zesty): status |
In Progress |
Fix Committed |
|
| 2017-10-11 18:43:46 |
Tyler Hicks |
attachment added |
|
lp1567597-kernel-test.c https://bugs.launchpad.net/snappy/+bug/1567597/+attachment/4967858/+files/lp1567597-kernel-test.c |
|
| 2017-10-12 16:28:46 |
Brian Murray |
libseccomp (Ubuntu Zesty): status |
In Progress |
Fix Committed |
|
| 2017-10-12 16:28:50 |
Brian Murray |
bug |
|
|
added subscriber Ubuntu Stable Release Updates Team |
| 2017-10-12 16:28:53 |
Brian Murray |
bug |
|
|
added subscriber SRU Verification |
| 2017-10-12 16:28:59 |
Brian Murray |
tags |
|
verification-needed verification-needed-zesty |
|
| 2017-10-16 16:12:49 |
Tyler Hicks |
tags |
verification-needed verification-needed-zesty |
verification-done-zesty verification-needed |
|
| 2017-10-18 08:56:54 |
Kleber Sacilotto de Souza |
tags |
verification-done-zesty verification-needed |
verification-done-zesty verification-needed verification-needed-xenial |
|
| 2017-10-18 23:12:25 |
Tyler Hicks |
tags |
verification-done-zesty verification-needed verification-needed-xenial |
verification-done-xenial verification-done-zesty verification-needed |
|
| 2017-10-18 23:12:58 |
Tyler Hicks |
tags |
verification-done-xenial verification-done-zesty verification-needed |
verification-done-xenial verification-done-zesty |
|
| 2017-10-19 17:49:08 |
Launchpad Janitor |
libseccomp (Ubuntu Zesty): status |
Fix Committed |
Fix Released |
|
| 2017-10-19 17:49:15 |
Brian Murray |
removed subscriber Ubuntu Stable Release Updates Team |
|
|
|
| 2017-10-30 19:26:53 |
Launchpad Janitor |
linux (Ubuntu Zesty): status |
Fix Committed |
Fix Released |
|
| 2017-10-30 19:26:53 |
Launchpad Janitor |
cve linked |
|
2017-1000252 |
|
| 2017-10-30 19:26:53 |
Launchpad Janitor |
cve linked |
|
2017-10663 |
|
| 2017-10-30 19:26:53 |
Launchpad Janitor |
cve linked |
|
2017-10911 |
|
| 2017-10-30 19:26:53 |
Launchpad Janitor |
cve linked |
|
2017-11176 |
|
| 2017-10-30 19:26:53 |
Launchpad Janitor |
cve linked |
|
2017-14340 |
|
| 2017-10-30 19:26:54 |
Launchpad Janitor |
linux (Ubuntu Zesty): status |
Fix Committed |
Fix Released |
|
| 2017-10-30 19:43:07 |
Launchpad Janitor |
linux (Ubuntu Xenial): status |
Fix Committed |
Fix Released |
|
| 2017-10-30 19:43:10 |
Launchpad Janitor |
linux (Ubuntu Xenial): status |
Fix Committed |
Fix Released |
|
| 2018-03-06 03:20:05 |
Jamie Strandboge |
libseccomp (Ubuntu Xenial): status |
In Progress |
Fix Released |
|
| 2019-03-25 10:55:25 |
Zygmunt Krynicki |
affects |
snappy |
snapd |
|
| 2019-03-25 10:55:32 |
Zygmunt Krynicki |
snapd: status |
In Progress |
Fix Released |
|
| 2019-07-24 21:21:16 |
Brad Figg |
tags |
verification-done-xenial verification-done-zesty |
cscc verification-done-xenial verification-done-zesty |
|
