6 ms·

Both of these issues seem like a timely reminder that everyday Linux desperately needs a proper application management and security model. Installing software

Both of these issues seem like a timely reminder that everyday Linux desperately needs a proper application management and security model. Installing software where your options are 1. running as a regular user, and the install script can put whatever it wants within your user's directories or 2. running as root, and the install script can do literally anything to anywhere on your system is not fit for purpose, when the risks from both malice and incompetence are both reaching new heights almost daily. These are systems we use for real work, but even smartphones and their toy app stores do better now. How do we still not have controls so applications can always be installed/uninstalled in a controlled way, can only access files and other system resources that are relevant to their own operation, and so on?

Piskvorrr 9y ago
FWIW, "new npm broke Æeeeverything? Meh. Destroy the docker container, force version <= 5.6.0, rebuild" has now saved me from a bigger disaster. This is the 1.5th option, IMNSHO: npm gets its root(-ish) access, host computer is somewhat protected.
progval 9y ago
> everyday Linux desperately needs a proper application management and security model. We already have the necessary tools to do it, eg. firejail. We only have to make every binary run in firejail by default (and write firejail profiles for more binaries).
mastax 9y ago
Yeah people like to hate on Microsoft/Mac App Stores, but at least they don't let programs vomit files across the disk. The Linux solution I suppose is Nix/Guix or Flatpak/Snap or Docker a la RancherOS. Perhaps more restrictive SELinix profiles could work as well.
vetinari 9y ago
> everyday Linux desperately needs a proper application management You mean something, that won't allow two packages to own the same file? Something, like, rpm or apt?
- y4mi 9y ago
  You probably meant rpm and dpkg... Or you'd have to compare yum, zypper, apt, pacman and whatever else is out there. But, I'm certain the parent didn't mean that. Dpkg and rpm both allow packages to overwrite files from each other and, more dangerously, allow fully authorized post-install scripts. And they're often necessary for sane package management (create user, initiate database), but could be exploited to wreck havoc on the system.
  - vetinari 9y ago
    Yes, I meant dpkg. Not sure about dpkg, but rpm does not allow two packages to own the same file. If you try to install package, that contains file owned by another, already installed package, the installation will fail (you can try that with installing an amd64 package that owns something in /usr/share, and then try to install the i386 version). Yes, post-install scripts are dangerous and rpm folks are doing small steps to phase them out: https://www.youtube.com/watch?v=kE-8ZRISFqA https://www.youtube.com/watch?v=kE-8ZRISFqA
    - Piskvorrr 9y ago
      dpkg will throw a fit in the same way.
      - y4mi 9y ago
        it will throw an error message, which the user is probably going to ignore and install anyway. This will ultimately cause errors down the line. Maybe not right now, but eventually problems will occur. showing a warning is great, but not needing that warning would be preferable. but most distributions are already working on solutions to that. ubuntu is working on SnapOn's [0] for example, and i remember hearing about something else from redhad as well. [0] https://snapcraft.io/ https://snapcraft.io/
        __david__ 9y ago
        No, it will not install the package at all: $ mkdir root/bin/ $ (echo '#!/bin/sh'; echo 'echo "hi"') > root/bin/ls $ chmod +x root/bin/ls $ fpm -s dir -t deb -n bad-ls -v 1.0 -C `pwd`/root . Created package {:path=>"bad-ls_1.0_amd64.deb"} $ dpkg-deb -c bad-ls_1.0_amd64.deb drwxrwxr-x 0/0 0 2018-02-22 10:44 ./ drwxr-xr-x 0/0 0 2018-02-22 10:44 ./usr/ drwxr-xr-x 0/0 0 2018-02-22 10:44 ./usr/share/ drwxr-xr-x 0/0 0 2018-02-22 10:44 ./usr/share/doc/ drwxr-xr-x 0/0 0 2018-02-22 10:44 ./usr/share/doc/bad-ls/ -rw-r--r-- 0/0 142 2018-02-22 10:44 ./usr/share/doc/bad-ls/changelog.gz drwxrwxr-x 0/0 0 2018-02-22 10:44 ./bin/ -rwxrwxr-x 0/0 20 2018-02-22 10:42 ./bin/ls $ sudo dpkg -i bad-ls_1.0_amd64.deb Selecting previously unselected package bad-ls. (Reading database ... 837129 files and directories currently installed.) Preparing to unpack bad-ls_1.0_amd64.deb ... Unpacking bad-ls (1.0) ... dpkg: error processing archive bad-ls_1.0_amd64.deb (--install): trying to overwrite '/bin/ls', which is also in package coreutils 8.28-1 Errors were encountered while processing: bad-ls_1.0_amd64.deb $ ls -l /bin/ls -rwxr-xr-x 1 root root 134792 Oct 2 10:51 /bin/ls* It doesn't just warn and leave things in a bad state.
danieldk 9y ago
Both of these issues seem like a timely reminder that everyday Linux desperately needs a proper application management and security model. I agree. For instance, on recent macOS versions you cannot modify most system directories as root, unless System Integrity Protection (SIP) is enabled [1]. SIP can only be disabled by the user by booting into the recovery OS. Just making these directories read-only prevent accidents and malice. AFAIK in Fedora Atomic Host/Server some system directories are also read-only [2]. Moreover, Fedora Atomic uses OSTree as a content-addressed object store, similarly to git, where the current filesystem is just a 'checkout'. So, you can do transactional rollbacks, upgrades, etc. [1] https://support.apple.com/en-us/HT204899 https://support.apple.com/en-us/HT204899 [2] https://rpm-ostree.readthedocs.io/en/latest/manual/administrator-handbook/#filesystem-layout https://rpm-ostree.readthedocs.io/en/latest/manual/administr...

Piskvorrr 9y ago

FWIW, "new npm broke Æeeeverything? Meh. Destroy the docker container, force version <= 5.6.0, rebuild" has now saved me from a bigger disaster. This is the 1.5th option, IMNSHO: npm gets its root(-ish) access, host computer is somewhat protected.

progval 9y ago

> everyday Linux desperately needs a proper application management and security model. We already have the necessary tools to do it, eg. firejail. We only have to make every binary run in firejail by default (and write firejail profiles for more binaries).

mastax 9y ago

Yeah people like to hate on Microsoft/Mac App Stores, but at least they don't let programs vomit files across the disk. The Linux solution I suppose is Nix/Guix or Flatpak/Snap or Docker a la RancherOS. Perhaps more restrictive SELinix profiles could work as well.

vetinari 9y ago

> everyday Linux desperately needs a proper application management You mean something, that won't allow two packages to own the same file? Something, like, rpm or apt?

y4mi 9y ago
You probably meant rpm and dpkg... Or you'd have to compare yum, zypper, apt, pacman and whatever else is out there. But, I'm certain the parent didn't mean that. Dpkg and rpm both allow packages to overwrite files from each other and, more dangerously, allow fully authorized post-install scripts. And they're often necessary for sane package management (create user, initiate database), but could be exploited to wreck havoc on the system.
- vetinari 9y ago
  Yes, I meant dpkg. Not sure about dpkg, but rpm does not allow two packages to own the same file. If you try to install package, that contains file owned by another, already installed package, the installation will fail (you can try that with installing an amd64 package that owns something in /usr/share, and then try to install the i386 version). Yes, post-install scripts are dangerous and rpm folks are doing small steps to phase them out: https://www.youtube.com/watch?v=kE-8ZRISFqA https://www.youtube.com/watch?v=kE-8ZRISFqA
  - Piskvorrr 9y ago
    dpkg will throw a fit in the same way.
    - y4mi 9y ago
      it will throw an error message, which the user is probably going to ignore and install anyway. This will ultimately cause errors down the line. Maybe not right now, but eventually problems will occur. showing a warning is great, but not needing that warning would be preferable. but most distributions are already working on solutions to that. ubuntu is working on SnapOn's [0] for example, and i remember hearing about something else from redhad as well. [0] https://snapcraft.io/ https://snapcraft.io/
      - __david__ 9y ago
        No, it will not install the package at all: $ mkdir root/bin/ $ (echo '#!/bin/sh'; echo 'echo "hi"') > root/bin/ls $ chmod +x root/bin/ls $ fpm -s dir -t deb -n bad-ls -v 1.0 -C `pwd`/root . Created package {:path=>"bad-ls_1.0_amd64.deb"} $ dpkg-deb -c bad-ls_1.0_amd64.deb drwxrwxr-x 0/0 0 2018-02-22 10:44 ./ drwxr-xr-x 0/0 0 2018-02-22 10:44 ./usr/ drwxr-xr-x 0/0 0 2018-02-22 10:44 ./usr/share/ drwxr-xr-x 0/0 0 2018-02-22 10:44 ./usr/share/doc/ drwxr-xr-x 0/0 0 2018-02-22 10:44 ./usr/share/doc/bad-ls/ -rw-r--r-- 0/0 142 2018-02-22 10:44 ./usr/share/doc/bad-ls/changelog.gz drwxrwxr-x 0/0 0 2018-02-22 10:44 ./bin/ -rwxrwxr-x 0/0 20 2018-02-22 10:42 ./bin/ls $ sudo dpkg -i bad-ls_1.0_amd64.deb Selecting previously unselected package bad-ls. (Reading database ... 837129 files and directories currently installed.) Preparing to unpack bad-ls_1.0_amd64.deb ... Unpacking bad-ls (1.0) ... dpkg: error processing archive bad-ls_1.0_amd64.deb (--install): trying to overwrite '/bin/ls', which is also in package coreutils 8.28-1 Errors were encountered while processing: bad-ls_1.0_amd64.deb $ ls -l /bin/ls -rwxr-xr-x 1 root root 134792 Oct 2 10:51 /bin/ls* It doesn't just warn and leave things in a bad state.

danieldk 9y ago

Both of these issues seem like a timely reminder that everyday Linux desperately needs a proper application management and security model. I agree. For instance, on recent macOS versions you cannot modify most system directories as root, unless System Integrity Protection (SIP) is enabled [1]. SIP can only be disabled by the user by booting into the recovery OS. Just making these directories read-only prevent accidents and malice. AFAIK in Fedora Atomic Host/Server some system directories are also read-only [2]. Moreover, Fedora Atomic uses OSTree as a content-addressed object store, similarly to git, where the current filesystem is just a 'checkout'. So, you can do transactional rollbacks, upgrades, etc. [1] https://support.apple.com/en-us/HT204899 https://support.apple.com/en-us/HT204899 [2] https://rpm-ostree.readthedocs.io/en/latest/manual/administrator-handbook/#filesystem-layout https://rpm-ostree.readthedocs.io/en/latest/manual/administr...