9 ms·

This is a real problem. It is a total joke to suggest that people move important systems to Archlinux though. Basically as an administrator you need to be awa

This is a real problem. It is a total joke to suggest that people move important systems to Archlinux though. Basically as an administrator you need to be aware of security advisories against the OS you run. This is already true because you need to know when to upgrade packages. If you are running Debian you should sign up for debian-security-announce: https://lists.debian.org/debian-security-announce/ https://lists.debian.org/debian-security-announce/ There are equivalent mailing lists for CentOS. It would probably be helpful to have better tooling to warn about/mark packages with known vulnerabilities associated. I'm not an expert on Debian's internal process but sometimes it seems that Debian add packages to their distribution without a clear plan for how to fix security issues in them. Sometimes upstream maintainers seem hellbent on making it impossible to offer long term support for software. Elasticsearch is a case in point: https://www.debian.org/security/2015/dsa-3389 https://www.debian.org/security/2015/dsa-3389

ynezz 11y ago
For us, lazy admins, there's cron-apt in Debian based distributions. I believe, that there's something like cron-apt available in more distributions also.
- creshal 11y ago
  cron-apt is more or less deprecated, unattended-upgrades works far better and is included in all supported Debian versions.
  - Qwertious 11y ago
    Shit, how do you get people to migrate away from cron-apt? By definition they're not around to do manual migration.
    - creshal 11y ago
      Chef, puppet, ansible, … Or the redneck version: Have a metapackage in your own repository that uses dependencies/conflicts to pull/remove the packages you want.
      - majewsky 11y ago
        What you call "redneck" version is actually how I manage my system configuration. :) The metapackage is the only one that's explicitly installed, ever. (Except for workstations where I might install applications to test them.) Part of system maintenance is to clean out orphaned packages every once in a while, usually as part of the system update.
        creshal 11y ago
        > What you call "redneck" version is actually how I manage my system configuration. :) Same here. One day I'll get around to migrate everything to Ansible… one day…
        stephenr 11y ago
        I'm a big fan of this approach too. Combine it with config packages (using something like configure-package-dev from debathena) and you have a very nice little config management system.
    - Ao7bei3s 11y ago
      That's what major versions are for. (It's still in Stretch though, so you don't have to switch to unattended-upgrades until at least ~2022. https://packages.debian.org/stretch/cron-apt https://packages.debian.org/stretch/cron-apt)
mbrock 11y ago
Lazyweb question. Is there a way for me to easily keep track of important upstream security announcements for some given set of software—say, ElasticSearch, Rails, nginx, and Linux? Like I could check those check boxes and get an RSS feed, or something?
- chei0aiV 11y ago
  That isn't really possible, Linux for example doesn't even have a security issues page, you are expected to read git patches yourself and understand the implications of each patch. In general, looking at the security information for a Linux/BSD distro containing the software you care about is probably the best way, along with tracking any RSS feeds you can find that do exist.
- viraptor 11y ago
  It's not pretty (you need to do filtering yourself), but https://nvd.nist.gov/download.cfm https://nvd.nist.gov/download.cfm will give you 99% of the data you want. Otherwise, look at specific distro feeds. For example Ubuntu has http://www.ubuntu.com/usn/ http://www.ubuntu.com/usn/ (RSSable) and Debian has https://www.debian.org/security/ https://www.debian.org/security/ (also RSSable) (apparently you can also generate your own feed from http://tif.mcafee.com/ http://tif.mcafee.com/ but I never used it)
- reidrac 11y ago
  Related to open source, you probably want to track OSS Security mailing list [1]; or if you're part of an organization relying on open source software, you should have someone looking at that list. I think it is a good complement to the security advisories of your Linux distributor (Debian, CentOS, whatever), but is isn't free as you'll need time to keep an eye on it. 1: http://oss-security.openwall.org/ http://oss-security.openwall.org/
  - mbrock 11y ago
    Thanks. Regarding cost... someone should sell curated security feeds to startups. There must be many dozens of engineers who monitor mailing lists for issues in (let's say) ElasticSearch. They could be incentivized to share their findings. Then if one source tags a certain CVE as significant, I get a ping. If several sources tag it, the ping gets more urgent. Eventually I feel scared enough that I upgrade.
viraptor 11y ago
I've been looking at various descriptions of distro security policies lately and I'm actually not really decided on what the "right way" is. I agree that if you're an sole operator, you need to monitor the upstream project, disclosure lists, and assigned CVEs. If you're in a larger company, you probably need a team to handle that. And on one hand side this looks like it makes the issue of the distro choice moot. If you keep on top of announcements, you can either upgrade packages, or port back the patch yourself, or just repackage the latest version. But having the right distribution makes things simpler - you get the benefit of someone backporting the patch earlier and doing a coordinated release. Or maybe even you get a pre-disclosure notification. One way or another, it makes things simpler to rely on someone else's work even if it's not guaranteed that it's always available and complete. But on the other hand, getting a rolling distro like Arch you get new versions by default. This means your backport is going to be way easier if you have to do it yourself. For example you have to only go 2.3.4->2.3.5, not backport from 2.3.5 to 1.2.3 because that's what's in stable. Arch/Gentoo also had the benefit of releasing grsec kernels which considerably limits the scope of kernel exploits (and userland too to some extent), but Debian joined them lately. I guess if I had to admin a small service on 5 of so servers full time these days, I could be temped to actually go with some rolling release distro. At larger scale I'd prefer the benefit of using the upstream work. At not-full time job I'd still go with Debian/Ubuntu/CentOS to rely on the automation of common cases.
- chei0aiV 11y ago
  Some distro rolling releases get upgraded every 6 hours, are you sure you want to potentially upgrade that often? If I were running a larger company I would assign my security team to help out a distro security team, so I benefit from the work of others as well as getting specific support for the software I really care about.
  - viraptor 11y ago
    You don't have to upgrade every 6 hours. The upstream repo may be constantly updated, but the smaller your scope is, the less you need to care about really. For example I expect that I'll have some new packages on my desktop every few hours, but on a server with system+service+monitoring it may be one package a week instead. At that pace, it's trivial to just get notifications and classify updates as critical/useful/whatever. If you have a proper test/deploy pipeline you can retest with new software all as it's released, but only push to production every week, or when it's critical.
mixedCase 11y ago
Except on Arch everyone is supposed to keep updating their system at least once a day/on boot. Making security lists irrelevant as long as the packages are patched and released to the repos. One of the reasons why you'll see most Arch users and developers recommend against using Arch for a server due to the increased maintenance burden, which on a desktop is minimal.
- majewsky 11y ago
  I wouldn't say "once a day". When I'm sick, I might not touch my PCs for a week, and that has always been fine. The only situation where things were fucked up badly was when the system upgrade failed on a friend's notebook that was not updated for 6 months. I had to uninstall KDE in order to untangle the missing dependencies, then do the upgrade, then reinstall KDE.

ynezz 11y ago

For us, lazy admins, there's cron-apt in Debian based distributions. I believe, that there's something like cron-apt available in more distributions also.

creshal 11y ago
cron-apt is more or less deprecated, unattended-upgrades works far better and is included in all supported Debian versions.
- Qwertious 11y ago
  Shit, how do you get people to migrate away from cron-apt? By definition they're not around to do manual migration.
  - creshal 11y ago
    Chef, puppet, ansible, … Or the redneck version: Have a metapackage in your own repository that uses dependencies/conflicts to pull/remove the packages you want.
    - majewsky 11y ago
      What you call "redneck" version is actually how I manage my system configuration. :) The metapackage is the only one that's explicitly installed, ever. (Except for workstations where I might install applications to test them.) Part of system maintenance is to clean out orphaned packages every once in a while, usually as part of the system update.
      - creshal 11y ago
        > What you call "redneck" version is actually how I manage my system configuration. :) Same here. One day I'll get around to migrate everything to Ansible… one day…
      - stephenr 11y ago
        I'm a big fan of this approach too. Combine it with config packages (using something like configure-package-dev from debathena) and you have a very nice little config management system.
  - Ao7bei3s 11y ago
    That's what major versions are for. (It's still in Stretch though, so you don't have to switch to unattended-upgrades until at least ~2022. https://packages.debian.org/stretch/cron-apt https://packages.debian.org/stretch/cron-apt)

mbrock 11y ago

Lazyweb question. Is there a way for me to easily keep track of important upstream security announcements for some given set of software—say, ElasticSearch, Rails, nginx, and Linux? Like I could check those check boxes and get an RSS feed, or something?

chei0aiV 11y ago
That isn't really possible, Linux for example doesn't even have a security issues page, you are expected to read git patches yourself and understand the implications of each patch. In general, looking at the security information for a Linux/BSD distro containing the software you care about is probably the best way, along with tracking any RSS feeds you can find that do exist.
viraptor 11y ago
It's not pretty (you need to do filtering yourself), but https://nvd.nist.gov/download.cfm https://nvd.nist.gov/download.cfm will give you 99% of the data you want. Otherwise, look at specific distro feeds. For example Ubuntu has http://www.ubuntu.com/usn/ http://www.ubuntu.com/usn/ (RSSable) and Debian has https://www.debian.org/security/ https://www.debian.org/security/ (also RSSable) (apparently you can also generate your own feed from http://tif.mcafee.com/ http://tif.mcafee.com/ but I never used it)
reidrac 11y ago
Related to open source, you probably want to track OSS Security mailing list [1]; or if you're part of an organization relying on open source software, you should have someone looking at that list. I think it is a good complement to the security advisories of your Linux distributor (Debian, CentOS, whatever), but is isn't free as you'll need time to keep an eye on it. 1: http://oss-security.openwall.org/ http://oss-security.openwall.org/
- mbrock 11y ago
  Thanks. Regarding cost... someone should sell curated security feeds to startups. There must be many dozens of engineers who monitor mailing lists for issues in (let's say) ElasticSearch. They could be incentivized to share their findings. Then if one source tags a certain CVE as significant, I get a ping. If several sources tag it, the ping gets more urgent. Eventually I feel scared enough that I upgrade.

viraptor 11y ago

I've been looking at various descriptions of distro security policies lately and I'm actually not really decided on what the "right way" is. I agree that if you're an sole operator, you need to monitor the upstream project, disclosure lists, and assigned CVEs. If you're in a larger company, you probably need a team to handle that. And on one hand side this looks like it makes the issue of the distro choice moot. If you keep on top of announcements, you can either upgrade packages, or port back the patch yourself, or just repackage the latest version. But having the right distribution makes things simpler - you get the benefit of someone backporting the patch earlier and doing a coordinated release. Or maybe even you get a pre-disclosure notification. One way or another, it makes things simpler to rely on someone else's work even if it's not guaranteed that it's always available and complete. But on the other hand, getting a rolling distro like Arch you get new versions by default. This means your backport is going to be way easier if you have to do it yourself. For example you have to only go 2.3.4->2.3.5, not backport from 2.3.5 to 1.2.3 because that's what's in stable. Arch/Gentoo also had the benefit of releasing grsec kernels which considerably limits the scope of kernel exploits (and userland too to some extent), but Debian joined them lately. I guess if I had to admin a small service on 5 of so servers full time these days, I could be temped to actually go with some rolling release distro. At larger scale I'd prefer the benefit of using the upstream work. At not-full time job I'd still go with Debian/Ubuntu/CentOS to rely on the automation of common cases.

chei0aiV 11y ago
Some distro rolling releases get upgraded every 6 hours, are you sure you want to potentially upgrade that often? If I were running a larger company I would assign my security team to help out a distro security team, so I benefit from the work of others as well as getting specific support for the software I really care about.
- viraptor 11y ago
  You don't have to upgrade every 6 hours. The upstream repo may be constantly updated, but the smaller your scope is, the less you need to care about really. For example I expect that I'll have some new packages on my desktop every few hours, but on a server with system+service+monitoring it may be one package a week instead. At that pace, it's trivial to just get notifications and classify updates as critical/useful/whatever. If you have a proper test/deploy pipeline you can retest with new software all as it's released, but only push to production every week, or when it's critical.

mixedCase 11y ago

Except on Arch everyone is supposed to keep updating their system at least once a day/on boot. Making security lists irrelevant as long as the packages are patched and released to the repos. One of the reasons why you'll see most Arch users and developers recommend against using Arch for a server due to the increased maintenance burden, which on a desktop is minimal.

majewsky 11y ago
I wouldn't say "once a day". When I'm sick, I might not touch my PCs for a week, and that has always been fine. The only situation where things were fucked up badly was when the system upgrade failed on a friend's notebook that was not updated for 6 months. I had to uninstall KDE in order to untangle the missing dependencies, then do the upgrade, then reinstall KDE.