Skip to content
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

Remove snappy from base Ubuntu system as part of installation process? #5128

Closed
zenmonkeykstop opened this issue Feb 19, 2020 · 7 comments · Fixed by #5784
Closed

Remove snappy from base Ubuntu system as part of installation process? #5128

zenmonkeykstop opened this issue Feb 19, 2020 · 7 comments · Fixed by #5784
Assignees
Milestone

Comments

@zenmonkeykstop
Copy link
Contributor

Description

Ubuntu 16.04 includes the snappy package manager, an alternative package management system that allows applications to be installed along with their dependencies in a single bundle. It's not used by SecureDrop and could be removed during the initial server setup, thereby reducing the overall attack surface.

User Research Evidence

None, this is not a user-facing issue.

User Stories

As a SecureDrop admin, I want the system to only include tools and packages required by SecureDrop.

@conorsch
Copy link
Contributor

We could make a quick change to the Ansible logic to purge the snappy config, but that'll mostly only work for new installs, it won't be applied generally to all production SecureDrop instances. We cannot easily provide unattended logic to purge those configs via postinst because the dpkg/apt lock will be active.

Using pull-like Ansible like as described in #3136 would resolve, but that's not on the roadmap at present. Recommend deferring action here until we tackle Bionic support #4768, when we can address cleanup issues in one fell swoop.

@emkll emkll added the needs/discussion queued up for discussion at future team meeting. Use judiciously. label Sep 28, 2020
@eloquence
Copy link
Member

Given Canonical's heavy push towards snaps, 1) is the assumption in this issue still true for 20.04 (I'm noticing on a non-SD 20.04 server that even stuff like lxd is now provided via snap), 2) will it hold true for future packages we may want to install / do we shut any doors for ourselves by removing snap support?

@zenmonkeykstop
Copy link
Contributor Author

On the base 20.04.1 LTS VM, there are no snaps installed by default. Since we don't use snap for the SD package dependencies, there are none installed on Xenial currently either. It's possible that in future Ubuntu versions we might be constrained to use it to satisfy application dependencies but right now (and for the duration of 20.04 support, probably) it's not required.

Given that in general we want to maintain a minimal set of packages for security reasons, we want to discourage admins from installing additional applications, and we want to keep our provisioning story simple, it seems like a good candidate for removal (most likely in the prepare-servers role called early by the playbook).

@eloquence
Copy link
Member

We discussed this during sprint planning today and agreed that it's worth doing, assuming we don't discover unintended side effects. Since it's only relevant to Focal, we agreed it can potentially wait until 1.8.0 or later.

@eloquence eloquence added this to the 1.8.0 milestone Jan 25, 2021
@eloquence
Copy link
Member

Considering as a stretch goal for 1.8.0, once other Focal requirements are met.

@eloquence eloquence removed the needs/discussion queued up for discussion at future team meeting. Use judiciously. label Feb 4, 2021
@zenmonkeykstop
Copy link
Contributor Author

Here are some reccos from a different Kevin, which I have not yet tried and which may apply more for desktop Ubuntu: https://www.kevin-custer.com/blog/disabling-snaps-in-ubuntu-20-04/

@zenmonkeykstop zenmonkeykstop self-assigned this Feb 8, 2021
@kushaldas kushaldas self-assigned this Feb 11, 2021
kushaldas added a commit that referenced this issue Feb 11, 2021
Also removes the related apparmor configuration.
@conorsch
Copy link
Contributor

Seeing a test failure on Focal for this, but only on Qubes staging VMs, created from ISO. Test failure looks like:

host = <testinfra.host.Host ansible://app-staging>
    
        def test_aa_no_denies_in_syslog(host):
            """ Ensure that there are no apparmor denials in syslog """
            with host.sudo():
                f = host.file("/var/log/syslog")
    >           assert 'apparmor="DENIED"' not in f.content_string
    E           assert 'apparmor="DENIED"' not in 'Feb 11 14:2...uildtimes.\n'
    E             'apparmor="DENIED"' is contained here:
    E               Feb 11 14:29:19 app-staging rsyslogd: [origin software="rsyslogd" swVersion="8.2001.0" x-pid="640" x-info="https://www.rsyslog.com"] rsyslogd was HUPed
    E               Feb 11 14:29:19 app-staging dbus-daemon[628]: dbus[628]: Unknown group "power" in message bus configuration file
    E               Feb 11 14:29:19 app-staging systemd[1]: Starting Hold until boot process finishes up...
    E               Feb 11 14:29:19 app-staging systemd[1]: Starting Terminate Plymouth Boot Screen...
    E               Feb 11 14:29:19 app-staging snapd[642]: daemon.go:347: started snapd/2.48+20.04 (series 16; classic) ubun...
    E             
    E             ...Full output truncated (4770 lines hidden), use '-vv' to show
    
    ../testinfra/app/test_apparmor.py:128: AssertionError


The specific lines causing the test to fail are:

sdadmin@app-staging:~$ sudo grep -F DENIED /var/log/syslog
Feb 11 14:34:13 app-staging kernel: [   63.945397] audit: type=1400 audit(1613054053.529:46): apparmor="DENIED" operation="open" profile="/usr/sbin/ntpd" name="/snap/bin/" pid=2239 comm="ntpd" requested_mask="r" denied_mask="r" fsuid=0 ouid=0
Feb 11 14:36:53 app-staging kernel: [  224.349950] audit: type=1400 audit(1613054213.933:47): apparmor="DENIED" operation="open" profile="/usr/sbin/ntpd" name="/snap/bin/" pid=22457 comm="ntpd" requested_mask="r" denied_mask="r" fsuid=0 ouid=0

We have a PR up in #5784, only documenting this to point out that it's another small divergence between ISOs and Vagrant boxes.

conorsch pushed a commit that referenced this issue Feb 11, 2021
Also removes the related apparmor configuration.
conorsch pushed a commit that referenced this issue Feb 11, 2021
Also removes the related apparmor configuration.
emkll added a commit that referenced this issue Feb 12, 2021
Fixes #5128 removes snappy from the default installation
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants