On Thu, Aug 12, 2021 at 08:32:14AM +0200, Vincent Bernat wrote: > ❦ 12 August 2021 10:39 +05, Andrey Rahmatullin: > >> I just ran across this article > >> https://blog.ikuamike.io/posts/2021/package_managers_privesc/ I tested > >> the attacks on Debian 11 and they work successfully giving me a root > >> shell prompt. > > I don't think calling this "privilege escalation" or "attack" is correct. > > The premise of the post is "the user should not be a root/admin user but > > has been assigned sudo permissions to run the package manager" and one > > doesn't really need a long article to prove that it's not secure. > > I think the article is interesting nonetheless. Some people may think > that granting sudo on apt is OK. In the past, I think "apt install > ./something.deb" was not possible.
It wasn't that easy, but if you can feed config options into apt you can basically do whatever (like setting a sources.list, including your own local repo including your bad deb). Beside the command line -o and -c you can also use environment variable APT_CONFIG. APT (, dpkg, …) just never was designed to be used in a restricted way or we wouldn't have hundreds upon hundreds of options to do all sorts of (sometimes) crazy things like using apt for bootstrap… I would say dd-schroot-cmd is a good example of what you would need, although I am relatively sure someone truly hostile can find a way if enough energy is invested (and then there is always the risk of the APT team adding yet another innocent option derailing the plan like the ability to install deb files directly used to back in 2014). > Maybe it would be worth to also set LESSSECURE (less is not the default > pager on minimal installs but I think it is the most common, more cannot > be secured this way). External solvers (--solver/--planner) are run as a (configurable) different user, currently defaulting to _apt. That is nice, as it isn't root, but _apt is also used by the download methods, which means it can have permissions to files it shouldn't have. Ideally, we would need an extra user for that. Except that different solvers probably shouldn't be able to access each other, so multiple I guess. Can't really be nobody (or a temporary) as the solvers might very well have their own config, cache, I could even envision some asking an online oracle for input (reproducible, open bugs, …) and firewall rules for nobody are bad ……… sorry, my head hurts, were where I? Right, pagers. Ideally I would like to not run them as root as well, but they are a lot more user facing, so if your usual config (hello lesspipe) disappears it is sad. Fun would be to run the pager as the user who sudoed initially… :P We could set this environment variable I guess, but dpkg doesn't set it either and a quick codesearch in Debian suggests that while the variable seems sufficiently ancient (console-log changelog mentions it in 2000) I don't see a whole lot of adoption – and golang-github-sean--pager surprises me with setting it only if the called pager is named less. Not sure I like systemds envvar to override an envvar either (and they of course all use different LESS flags to begin with). So, before I am rushing off to do whatever I like, could we perhaps agree on a "sensible-restricted-pager" (I dare not to name it secure…) sort-of implementation first? Oh and, btw, there is no point¹ in running 'apt changelog' with root permissions – it is beside the point here, but I feel obligated to mention it. Best regards David Kalnischkies ¹ well, there is a teeny weeny one: an outdated binary cache is updated and stored on disk rather then build in memory and discarded afterwards, but ideally your cache isn't outdated – it usually isn't if you aren't doing things with envvars, options, …
signature.asc
Description: PGP signature
