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, 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