New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

expose improved kernel logging features through libseccomp-golang #29

Open
wants to merge 5 commits into
base: master
from

Conversation

Projects
None yet
4 participants
@tyhicks

tyhicks commented Sep 21, 2017

This is a pull request that complements seccomp/libseccomp#92. It is not yet ready for merging as there's some pending work left to do for that libseccomp PR to allow applications, such as the libseccomp and libseccomp-golang test suites, to request/force a certain API level. See seccomp/libseccomp#92 (comment) for more context.

The SECCOMP_FILTER_FLAG_LOG filter flag and SECCOMP_RET_LOG action allow applications to have more control over what actions should be logged.

The tests added by this PR pass when run under a kernel that has support for the new filter flag and action and a libseccomp that has been built with seccomp/libseccomp#92. They fail otherwise, pending the API level changes that would allow the libseccomp-golang tests to request a certain API level.

@@ -67,16 +67,26 @@ const uint32_t C_ARCH_PPC64LE = SCMP_ARCH_PPC64LE;
const uint32_t C_ARCH_S390 = SCMP_ARCH_S390;
const uint32_t C_ARCH_S390X = SCMP_ARCH_S390X;
#ifndef SCMP_ACT_LOG
#define SCMP_ACT_LOG 0x7ffc0000U
#endif

This comment has been minimized.

@tyhicks

tyhicks Sep 21, 2017

Is this the right thing to do here? This is to allow a new libseccomp-golang to build with an older libseccomp which doesn't have SCMP_ACT_LOG support. Is it acceptable to fail the build if the installed libseccomp is not new enough or should I leave this #define here?

@tyhicks

tyhicks Sep 21, 2017

Is this the right thing to do here? This is to allow a new libseccomp-golang to build with an older libseccomp which doesn't have SCMP_ACT_LOG support. Is it acceptable to fail the build if the installed libseccomp is not new enough or should I leave this #define here?

This comment has been minimized.

@mheon

mheon Sep 21, 2017

Contributor

This matches what we're been doing elsewhere - we need to support building against older libseccomp, so defining if it's undefined is necessary. So yes, this is the correct thing to do, though it's not very convenient or good practice in general.

@mheon

mheon Sep 21, 2017

Contributor

This matches what we're been doing elsewhere - we need to support building against older libseccomp, so defining if it's undefined is necessary. So yes, this is the correct thing to do, though it's not very convenient or good practice in general.

// GetLogBit returns the current state the Log bit will be set to on the filter
// being loaded, or an error if an issue was encountered retrieving the value.
// The Log bit tells the kernel that all actions taken by the filter, with the
// exception of ActAllow, should be logged.

This comment has been minimized.

@mheon

mheon Sep 21, 2017

Contributor

Can you add something in the comment regarding a minimum required kernel version for this working?

@mheon

mheon Sep 21, 2017

Contributor

Can you add something in the comment regarding a minimum required kernel version for this working?

This comment has been minimized.

@tyhicks

tyhicks Sep 21, 2017

Yes, this is a good idea. There's, unfortunately, now a little uncertainty around which kernel release it'll be present in due to an unrelated issue. I'll update the comment as soon as there's some clarity.

@tyhicks

tyhicks Sep 21, 2017

Yes, this is a good idea. There's, unfortunately, now a little uncertainty around which kernel release it'll be present in due to an unrelated issue. I'll update the comment as soon as there's some clarity.

This comment has been minimized.

@tyhicks

tyhicks Oct 25, 2017

In the update to this PR, I've added a comment about the minimum API level required (3).

@tyhicks

tyhicks Oct 25, 2017

In the update to this PR, I've added a comment about the minimum API level required (3).

@@ -756,6 +777,18 @@ func (f *ScmpFilter) SetNoNewPrivsBit(state bool) error {
return f.setFilterAttr(filterAttrNNP, toSet)
}
// SetLogBit sets the state of the Log bit, which will be applied on filter
// load, or an error if an issue was encountered setting the value.

This comment has been minimized.

@mheon

mheon Sep 21, 2017

Contributor

Same as above, please add something about minimum kernel version where this will take effect. And/or minimum libseccomp version.

@mheon

mheon Sep 21, 2017

Contributor

Same as above, please add something about minimum kernel version where this will take effect. And/or minimum libseccomp version.

This comment has been minimized.

@tyhicks

tyhicks Sep 21, 2017

Sounds good.

@tyhicks

tyhicks Sep 21, 2017

Sounds good.

This comment has been minimized.

@tyhicks

tyhicks Oct 25, 2017

In the update to this PR, I've added a comment about the minimum API level required (3).

@tyhicks

tyhicks Oct 25, 2017

In the update to this PR, I've added a comment about the minimum API level required (3).

@@ -519,3 +531,64 @@ func TestRuleAddAndLoad(t *testing.T) {
t.Errorf("Syscall returned incorrect error code - likely not blocked by Seccomp!")
}
}
func TestLogAct(t *testing.T) {

This comment has been minimized.

@mheon

mheon Sep 21, 2017

Contributor

Can we skip this if the libseccomp version we build against is too low to have support? We have a function to grab library version we built against, it should be possible to skip the test if it's detected as too low.

@mheon

mheon Sep 21, 2017

Contributor

Can we skip this if the libseccomp version we build against is too low to have support? We have a function to grab library version we built against, it should be possible to skip the test if it's detected as too low.

This comment has been minimized.

@tyhicks

tyhicks Sep 21, 2017

Yes! Good idea. Unfortunately, it doesn't solve the case where libseccomp is "new" but the kernel is "old" but at least it improves the situation.

@tyhicks

tyhicks Sep 21, 2017

Yes! Good idea. Unfortunately, it doesn't solve the case where libseccomp is "new" but the kernel is "old" but at least it improves the situation.

This comment has been minimized.

@tyhicks

tyhicks Oct 25, 2017

The new API level support in libseccomp allows us to handle the case that I mentioned above. The updated PR now handles all combinations of new/old libseccomp-golang, new/old libseccomp, and new/old kernel.

@tyhicks

tyhicks Oct 25, 2017

The new API level support in libseccomp allows us to handle the case that I mentioned above. The updated PR now handles all combinations of new/old libseccomp-golang, new/old libseccomp, and new/old kernel.

@mheon

This comment has been minimized.

Show comment
Hide comment
@mheon

mheon Sep 21, 2017

Contributor

Have a few minor concerns mostly related to tests/comments, but overall looks fine.

Contributor

mheon commented Sep 21, 2017

Have a few minor concerns mostly related to tests/comments, but overall looks fine.

@mheon mheon self-assigned this Sep 21, 2017

@pcmoore

This comment has been minimized.

Show comment
Hide comment
@pcmoore

pcmoore Sep 21, 2017

Member

@tyhicks thanks for doing this.

@mheon thanks for reviewing, but please hold off on merging anything until we sort things out in the main repo.

Member

pcmoore commented Sep 21, 2017

@tyhicks thanks for doing this.

@mheon thanks for reviewing, but please hold off on merging anything until we sort things out in the main repo.

@mheon

This comment has been minimized.

Show comment
Hide comment
@mheon

mheon Sep 21, 2017

Contributor

@pcmoore Roger that, was going to ask about that. I'll mark this as WIP until we get support merged into the main library.

Contributor

mheon commented Sep 21, 2017

@pcmoore Roger that, was going to ask about that. I'll mark this as WIP until we get support merged into the main library.

@mheon mheon changed the title from expose improved kernel logging features through libseccomp-golang to [WIP] expose improved kernel logging features through libseccomp-golang Sep 21, 2017

@tyhicks

This comment has been minimized.

Show comment
Hide comment
@tyhicks

tyhicks Oct 25, 2017

@mheon @pcmoore Hello! I've updated this PR with API level bindings (in support of seccomp/libseccomp@e89d182) and I've updated the SCMP_FLTATR_CTL_LOG and SCMP_ACT_LOG related patches accordingly for API level support and to match what is nearly merged in seccomp/libseccomp#92.

tyhicks commented Oct 25, 2017

@mheon @pcmoore Hello! I've updated this PR with API level bindings (in support of seccomp/libseccomp@e89d182) and I've updated the SCMP_FLTATR_CTL_LOG and SCMP_ACT_LOG related patches accordingly for API level support and to match what is nearly merged in seccomp/libseccomp#92.

Show outdated Hide outdated seccomp.go
@@ -328,6 +334,21 @@ func GetLibraryVersion() (major, minor, micro uint) {
return verMajor, verMinor, verMicro
}
// GetApi returns the API level supported by the system.

This comment has been minimized.

@mheon

mheon Oct 25, 2017

Contributor

Can you give a brief description of what API levels there are in the comments for this and SetAPI?

@mheon

mheon Oct 25, 2017

Contributor

Can you give a brief description of what API levels there are in the comments for this and SetAPI?

This comment has been minimized.

@tyhicks

tyhicks Oct 25, 2017

I sure can. My reasoning for not including API level descriptions in libseccomp-golang was that they may become outdated because developers could easily forget to keep the descriptions updated when new API levels are added. The seccomp_api_get man page is probably going to be the most authoritative location for API level descriptions but I don't know how you feel about pointing to that man page from the function documentation.

@tyhicks

tyhicks Oct 25, 2017

I sure can. My reasoning for not including API level descriptions in libseccomp-golang was that they may become outdated because developers could easily forget to keep the descriptions updated when new API levels are added. The seccomp_api_get man page is probably going to be the most authoritative location for API level descriptions but I don't know how you feel about pointing to that man page from the function documentation.

This comment has been minimized.

@mheon

mheon Oct 25, 2017

Contributor

I'd be fine with directing people to a manpage. A link to the libseccomp github (if it's documented anywhere on there) would also be fine. I'd just like to give people a pointer as to what valid API levels look like.

@mheon

mheon Oct 25, 2017

Contributor

I'd be fine with directing people to a manpage. A link to the libseccomp github (if it's documented anywhere on there) would also be fine. I'd just like to give people a pointer as to what valid API levels look like.

@mheon

This comment has been minimized.

Show comment
Hide comment
@mheon

mheon Oct 25, 2017

Contributor

Can you add API level and/or library version checks in getFilterAttr() and setFilterAttr() for the new filterAttrLog? The library should catch it already, but it'd be nice to give a proper string error ("Setting the log bit is only supported in Libseccomp 2.3.3 with API level 3 set" or something similar). Doing a getAPI() call and returning an error if the API level call is not supported or the API level is too low should be sufficient.

Contributor

mheon commented Oct 25, 2017

Can you add API level and/or library version checks in getFilterAttr() and setFilterAttr() for the new filterAttrLog? The library should catch it already, but it'd be nice to give a proper string error ("Setting the log bit is only supported in Libseccomp 2.3.3 with API level 3 set" or something similar). Doing a getAPI() call and returning an error if the API level call is not supported or the API level is too low should be sufficient.

Show outdated Hide outdated seccomp.go

tyhicks added some commits Sep 21, 2017

golang: Add support for SCMP_FLTATR_CTL_LOG
Create a new scmpFilterAttr, filterAttrLog, to represent libseccomp's
SCMP_FLTATR_CTL_LOG.

A new set of getter and setter functions are created to set the log
filter attribute. They are named GetLogBit() and SetLogBit().

Signed-off-by: Tyler Hicks <tyhicks@canonical.com>
golang: Add filterAttrLog getter/setters test
Update TestFilterAttributeGettersAndSetters() to set the log filter flag
and then verify its value.

The log filter flag is not tested when libseccomp is not new enough to
support API level operations.

Signed-off-by: Tyler Hicks <tyhicks@canonical.com>
golang: Add API level bindings
Add bindings for getting and setting the libseccomp API level which was
added in the following libseccomp commit:

  commit e89d18205c7dcd7582f41051cd6389c9b12dfccf
  Author: Paul Moore <paul@paul-moore.com>
  Date:   Thu Sep 21 10:27:38 2017 -0400

      api: create an API level construct as part of the supported API

The added tests for getting and setting the API level detect if API
level support is available in libseccomp and tests the behavior of
GetApi() and SetApi() accordingly.

Signed-off-by: Tyler Hicks <tyhicks@canonical.com>
@tyhicks

This comment has been minimized.

Show comment
Hide comment
@tyhicks

tyhicks Oct 25, 2017

@mheon I've addressed all of your feedback. Here are the changes that I made:

  • Move ActLog declaration below ActLog
  • Point to seccomp_api_get(3) man page in GetApi() and SetApi() docs
  • Provide more helpful error messages when GetLogBit() or SetLogBit() fail due to libseccomp being too old or the API level being set too low
  • Update TestFilterAttributeGettersAndSetters() to call GetLogBit() and SetLogBit(), even when the API level is too low, and emit an "Ignoring failure" info message that includes the more helpful error messages mentioned above

tyhicks commented Oct 25, 2017

@mheon I've addressed all of your feedback. Here are the changes that I made:

  • Move ActLog declaration below ActLog
  • Point to seccomp_api_get(3) man page in GetApi() and SetApi() docs
  • Provide more helpful error messages when GetLogBit() or SetLogBit() fail due to libseccomp being too old or the API level being set too low
  • Update TestFilterAttributeGettersAndSetters() to call GetLogBit() and SetLogBit(), even when the API level is too low, and emit an "Ignoring failure" info message that includes the more helpful error messages mentioned above
@mheon

This comment has been minimized.

Show comment
Hide comment
@mheon

mheon Oct 25, 2017

Contributor

Code LGTM though I'd like to run some tests on my end to verify new functionality (and that we haven't broken earlier library versions). We're also still pending on final support landing in the library. Once that lands, ping me and I'll get this tested and merged.

Contributor

mheon commented Oct 25, 2017

Code LGTM though I'd like to run some tests on my end to verify new functionality (and that we haven't broken earlier library versions). We're also still pending on final support landing in the library. Once that lands, ping me and I'll get this tested and merged.

@tyhicks

This comment has been minimized.

Show comment
Hide comment
@tyhicks

tyhicks Oct 25, 2017

@mheon thanks! I'll describe the testing that I performed. I've tested with libseccomp-golang's check makefile target in the following scenarios:

  1. New libseccomp-golang with old libseccomp and old kernel
  2. New libseccomp-golang with new libseccomp and old kernel
  3. New libseccomp-golang with new libseccomp and new kernel

When I say "new", I mean that the project has been updated with the respective logging patches and, in the case of userspace projects, API level patches. By "old", I mean that API level and logging patches are not applied.

All tests pass for each scenario.

tyhicks commented Oct 25, 2017

@mheon thanks! I'll describe the testing that I performed. I've tested with libseccomp-golang's check makefile target in the following scenarios:

  1. New libseccomp-golang with old libseccomp and old kernel
  2. New libseccomp-golang with new libseccomp and old kernel
  3. New libseccomp-golang with new libseccomp and new kernel

When I say "new", I mean that the project has been updated with the respective logging patches and, in the case of userspace projects, API level patches. By "old", I mean that API level and logging patches are not applied.

All tests pass for each scenario.

@tyhicks

This comment has been minimized.

Show comment
Hide comment
@tyhicks

tyhicks Nov 1, 2017

@mheon just an FYI that the libseccomp changes all are merged. No changes to my libseccomp-golang branch are needed so it is ready for your testing. Thanks!

tyhicks commented Nov 1, 2017

@mheon just an FYI that the libseccomp changes all are merged. No changes to my libseccomp-golang branch are needed so it is ready for your testing. Thanks!

@mheon

This comment has been minimized.

Show comment
Hide comment
@mheon

mheon Nov 1, 2017

Contributor

Alright, I'll try and get this merged sometime tomorrow then. Thanks!

Contributor

mheon commented Nov 1, 2017

Alright, I'll try and get this merged sometime tomorrow then. Thanks!

@tyhicks tyhicks changed the title from [WIP] expose improved kernel logging features through libseccomp-golang to expose improved kernel logging features through libseccomp-golang Dec 11, 2017

@tyhicks

This comment has been minimized.

Show comment
Hide comment
@tyhicks

tyhicks Dec 11, 2017

I've removed "[WIP]" from the title so that we don't forget that this PR is potentially ready to be merged.

tyhicks commented Dec 11, 2017

I've removed "[WIP]" from the title so that we don't forget that this PR is potentially ready to be merged.

@mvo5

This comment has been minimized.

Show comment
Hide comment
@mvo5

mvo5 Jan 16, 2018

I am keen to use this new logging feature in one of my projects. Anything I can help with to get this merged?

mvo5 commented Jan 16, 2018

I am keen to use this new logging feature in one of my projects. Anything I can help with to get this merged?

@mheon

This comment has been minimized.

Show comment
Hide comment
@mheon

mheon Jan 16, 2018

Contributor

Sorry for the delay here, it's been a busy few months. I'll get this tested and merged tonight

Contributor

mheon commented Jan 16, 2018

Sorry for the delay here, it's been a busy few months. I'll get this tested and merged tonight

@mheon

This comment has been minimized.

Show comment
Hide comment
@mheon

mheon Jan 16, 2018

Contributor

Tests look good, but I noticed something concerning. Libseccomp just released v2.3.3, which is referenced a lot in this PR as the version that will include SCMP_ACT_LOG support (and API levels). Upstream v2.3.3 does not appear to have either of those, however.

@pcmoore What release are those likely to come out in? Can we throw v2.3.4 in there and be safe?

Contributor

mheon commented Jan 16, 2018

Tests look good, but I noticed something concerning. Libseccomp just released v2.3.3, which is referenced a lot in this PR as the version that will include SCMP_ACT_LOG support (and API levels). Upstream v2.3.3 does not appear to have either of those, however.

@pcmoore What release are those likely to come out in? Can we throw v2.3.4 in there and be safe?

@pcmoore

This comment has been minimized.

Show comment
Hide comment
@pcmoore

pcmoore Jan 17, 2018

Member

@mheon the changes from Tyler are not simple bug fixes, but new functionality, so it would be the next "Y" release (given the X.Y.Z versioning).

Considering that the logging capability in the golang bindings needs to be conditional on the main libseccomp version, and we haven't released a libseccomp update with the logging functionality, it seems premature to add this to the golang bindings right now.

FWIW, I'm trying very hard to get a new libseccomp Y release ready, but I'm chasing some nasty bugs at the moment in the src/db.c code. I'm getting very close, but not there yet.

Member

pcmoore commented Jan 17, 2018

@mheon the changes from Tyler are not simple bug fixes, but new functionality, so it would be the next "Y" release (given the X.Y.Z versioning).

Considering that the logging capability in the golang bindings needs to be conditional on the main libseccomp version, and we haven't released a libseccomp update with the logging functionality, it seems premature to add this to the golang bindings right now.

FWIW, I'm trying very hard to get a new libseccomp Y release ready, but I'm chasing some nasty bugs at the moment in the src/db.c code. I'm getting very close, but not there yet.

@mheon

This comment has been minimized.

Show comment
Hide comment
@mheon

mheon Jan 17, 2018

Contributor

ACK. I'll hold off until you cut a new version with the appropriate defines, then.

Contributor

mheon commented Jan 17, 2018

ACK. I'll hold off until you cut a new version with the appropriate defines, then.

tyhicks added a commit to tyhicks/libseccomp-golang that referenced this pull request Mar 2, 2018

golang: Correct the value of the ActLog const
The libseccomp-golang upstream had previously requested that ActLog be
placed below ActAllow. This change reflects the request from upstream.

seccomp#29 (comment)

Signed-off-by: Tyler Hicks <tyhicks@canonical.com>

tyhicks added some commits Sep 21, 2017

golang: Add support for SCMP_ACT_LOG
Represent libseccomp's SCMP_ACT_LOG action with ActLog. This action logs
before allowing the syscall.

Signed-off-by: Tyler Hicks <tyhicks@canonical.com>
golang: Add ActLog test
Add a new test that defaults to ActErrno, allows the syscalls needed to
carry out a basic test, and sets the getpid() syscall to ActLog. The
getpid() syscall is called before the filter is loaded and once again
after the filter is loaded. The test is successful if the return values
match.

The test is skipped when libseccomp is not new enough to support API
level operations or the API level is less than 3.

Signed-off-by: Tyler Hicks <tyhicks@canonical.com>
@tyhicks

This comment has been minimized.

Show comment
Hide comment
@tyhicks

tyhicks Mar 2, 2018

I found a bug in this PR that was introduced when I moved ActLog after ActAllow in the list of ScmpActions. I forgot to update actionEnd to be ActLog instead of ActAllow. This prevented ActLog from being used as the default action for a filter. I've incorporated that change into the Add support for SCMP_ACT_LOG commit and updated this PR.

tyhicks commented Mar 2, 2018

I found a bug in this PR that was introduced when I moved ActLog after ActAllow in the list of ScmpActions. I forgot to update actionEnd to be ActLog instead of ActAllow. This prevented ActLog from being used as the default action for a filter. I've incorporated that change into the Add support for SCMP_ACT_LOG commit and updated this PR.

tyhicks added a commit to tyhicks/libseccomp-golang that referenced this pull request Mar 2, 2018

golang: Correct the value of the ActLog const
The libseccomp-golang upstream had previously requested that ActLog be
placed below ActAllow. This change reflects the request from upstream.

seccomp#29 (comment)

Signed-off-by: Tyler Hicks <tyhicks@canonical.com>

tyhicks added a commit to tyhicks/libseccomp-golang that referenced this pull request Mar 2, 2018

golang: Correct the value of the ActLog const
The libseccomp-golang upstream had previously requested that ActLog be
placed below ActAllow. This change reflects the request from upstream.

seccomp#29 (comment)

Signed-off-by: Tyler Hicks <tyhicks@canonical.com>

tyhicks added a commit to tyhicks/libseccomp-golang that referenced this pull request Mar 2, 2018

Revert "golang: Add support for SCMP_ACT_LOG"
This reverts commit eee98e2.

The libseccomp-golang maintainer requested that ActLog be placed below
ActAllow. Revert the outdated version of this patch so that we can apply
the new version that reflects the request from upstream.

seccomp#29 (comment)

Signed-off-by: Tyler Hicks <tyhicks@canonical.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment