Request for access to system-files interface and automatic connection

Good afternoon @reviewers

Request

I have written a program grpusr and published it as a snap which requires read-only access to two system files, both of which are publicly readable:

  • /etc/group
  • /etc/passwd

Pursuant to the review (thankyou Alex) I submit this request for access to system-files interface and auto-connection. system-files appears to be the most appropriate interface in order to access the two files however if a more suitable alternative exists I would love to learn what it is and explore that.


A primer on the program

grpusr is a simple utility which queries /etc/group and /etc/passwd (or two similarly formatted alternatives) for group membership information. Whilst it can do single user-group membership checks, it becomes much more useful when checking a list of users belong to one or more groups. The program doesn’t write any data and it doesn’t connect to a network.

Examples:

Example 1

Check whether a single user exists in a single group

Usage:

$ snap run grpusr lxd:daniel

Output:

Group 'lxd' contains user 'daniel'

return code: 0

Example 2

Check whether a multiple users exist in a single group

Usage:

$ snap run grpusr lxd:daniel,postgres

Output:

Group 'lxd' contains user 'daniel'
Group 'lxd' does not contain user 'postgres'

return code: 1

Example 3

Check whether a multiple exist users in multiple groups

Usage:

$ snap run grpusr \
    lxd:daniel,root \
    adm:daniel,root,postgres

Output:

Group 'adm' contains user 'daniel'
Group 'adm' does not contain user 'postgres'
Group 'adm' does not contain user 'root'
Group 'lxd' contains user 'daniel'
Group 'lxd' does not contain user 'root'

return code: 1


Best regards

Daniel

Hey @DWD

Your program looks great!

+1 from me for granting grpusr snap read access to /etc/group and /etc/passwd via system-files interface auto-connection, considering that this information is not shared over the network.

As a more general though when private information is involved, one thing that weights the decision to grant access to that information or not, is what the information is going to be used for (specially relevant whether the information needs to leave the user’s computer or not). Sometimes it will be acceptable to grant auto-connection if the information is not going to be shared in anyway, but we may prefer to let the user decide (with manual connection) is the information may be sent over the network.

In that sense, I wonder if it will be a good practice in those cases to add explicit deny conditions to the snap declaration for network related interfaces when its use (or not use) may weight the decision to grant access to some private information. Thus, future changes do not go unnoticed. @alexmurray thoughts?

1 Like

Thank you for your positive feedback and support @jslarraz.


Explicit deny-network policy

I think the ability to explicitly agree that network access is not required would be a good move in general for snap package security and visibility. Many applications may never need to access the network and it would be beneficial to declare that.

If necessary, a subsequent request to review/ alter that agreement could be made with appropriate justification.


Appetite for a less privileged system-files interface

Is there an appetite for the creation of a less sensitive/ privileged interface than system-files, with read-only capability for already globally readable files.

The proposition:

  • Everyone can already read the file by design
  • The file is deemed to have low-sensitivity by the system
  • There is no opportunity for network egress
  • There are no filesystem changes

is far less threatening than:

  • Requires access to the information in the super sensitive /etc/ hierarchy

A note for future Daniel and reviews: I have subsequently learnt of /etc/subuid and /etc/subgid which I will likely integrate into grpusr at a later date.


Best regards

Daniel

hey @DWD After understanding the requirements for this snap, +1 from me as well for granting an auto-connect request to grpusr snap read access to /etc/group and /etc/passwd via system-files interface

1 Like

hi @DWD, sorry for the delay in getting this one processed!

+2 votes for, 0 votes against, granting auto-connect of interface system-files to snap grpusr. Before making this snap live, would it be possible to adjust the interface formatting to match the example seen in https://snapcraft.io/docs/system-files-interface.

That being separating the two files into their own system-files plug?

plugs:
  etc-group:
    interface: system-files
    read:
    - /etc/group

  etc-passwd:
    interface: system-files
    read:
    - /etc/passwd

Thanks!

1 Like

Thank you @cav, yes I will make that change.

amazing! Let me know once this change is updated in the store and I’ll go ahead and grant. Thanks!

Thanks @cav, I’ve made that change on the v1.0.0 release. I’ve rebuilt the snaps for amd64 and arm64 and uploaded.

Once approved I’ll work through the subsequent releases

@DWD - since the request is for autoconnect of system files not owned by the snap, I will go ahead and begin publisher vetting.

Could you please provide a link to the upstream project and your Git{hub|lab|…} account associated with the upstream project?

Thanks @cav . The project source is not published, it remains private for now. That might change in the future.

I have a (purposely) sparse GitHub profile where you should see two PRs into Snapcraft itself, merged by @mr_cal . I might be able to find a few people to give character references if necessary?

Please let me know what I can do to facilitate the vetting process

hi @DWD, it seems I may have been wrong with my understanding in this one!

By default, you snap should already be able to read /etc/group and /etc/passwd as it is in the apparmor template in snapd.

If you do something like

$ snap run --shell grpusr.<app_name>
$ cat /etc/passwd
$ cat /etc/group

It should be able to show that the snap already has access. Let me know if that works! Thanks again!

Hey @cav ,having removed those plugs, the snap does still work on my laptop with --dangerous enabled. I can’t upload it because of this:

  • Waiting for previous upload(s) to complete their review process. If you want to prioritize this last one, go to the other upload(s) page in https://dashboard.snapcraft.io/ and click on the ‘Reject and remove from review queue’ button.

It looks like revision #5 just passed and is ready to release: https://dashboard.snapcraft.io/snaps/grpusr/revisions/5/

Thank you :slight_smile: It’s uploaded and working!

1 Like

that is all good! Apologies again for the delay