The snap for nsntrace requests classic confinement

store-requests
#1

Hi!

I belive that nsntrace needs classic confinement because it traces the network activity of applications, and we cannot know the confinement needs for arbitrary binaries being traced.

Review of nsntrace snap here: https://dashboard.snapcraft.io/snaps/nsntrace/revisions/1/review/
See more about nsntrace here: https://github.com/nsntrace/nsntrace

Thank you!

#2

The nsntrace application runs arbitrary applications in a separate network namespace in order to trace the network activity of that application.

@review-team is there anymore information you need in order to make a decision?

Best regards
Jonas

#3

Hey @jonasdn, apologize for the late response.

If you take a look at our Process for reviewing classic confinement snaps, the need to launch arbitrary applications is not generally considered a supported use-case for classic confinement. So unfortunately this request cannot proceed as it is. You could ship any application (e.g. stage-package) in your snap but I assume this is not a valid scenario given what you have explained. Can you please confirm?

#4

Hi @emitorino, I think that nsntrace fits into the class of utilities such as compilers/IDE’s, similar to my application etrace which was granted classic confinement usage, as per Jamie’s logic:

most notably that the snap can’t reasonably do its analysis while running under a strict mode runtime (needs access to host files).

As such, I think nsntrace should be granted classic confinement

#5

@ijohnson hmm that is an interesting data-point - our current guidelines for classic confinement list the following categories:

Supported

  • compilers
  • IDEs
  • juju helpers
  • kubernetes tools requiring arbitrary authentication agents
  • nautilus scripts
  • programming languages
  • public cloud agents
  • tools for local, non-root user driven configuration of/switching to development workspaces/environments
  • terminal emulators, multiplexers and shells
  • HPC or orchestration agents/software for running workloads on systems without traditional users where the systems are otherwise managed outside of the agent (ie, the software simply orchestrates running workloads on systems and doesn’t manage the systems themselves). Note: many HPC/orchestration applications can run with strict confinement and classic should only be granted if snapd does not support the specific use case (eg, the need for user accounting).

In this case, nsntrace doesn’t appear to fit into one of these categories. I was going to suggest that it perhaps could be seen as something like a tool for local, non-root user driven configuration of/switching to development workspaces/environments since it switches to a new network namespace / environment to run the application. However, when I try and run the nsntrace deb it wants root privileges - I assume the snap is the same. In this case, it fails the non-root user driven part of that category.

In regards to etrace I feel that perhaps this did not fit the existing categories for classic confinement and so I wonder if @pedronis could comment on whether we need an additional explicit category for Tracing / development tools that wrap existing host binaries since to me the concept of IDE/compiler is perhaps a bit too limiting to cover this.

#6

well, should that perhaps be extended to “compilers and debug tools” (which a tracing tool most likely fits into) ?

1 Like
#7

Yes I think this would make for a nice succinct definition - @pedronis thoughts?

1 Like
#8

I think it’s fine to add a debug tools category with the following understanding:

  • the main reason to grant classic would be if they need, because of how they perform or because of the needs of the programs under debugging, to access potentially any file on the system
  • as usual we should be careful and reluctant to grant classic to programs that are open to external network access
1 Like
#9

Since we have agreed on extending the compilers supported categories to: “compilers and debug tools”, then the requirements are understood. @advocacy could you please proceed with the publisher vetting process?

Thanks!

#10

I have updated the process doc with the above suggestion:

well, should that perhaps be extended to “compilers and debug tools” (which a tracing tool most likely fits into) ?

Please @reviewers, @pedronis take a look and let me know if you have any questions.

Thanks!

#11

Thanks, I split them out in their own category though. We might have to clarify some recommendations for them that are not shared with compilers themselves.

1 Like
#12

@jonasdn does nsntrace have an official webpage (or is the GH page the official one)?

#13

Hi!

The GitHub page is the official page!

Regards
Jonas

#14

@Igor could you please perform publisher vetting since @jonasdn confirmed the GitHub page is the official site for nsntrace?

#15

Sorry for the belated reply. +1 from me, I’ve checked and vetted the publisher.

1 Like
#16

Granting use of classic. This is now live. @jonasdn could you please either request a manual review or upload a new revision so review-tools can run automatically again and your snap can be published? Thanks!