SUMMARY:
Q: Can a registered 3rd party repo spoof critical packages (e.g.
libc6) and have them installed on apt 'upgrade' operations?
Q: What are the best ways (configuration) to help manage 3rd party
repos to constrain their capabilities?
I have a growing number of users who want all sorts of 3rd party stuff
installed on their desktops (a few hundred), including things like
google chrome|earth, dropbox, etc. Keeping packages updated implies
adding sources.list entries, but...
Is it possible for a 3rd party repository/source added in
/etc/apt/sources.list.d/ to compromise a system by spoofing a new
(higher) version of a critical package, such as 'libc6'?
(aptitude update && aptitude upgrade => here, let me install
that new 'libc6' from 'packages-r-us.biz')?
What within apt prevents a spoofage of this nature? (it's unclear to
me that there's any builtin protection against this)
Ultimately, this question is kind of moot, as the mere act of trusting
a 3rd party source for a package installation (or dpkg -i {file})
makes us all sitting ducks, opening your system up to ANY root
activity being performed via a '{pre,post}inst' scripted action or
malware contents -- including having an arbitrary package flat-out
replace libc.so.So a whole lotta faith is being put into that 3rd
party being benevolent, being security conscious in protection of
signing keys, and not ever getting hacked. (is this big elephant in
the room part of why there seems to be a dearth of any detailed Apt
configuration security best practices?) (debsums after the fact
might be a good thing to have configured just to warn when something
does get borked, but in the case of dynamic lib SOs -- nothing stops a
symlink diversion to an alternate .so either, which wouldn't get
reported, since the symlink is dynamically created outside the package
contents)
But, my real question is about how best to configure Apt for when you
*do* make the leap of faith to add a 3rd party source.
There's some question of whether not adding the PGP keys of the
source/package signers and having to manually intervene in the Apt
install warnings is a good idea to keep from accidentally
automatically installing something suspicious. (breaks
unattended-upgrades, obviously) Anybody do this?
Does it make sense to configure APT Preferences to allow only
DESIRED/KNOWN packages from that source to be installable.
I do that for Redhat/Yum via something like:
# Only let CFEngine be installed from EPEL
kwriteconfig --file /etc/yum.repos.d/epel.repo --group 'epel'
--key 'includepkgs' 'cfengine'
E.G. for Google packages, something like:
[/etc/apt/sources.list.d/google*.list]
deb http://dl.google.com/linux/chrome/deb/ stable main
deb http://dl.google.com/linux/earth/deb/ stable main
[/etc/apt/preferences.d/google.pref]
Package: google-earth-stable
Explanation: Allow google-earth-stable to be installed/upgraded
Pin: origin "dl.google.com"
Pin-Priority: 100
Package: google-chrome-stable
Explanation: Allow google-chrome-stable to be installed/upgraded
Pin: origin "dl.google.com"
Pin-Priority: 100
Package: *
Explanation: Disallow all other packages from dl.google.com
Pin: origin "dl.google.com"
Pin-Priority: -1000
lists# apt-cache policy google-chrome-stable
google-chrome-stable:
Installed: 39.0.2171.99-1
Candidate: 40.0.2214.91-1
Package pin: 40.0.2214.91-1
Version table:
40.0.2214.91-1 100
-1000 http://dl.google.com/linux/chrome/deb/ stable/main
amd64 Packages
*** 39.0.2171.99-1 100
100 /var/lib/dpkg/status
AFAICT, this preferences setting *should* disallow 'dl.google.com'
from ever being able to offer a spoofed system package such as
'libc6', allowing that source to only provide the packages
'google-earth-stable' and 'google-chrome-stable'. It would also
prevent the possibility of that source offering a new package that
might accidentally get installed by 'typo' ( new package 'lib6c', hyuk
) or by an administrator who mistakenly sees a package show up
(aptitude search...) that looks useful, thinking it's part of the OS
distribution.
But, is this worthwhile -- does it actually protect you from something
that Apt wouldn't allow anyway?
lists# apt-cache policy libc6 | sed -e 's=\(https\{0,1\}\|ftp\):[^
]*=URI-REDACTED='
libc6:
Installed: 2.13-38+deb7u6
Candidate: 2.13-38+deb7u6
Version table:
*** 2.13-38+deb7u6 0
990 URI-REDACTED wheezy/main amd64 Packages
100 /var/lib/dpkg/status
2.13-38+deb7u4 0
990 URI-REDACTED wheezy/updates/main amd64 Packages
So, i don't have a 3rd party repo defined for libc6 (just site caching
repos). But what is to stop 'dl.google.com' from offering 2.15 of
libc6 and 'aptitude upgrade' installing it?
thanks,
--stephen
--
Stephen Dowdy - Systems Administrator - NCAR/RAL
303.497.2869 - sdo...@ucar.edu - http://www.ral.ucar.edu/~sdowdy/
--
To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive:
https://lists.debian.org/ca+czzdar+d0uffbqgvzpfdzilceztktwucys7ghjwsuh+hr...@mail.gmail.com
