Giters

geerlingguy / ansible-role-security

Ansible Role - Security

Home Page:https://galaxy.ansible.com/geerlingguy/security/

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

unattended-upgrades config is broken in Debian

Hnasar opened this issue · comments

commented

http://security.ubuntu.com/ubuntu/dists/precise-security/Release

Origin: Ubuntu
Label: Ubuntu
Suite: precise-security
Version: 12.04
Codename: precise

vs
http://security.debian.org/debian-security/dists/stretch/updates/Release

Origin: Debian
Label: Debian-Security
Suite: stable
Version: 9
Codename: stretch

templates/50unattended-upgrades.j2 has:

Unattended-Upgrade::Allowed-Origins {                                          
        "${distro_id} ${distro_codename}-security";                            
//      "${distro_id} ${distro_codename}-updates";                             
};

which works for ubuntu's precise-security but not Debian's stable.

unattended-upgrade's README.md has the following:

Allowed-Origins is a simple list of patterns of the form
"origin:archive".

Origins-Pattern allows you to give a list of
(glob-style) patterns to match against. For example:

 Unattended-Upgrade::Origins-Pattern {                                       
        "origin=Google\, Inc.,suite=contrib";                                
        "site=www.example.com,component=main";                               
 };

Again per the README.md, ${distro_codename} contains the output of lsb_release -c, which is stretch, xenial, etc.
The archive is based on the Suite which is percise-updates for ubuntu and stable for Debian.

As such, the default config means that no packages are matched by unattended-upgrades in Debian.
One fix is to add "${distro_id} stable"; to Allowed-Origins, but even better would to use the upstream 50unattended-upgrades which is created in the unattended-upgrades postinst.

In Debian:

Unattended-Upgrade::Origins-Pattern {
        "origin=Debian,codename=${distro_codename},label=Debian-Security";
};

and in Ubuntu:

Unattended-Upgrade::Allowed-Origins {
        "${distro_id}:${distro_codename}";
        "${distro_id}:${distro_codename}-security";
        "${distro_id}ESM:${distro_codename}";
};

I'm not sure the best method for a fix. I think a template for 50unattended-upgrades is not ideal, and instead this role should switch to using lineinfile for

security_autoupdate_blacklist: []                                              
security_autoupdate_mail_to: ""                                                
security_autoupdate_mail_on_error: true

That doesn't explain what to do with other systems which already have a nonworking config. I'm not sure how much retroactive fixing is appropriate for this role, but on my systems I found that I can restore the upstream 50unattended-upgrades by:

  # UCF has some weirdness where even if you set FORCE_CONFFNEW, if the file   
  # is user modified, it uses a hash calculated when the conf file was last    
  # touched by a package. To workaround, delete and then rely on CONFFMISS.    
  - name: Remove bad unattended-upgrades                                       
    file:                                                                      
      path: /etc/apt/apt.conf.d/50unattended-upgrades                          
      state: absent                                                            
                                                                               
  - name: Set back to default unattended-upgrades configuration                
    command: dpkg-reconfigure --default-priority unattended-upgrades           
    environment:                                                               
      UCF_FORCE_CONFFMISS: True

(or in the shell:

sudo rm /etc/apt/apt.conf.d/sudo rm 50unattended-upgrades
env UCF_FORCE_CONFFMISS=1 sudo -E dpkg-reconfigure --default-priority unattended-upgrades

)

commented

I've just submitted a PR which might resolve this? #35

I've pulled the current config file from the upstream repo (according to Debian's package index) and had it check for specific strings.

commented

This issue has been marked 'stale' due to lack of recent activity. If there is no further activity, the issue will be closed in another 30 days. Thank you for your contribution!

Please read this blog post to see the reasons why I mark issues as stale.

commented

This issue has been closed due to inactivity. If you feel this is in error, please reopen the issue or file a new issue with the relevant details.