Re: Limiting the power of packages

[Enrico Weigelt, metux IT consult]

On 19.11.18 20:24, gregor herrmann wrote:
> On Mon, 19 Nov 2018 17:29:37 +0100, Enrico Weigelt, metux IT consult wrote:
> 
> (OT, but since I noticed it too:)
> 
>> Anyways, Skype doesn't work since 8.30 as it crashes directly on
>> startup.
> 
> Apparently it needs (e)logind since that version.

That didn't help neither.

Few days ago, I tried their inofficial preview build, which doesn't seem
to crash anymore. Let's see what happens when the official release
comes.


--mtx


-- 
Enrico Weigelt, metux IT consult
Free software and Linux embedded engineering
i...@metux.net -- +49-151-27565287

Re: Limiting the power of packages

[gregor herrmann]

On Mon, 19 Nov 2018 17:29:37 +0100, Enrico Weigelt, metux IT consult wrote:

(OT, but since I noticed it too:)

> Anyways, Skype doesn't work since 8.30 as it crashes directly on
> startup.

Apparently it needs (e)logind since that version.


Cheers,
gregor

-- 
 .''`.  https://info.comodo.priv.at -- Debian Developer https://www.debian.org
 : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D  85FA BB3A 6801 8649 AA06
 `. `'  Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe
   `-   NP: Cat Stevens: Father and Son


signature.asc
Description: Digital Signature

Re: Limiting the power of packages

[Enrico Weigelt, metux IT consult]

On 07.10.18 21:20, Adrian Bunk wrote:

> For leaf software like Skype or Chrome, approaches like flatpak where> 
> software can be installed by non-root users and then runs confined>
have a more realistic chance of being able to becoming a good solution.
I'd rather put those non-trustworthy code them into a minimal container
w/ fine tuned minimal permissions.

Anyways, Skype doesn't work since 8.30 as it crashes directly on
startup.


--mtx

-- 
Enrico Weigelt, metux IT consult
Free software and Linux embedded engineering
i...@metux.net -- +49-151-27565287

Re: Limiting the power of packages

[Jonathan Dowland]

On Sun, Oct 07, 2018 at 01:06:54PM +0200, Tomas Pospisek wrote:

I think Linux systems per se, Debian as a runtime, the (social)
processes required from DDs/DMs, the whole technical Debian packaging
ecosystem are each plenty complex enough already.

…

they IMHO should serve as a dimension to measure Debian's/Linux'
progress against and as a yard stick to measure our solutions against:


As a general principle I think this is an important thing to consider,
but not the sole criterion for any proposed enhancement to Debian. But
for sure an important one. I'm reminded of my dormant attempts to
measure and report on the "surface area" of debian development (which I
do hope to pick back up)


These points above do not imply that Lars' idea is bad and should not be
pursued.


Lars layed out a problem, your criterion should be used to measure
proposed solutions. The problem itself does not necessarily imply an
increase in complexity. For example we've discussed the idea of
declarative maintainer scripts as (part of) a potential solution: I'd
argue that these are far simpler than anything-goes shell scripts.

--

⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Jonathan Dowland
⢿⡄⠘⠷⠚⠋⠀ https://jmtd.net
⠈⠳⣄ Please do not CC me, I am subscribed to the list.

Re: Limiting the power of packages

[Adrian Bunk]

On Wed, Oct 03, 2018 at 08:19:17PM +0300, Lars Wirzenius wrote:
>...
> A suggestion: we restrict where packages can install files and what
> maintainer scripts can do. The default should be as safe as we can
> make it, and packages that need to do things not allowed by the
> default should declare they that they intend to do that.
>...

The most common real world problem is actually a popular 3rd party 
repository that provides slightly modified versions of several libraries 
in Debian, and their version has an epoch added.

There are plenty of incoming bugs in Debian where a still installed 
"ancient but with epoch" version of such a library is the cause.

We cannot realistically make installing random 3rd parties safe, the 
only proper handling is that we continue to consider this unsupported
by Debian.

And for malicious packages the user would anyways still run into
a variant of https://xkcd.com/1200/ since the user will surely
want to run the installed software.

For leaf software like Skype or Chrome, approaches like flatpak where
software can be installed by non-root users and then runs confined
have a more realistic chance of being able to becoming a good solution.

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

Re: Limiting the power of packages

[Tomas Pospisek]

On 3 Oct 2018 Lars Wirzenius wrote:

> A suggestion: we restrict where packages can install files and what
maintainer scripts can do.

On 4 Oct 2018 Enrico Weigelt wrote:

> Finally, I'd really like to reduce complexity, not introduce even more.

+1

I think Linux systems per se, Debian as a runtime, the (social)
processes required from DDs/DMs, the whole technical Debian packaging
ecosystem are each plenty complex enough already. So adding more
complexity will:

* increase friction and dissipative heat production, which means less
software in Debian, less DMs/DDs, less fun, pushing mean temperatures on
earth further up

* increase the number of edge cases, increase the number of possible
interactions between different parts of the whole system, reduce the
ability of us users/DDs/DMs to reason about/understand/cope with our systems

These points above do not imply that Lars' idea is bad and should not be
pursued. Instead they IMHO should serve as a dimension to measure
Debian's/Linux' progress against and as a yard stick to measure our
solutions against:

* did the added constraint or tech reduce or increase complexity and our
ability to reason about the system?

* did the new tech enable us to throw away part of older tech that was
badly defined, complex, broken?

* did the new solution advance us toward a model that is easier to
understand?

*t

Re: Limiting the power of packages

[David Bremner]

Laurent Bigonville  writes:

> Lars Wirzenius wrote:
>
>> * default: install files in /usr only
>> * kernel: install files in /boot, trigger initramfs
>> * core: can install files anywhere, trigger anything
>> * maintained-by-liw: full power to do anything
>>
>> This might be implemented in various ways. For example, dpkg could
>> create a temporary directory, and bind mount the directories the
>> profile indicates are needed, into a temporary shadow of the full
>> system. Maintainer scripts would be run in the shadow environment.
>> Thus, if they try to do something that isn't allowed by the packages
>> profile, they can't.
> This can be done with SELinux as well, the maintainer scripts can be 
> labeled and dpkg will run them in the desired context.

I like the general project, but feel obliged to point out that having
maintainer scripts fail is not nice for users, so we'd need to think
about how to handle security/liw-classification failures.

d

Re: Limiting the power of packages

[Laurent Bigonville]

Lars Wirzenius wrote:


* default: install files in /usr only
* kernel: install files in /boot, trigger initramfs
* core: can install files anywhere, trigger anything
* maintained-by-liw: full power to do anything

This might be implemented in various ways. For example, dpkg could
create a temporary directory, and bind mount the directories the
profile indicates are needed, into a temporary shadow of the full
system. Maintainer scripts would be run in the shadow environment.
Thus, if they try to do something that isn't allowed by the packages
profile, they can't.
This can be done with SELinux as well, the maintainer scripts can be 
labeled and dpkg will run them in the desired context.

Re: Limiting the power of packages

[Thomas Goirand]

On 10/4/18 12:23 PM, Jonathan Dowland wrote:
> On Thu, Oct 04, 2018 at 12:09:05PM +0200, Thomas Goirand wrote:
>> And prevent stuff like with the bumblebee uninstall disaster because of
>> an added space, for example:
>>
>> rm -rf /usr /share/foo/bar.conf
> 
> Yes, or the similar bug in steam-for-linux steam.sh. Although neither
> made it into the Debian archive, so adding the features being discussed
> won't protect users who run external install scripts like these two
> examples.

The same kind of mistake could happen in a postrm script. And we really
want to prevent that.

One thing which I really would love to have as a declarative thing:

owned_config_file=foo.conf,username:group

would create username and group if absent from the system, copy foo.conf
from /usr/share/package-name/foo.conf to /etc/foo/foo.conf, with correct
640 rights owned by root:group, and remove foo.conf on purge.

I don't mind where this is declared (in debian/rules, or elsewhere), but
this shouldn't go in a maintainer script, as it affects multiple ones
(ie: postinst, postrm, etc.).

>From my experience, the more declarative things there is, the less
errors one makes. I've been caught numerous time forgetting to remove
foo.conf on purge... (shame on me). Lucky there's puiparts to catch
them, though it should just not happen!

Cheers,

Thomas Goirand (zigo)

Re: Limiting the power of packages

[Paul Wise]

On Fri, Oct 5, 2018 at 3:20 AM Simon Richter wrote:

> We could bring the same to dpkg by moving things out of maintainer scripts
> and into control files. The big items would be
>
>  - alternatives
>  - diversions
>  - statoverride
>  - service start/stop

The dpkg maintainers have this on their radar:

https://wiki.debian.org/Teams/Dpkg/Spec/DeclarativePackaging

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: Limiting the power of packages

[W. Martin Borgert]

On 2018-10-04 21:10, Simon Richter wrote:
> We could bring the same to dpkg by moving things out of maintainer scripts
> and into control files. The big items would be
>
>  - alternatives
>  - diversions
>  - statoverride
>  - service start/stop

I agree and like to add:

 - create system users/groups
 - update-icon-cache and similar
 - create various symlinks
 - some directory and file creation in postinst could probably avoided, too

Cheers

Re: Limiting the power of packages

[Simon Richter]

Hi,

> A suggestion: we restrict where packages can install files and what
> maintainer scripts can do. The default should be as safe as we can
> make it, and packages that need to do things not allowed by the
> default should declare they that they intend to do that.

I've held a short inflammatory lightning talk at DebConf9 in Cáceres about
that, comparing dpkg against Microsoft Installer. :)

MSI solves this quite nicely: packages are collections of relational
database tables, each table provides the parameters for an action, and the
actions themselves are defined by the core installer (with a plugin
interface for custom actions, which noone uses).

This means that any package that doesn't use any plugins can be evaluated
externally by looking at the table data, and Small Business Server includes
a tool to statically check packages for conflicts.

We could bring the same to dpkg by moving things out of maintainer scripts
and into control files. The big items would be

 - alternatives
 - diversions
 - statoverride
 - service start/stop

If we had control files for these, a lot of maintainer scripts would simply
be empty, especially in the base system that would be really helpful for
"debootstrap --foreign", where the host system could run the actions in the
newly installed system even if the architecture does not match, and we
could avoid running services in freshly installed chroots as well.

Smaller items:

 - ldconfig could be a control file as well -- if it's present, we need to
   run ldconfig.

We already have a solution for that with file-based triggers, but this
would be also be more transparent for "debootstrap --foreign".

 - Moving files into new locations would need a table

old version; new version; old location; new location

When upgrading from a version between the old and new versions, the files
need to be moved (this would catch preinst for move, and postinst for
aborted-upgrade).

 - Updates from debconf to files in /etc/default

This requires some more thought than I can provide at this late hour.

 - Installation of new APT sources and keys

Having the information as descriptive data will allow filtering and adding
constraints during source/key installation, e.g. by keeping keys installed
through this mechanism associated with the source installed in the same
package, and having packages from the source inherit constraints from the
package that provided the source.

Ideally, maintainer scripts would be a last-resort option if none of the
existing descriptive mechanisms works.

Packages using these control files would obviously require a dpkg version
that supports them, and we'd also need a mechanism for adding new control
files over time.

The main difficulty I see is keeping compatibility for upgrades, so stable
dpkg can still install packages from unstable. My proposal would be that
packages start using "_alternatives" first (which dpkg knows to ignore if
it doesn't understand it, it's almost as if someone knew what they were
doing back then) together with a maintainer script that makes the
alternatives handling conditional on the return code of a query command
that checks if dpkg handles the control file internally. Then, a few years
later, we transition to "alternatives" as a control file, and no maintainer
script. Most packages would probably use dh_alternatives for that anyway.

   Simon

Re: Limiting the power of packages

[Wouter Verhelst]

On Thu, Oct 04, 2018 at 01:27:29PM +0200, Enrico Weigelt, metux IT consult 
wrote:
> Yes, that would have to be customized per-package, but we're only
> talking about a hand full of packages, anyways.

Eh, no.

-- 
Could you people please use IRC like normal people?!?

  -- Amaya Rodrigo Sastre, trying to quiet down the buzz in the DebConf 2008
 Hacklab

Re: Limiting the power of packages

[Ralf Treinen]

On Thu, Oct 04, 2018 at 11:07:37AM +0200, W. Martin Borgert wrote:
> On 2018-10-03 23:30, Antoine Beaupré wrote:
> > There
> > are somewhat low-hanging fruits in there like declarative maintainer
> > scripts.
> 
> I am very much in favour of declarative maintainer scripts!
> AFAIK, Niels Thykier has done a lot of work there, while Ralf
> Treinen and colleagues are analysing maintainer scripts - they
> even wrote a shell script parser, that is not a shell itself.

Indeed, our goal is to do QA on maintainer script and to detect
(possibly) buggy ones, in the sense that they may fail in a 
unforeseen situation, or do stuff which the script is not supposed
to do. One of the difficulties is of course to know what it is
supposed to do, and what it must never do. Having a declaration
of what the maintainer thinks are the possible effects of a script
would certainly help us. In that case we could try to infer the
possible effects of a script and check that they do not exceed
what is declared.

> However, I would not try to see this work too much as means of
> defense against malicious deb packages. This leads to a wrong,
> non-achievable goal. I see it as a means to provide better
> quality, predictable system state, and safety against bugs.

yes, safety against a malicious attacker is a completely different
league. As Guillem has explained in his mail it is very difficult to
achieve due to the presence of many different attack vectors, and
their possible interaction.

-Ralf.

Re: Limiting the power of packages

[intrigeri]

Paul Wise:
> On Thu, Oct 4, 2018 at 11:31 AM Antoine Beaupré wrote:
>> Beyond this issue, what I'm mostly concerned about these days is
>> isolation between different apps. Our only solution on the desktop right
>> now is Qubes and it seems rather overengineered for my needs.

> Our solution here is AppArmour.

Sadly, AppArmor is not very well suited _for desktop apps_ at the
moment. Approaches based on sandboxing + portals seem to be a much
better design.

Cheers,
-- 
intrigeri

Re: Limiting the power of packages

[Philipp Kern]

On 04.10.2018 13:17, Enrico Weigelt, metux IT consult wrote:
>> (Note that I'm not saying Microsoft or Google are doing something
>> nefarious here: 
> 
> But I do think that. If they really wanted to do that in a reasonably
> secure and safe way (assuming they're not completely incompetent),
> they'd split off the sources.list part from the actual package (there're
> many good ways to do that), and added proper pinning to reduce the
> attack surface.
> 
> And they would have talked to the Distros about a proper process of
> bringing Skype into Distro repos.
> 
> OTOH, considering the tons of other bugs and design flaws, I'm not
> really sure whether they're nefarious or incompetent, maybe a mix of
> both ...

It's not like Debian provides a way that nicely integrates with the
system except by what they are doing. Yes, one could ship a pin to limit
to specific packages, but from the point of the vendor there's no threat
here: They know what they are going to ship. And from a vendor point of
view you actually want to have the agility to rotate the GPG key in use,
to switch to a different hosting place, and to ship more packages as
required. So it's just that your and the vendor's assumptions mismatch.

Ultimately what most users want is something that is kept up-to-date. At
the point where they decided that they want (or need) to use a vendor's
software, it's not really our business anymore to tell them off. You
yield full control to the vendor at that point, just like Debian has
full control of your system.

If we had a sensible way to report back binary provenance, we could at
least call out when a vendor did something nefarious. (Like serving a
trojan to a specific user.) But we don't.

And to the point of nefavious vs. incompetence: The truth is that most
companies employ software engineers to do the packaging. Apart from
Linux being a small market for most of this software, it is also
something they are not necessarily familiar with or would need to hire
some kind of specialist for. I understand that you are in that business.
But at the same time most programmers assume that it's just a small
matter of programming and it can't be that hard to integrate with
another system. They can't really anticipate the bugs. But we at least
need to hold them accountable to listening to feedback.

> That way, the vendors could just pick some minimal base system (maybe
> apline or devuan based) [...]

That's also where you lost me, FWIW.

Kind regards
Philipp Kern

Re: Limiting the power of packages

[Xavier]

Le 04/10/2018 à 13:20, Paride Legovini a écrit :
> Lars Wirzenius wrote on 03/10/2018:
>> The problem: when a .deb package is installed, upgraded, or removed,
>> the maintainer scripts are run as root and can thus do anything.
>>
>> Sometimes what they do is an unwelcome surprise to the user. For
>> example, the Microsoft Skype .deb and the Google Chrome .deb add to
>> the APT sources lists and APT accepted signing keys.
> 
>> A suggestion: we restrict where packages can install files and what
>> maintainer scripts can do.
> 
>> This could be done, for example, by having each package labelled with
>> an installation profile, which declares what the package intends to do
>> upon installation, upgrade, or removal.
>>
>> * default: install files in /usr only
>> * kernel: install files in /boot, trigger initramfs
>> * core: can install files anywhere, trigger anything
> 
> This would be a nice safety feature for users and for us maintainers: I
> know I won't screw up anybody's system with a font package as I
> restricted it to /usr/share and /etc/fonts.
> 
> But I don't think it would solve the problem you pose. Who is going to
> set the profile? If if is the 3rd party packager, they will just use
> 'core' and install their APT source (or whatever they want). If it can
> be specified or overridden by the user at install time, then trying to
> install Skype with --profile=default will make the installation fail,
> and the user will just resort to --profile=core.
> 
> Paride

Hi all,

other ideas:
- use a sort of restricted shell (or a meta language) for {pre,post}int
  scripts and debian/rules: only access to debconf db and its own files
   => So no way to execute a custom script during install.
- remove suid bits unless package is signed by Debian: it means that
  there could be 2 different key stores: apt one and dpkg one

My 2 cents...

Xavier

Re: Limiting the power of packages

[Enrico Weigelt, metux IT consult]

On 04.10.2018 01:19, Carl-Valentin Schmitt wrote:
> It would be a possibility, for safety to create a new directory only for
> brandy 3rd-party-software like skype, Google Chrome, Swift, and else
> Software where huge companies are Sponsors.
>  
> This would then mean, to create a second sources list for 3rd-party-links.

We don't need to add anything to dpkg/apt for that - there's a simpler
solution:

Automatically fetch those packages from the vendor and collect them into
our own repo, but run a strict analysis before accepting anything.
Rules could be strictly limiting to certain filename patterns, file
modes (eg. forbid suid or limit to certain owners), no maintainer
scripts, etc, etc. We could either filter out anything suspicious or
reject the package completely (maybe even automatically filing
upstream bugs :p).

Yes, that would have to be customized per-package, but we're only
talking about a hand full of packages, anyways.


What's really important for me: don't add more complexity on the
target apt/deb for these few cases, unless *absolutely* *necessary*


By the way: we can put aside the whole Skype issue for the next few
month, as it's completely broken and unusable anyways - for several
month now. We could reconsider once the Upstream (Microsoft) manages
get it at least running w/o segfaulting.


--mtx

-- 
Enrico Weigelt, metux IT consult
Free software and Linux embedded engineering
i...@metux.net -- +49-151-27565287

Re: Limiting the power of packages

[Paride Legovini]

Lars Wirzenius wrote on 03/10/2018:
> The problem: when a .deb package is installed, upgraded, or removed,
> the maintainer scripts are run as root and can thus do anything.
> 
> Sometimes what they do is an unwelcome surprise to the user. For
> example, the Microsoft Skype .deb and the Google Chrome .deb add to
> the APT sources lists and APT accepted signing keys.

> A suggestion: we restrict where packages can install files and what
> maintainer scripts can do.

> This could be done, for example, by having each package labelled with
> an installation profile, which declares what the package intends to do
> upon installation, upgrade, or removal.
> 
> * default: install files in /usr only
> * kernel: install files in /boot, trigger initramfs
> * core: can install files anywhere, trigger anything

This would be a nice safety feature for users and for us maintainers: I
know I won't screw up anybody's system with a font package as I
restricted it to /usr/share and /etc/fonts.

But I don't think it would solve the problem you pose. Who is going to
set the profile? If if is the 3rd party packager, they will just use
'core' and install their APT source (or whatever they want). If it can
be specified or overridden by the user at install time, then trying to
install Skype with --profile=default will make the installation fail,
and the user will just resort to --profile=core.

Paride

Re: Limiting the power of packages

[Enrico Weigelt, metux IT consult]

On 03.10.2018 19:19, Lars Wirzenius wrote:

> Sometimes what they do is an unwelcome surprise to the user. For
> example, the Microsoft Skype .deb and the Google Chrome .deb add to
> the APT sources lists and APT accepted signing keys. Some users do not
> realise this, and are unpleasantly surprise.

https://seclists.org/fulldisclosure/2018/Sep/53

> (Note that I'm not saying Microsoft or Google are doing something
> nefarious here: 

But I do think that. If they really wanted to do that in a reasonably
secure and safe way (assuming they're not completely incompetent),
they'd split off the sources.list part from the actual package (there're
many good ways to do that), and added proper pinning to reduce the
attack surface.

And they would have talked to the Distros about a proper process of
bringing Skype into Distro repos.

OTOH, considering the tons of other bugs and design flaws, I'm not
really sure whether they're nefarious or incompetent, maybe a mix of
both ...

> they're trying to make sure security updates for their
> packages will be deployed to user's system; this seems like a worthy
> goal. But it's a surprise to some users.)

The goal is nice, but that's what Distros are for. But it's always
the same since aeons: commercial vendors tend to work against the
distros.

> I don't think it's good enough to say the user shouldn't install
> third-party packages. 

Actually, I do think so (unless the user knows exactly what he does).
It's not about proprietary software in general - this can (and is)
also handled by Distros. But the Distro (or some other neutral
project, that provides an extra repo) is needed as quality gate.

> It's not even good enough to say the user should
> use flatpaks or snaps instead: not everything can be packaged that
> way. Debian's own packages can have equally unwelcome surprises.

Haven't really looked deeper into flatpak, but I'm doing a lot with
docker and lxc containers.

As those proprietary vendors tend to be completely overstrained with
the whole concept of package management (no idea why, but I've seen
this a thousand times w/ my clients), it seems to be the most pragmatic
solution to put everything into strictly isolated containers.

Those packages are only few special cases anyways. (for the average
end-user I don't see much more candidates besides Skype, but there's
still a lot very special business applications each having a petty tiny
user base).

That way, the vendors could just pick some minimal base system (maybe
apline or devuan based) and step by step learn how to use package
management, in their own confined microcosmos. At least they wouldn't
have to cope w/ many different distros, as long as they haven't
understood the whole concept behind (if they did, it would be pretty
trivial for them, and we wouldn't need this this discussion).

> Imagine a package that accidentally removes /var, but only under
> specific conditions. You'd hope that Debian's testing during a release
> cycle would catch that, but there's not guarantee it will. (That's a
> safety issue more than a security issue.)

Did this ever happen ? Why should anybody write such things into a
maintainer script in the first place ?

> A suggestion: we restrict where packages can install files and what
> maintainer scripts can do. The default should be as safe as we can
> make it, and packages that need to do things not allowed by the
> default should declare they that they intend to do that.

Rebuild flatpak+friends ?

Point is: maintainer scripts can do anything they want.

What we can (and should) do is doing most things in a purely declarative
way - at deployment time, instead of autogenerating mnt scripts or
calling predefined functions - so we can concentrate on more careful
reviews of the remaining special cases.

By the way: at lot of the demand for mnt scripts, IMHO, comes from
upstream's bad sw architecture (interestingly, GUI stuff again tends
to be the ugliest area). Usually, good packages should be fine with just
unpacking some files into proper places.

> This could be done, for example, by having each package labelled with
> an installation profile, which declares what the package intends to do
> upon installation, upgrade, or removal.

Who defines these labels ? The packager ? Is there any extra quality
gate (before the user) ?

> * default: install files in /usr only

That's bad enough, if the package is of bad quality or even malicious.

Finally, I'd really like to reduce complexity, not introduce even more.


--mtx

-- 
Enrico Weigelt, metux IT consult
Free software and Linux embedded engineering
i...@metux.net -- +49-151-27565287

Re: Limiting the power of packages

[Jonathan Dowland]

On Thu, Oct 04, 2018 at 12:09:05PM +0200, Thomas Goirand wrote:

And prevent stuff like with the bumblebee uninstall disaster because of
an added space, for example:

rm -rf /usr /share/foo/bar.conf


Yes, or the similar bug in steam-for-linux steam.sh. Although neither
made it into the Debian archive, so adding the features being discussed
won't protect users who run external install scripts like these two
examples.


--

⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Jonathan Dowland
⢿⡄⠘⠷⠚⠋⠀ https://jmtd.net
⠈⠳⣄ Please do not CC me, I am subscribed to the list.

Re: Limiting the power of packages

[Jonathan Dowland]

On Thu, Oct 04, 2018 at 01:19:43AM +0200, Carl-Valentin Schmitt wrote:

It would be a possibility, for safety to create a new directory only for
brandy 3rd-party-software like skype, Google Chrome, Swift, and else
Software where huge companies are Sponsors.

This would then mean, to create a second sources list for 3rd-party-links.


This would not restrict what those packages would do, so it's orthogonal
to what we are discussing here.


--

⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Jonathan Dowland
⢿⡄⠘⠷⠚⠋⠀ https://jmtd.net
⠈⠳⣄ Please do not CC me, I am subscribed to the list.

Re: Limiting the power of packages

[Thomas Goirand]

On 10/4/18 10:06 AM, Jonathan Dowland wrote:
> On Wed, Oct 03, 2018 at 11:30:40PM -0400, Antoine Beaupré wrote:
>> Yet I still think we should start fixing those problems. 
> 
> +1
> 
>> Yes, there are a billion things that could go wrong in the current
>> approach, but if we had *some* safety net, controlled in the
>> sources.list file, we could at least restrict what third-party packages
>> would do.
> 
> Not just third-party packages: this isolation feature could limit the
> damage that could occur from buggy maintainer scripts in Debian's own
> scripts too.

And prevent stuff like with the bumblebee uninstall disaster because of
an added space, for example:

rm -rf /usr /share/foo/bar.conf

Cheers,

Thomas Goirand (zigo)

Re: Limiting the power of packages

[Thomas Goirand]

On 10/4/18 1:19 AM, Carl-Valentin Schmitt wrote:
> It would be a possibility, for safety to create a new directory only for
> brandy 3rd-party-software like skype, Google Chrome, Swift, and else
> Software where huge companies are Sponsors.
>  
> This would then mean, to create a second sources list for 3rd-party-links.

What you really want here is a 3rd party non-free bikeshed.

Cheers,

Thomas Goirand (zigo)

Re: Limiting the power of packages

[W. Martin Borgert]

On 2018-10-03 23:30, Antoine Beaupré wrote:
> There
> are somewhat low-hanging fruits in there like declarative maintainer
> scripts.

I am very much in favour of declarative maintainer scripts!
AFAIK, Niels Thykier has done a lot of work there, while Ralf
Treinen and colleagues are analysing maintainer scripts - they
even wrote a shell script parser, that is not a shell itself.

However, I would not try to see this work too much as means of
defense against malicious deb packages. This leads to a wrong,
non-achievable goal. I see it as a means to provide better
quality, predictable system state, and safety against bugs.

> Compared
> with the security models of iOS or Android, we still have quite a lot of
> work to do to make sure (say) my IRC client cannot steal my bank
> credentials or (the horror!) vice-versa. ;)

:~)

Re: Limiting the power of packages

[W. Martin Borgert]

On 2018-10-04 09:06, Jonathan Dowland wrote:
> What about running Chromium as root? Certainly not recommended, but what
> are the user's expectations if they try it anyway?

With nowadays web, I would disallow this by default. If root
types their sentence ("Yes, I know..."), they can shoot themself
in every single toe with only one shot.

Re: Limiting the power of packages

[Florian Weimer]

* Simon McVittie:

> On Thu, 04 Oct 2018 at 08:34:15 +0200, Florian Weimer wrote:
>> * Paul Wise:
>> > To fully solve the problem you need a whitelist based approach that
>> > ends up something completely different like Flatpak.
>> 
>> Flatpaks don't work this way.  Try installing gedit and open a file
>> like ~/.ssh/id_rsa with it.  There are no security prompts whatsoever,
>> yet the software in a flatpak can read your SSH private key.
>
> That particular app's whitelist presumably includes "share the entire
> host filesystem"; the existence of a whitelist doesn't mean the whitelist
> isn't large. General-purpose development tools and text editors generally
> have larger whitelists than more limited apps, with GNOME Builder at
> the extreme of least-confined.

The other problem is that the whitelist comes from the application
author, so it's like asking a drunk whether they are drunk.

> % flatpak --user install flathub org.gnome.gedit
> Installing in user:
> org.gnome.Platform.Locale/x86_64/3.28 flathub 2823e3d81b74
> org.gnome.gedit/x86_64/stable flathub a03b66681bce
>   permissions: ipc, wayland, x11
>   file access: host, xdg-run/dconf, ~/.config/dconf:ro
>
> \- this is why it can read arbitrary files
>   dbus access: ca.desrt.dconf, org.gtk.vfs.*
> org.gnome.gedit.Locale/x86_64/stable  flathub c2974b37ef08
> Is this ok [y/n]:
>
> I think the intention is that GUIs like GNOME Software prompt for apps
> that need special permissions in a more user-friendly way, something
> like how Android handles app permissions, although I don't think that's
> actually implemented yet.

Yes, I tried this on Fedora 28 before posting, which I consider the
reference implementation.  There is no security prompt at all.

I've also been told in an other context that it is up to the Flatpak
repository to vet the permissions requested by the software authors.
This model would be closer to what the Debian archive does in
practice.

> I don't know specifically why gedit has the host file access
> permission: it's unnecessary for File->Open and File->Save
> As... (e.g. org.gnome.Recipes is a good example of an app that
> doesn't, but can still import and export recipes) but presumably some
> of gedit's IDE-like features involve opening files other than the one
> you directly asked for.

I assume it's because gedit creates backup files when saving, and the
document portal does not support that.

Re: Limiting the power of packages

[Jonathan Dowland]

On Wed, Oct 03, 2018 at 11:30:40PM -0400, Antoine Beaupré wrote:
Yet I still think we should start fixing those problems. 


+1


Yes, there are a billion things that could go wrong in the current
approach, but if we had *some* safety net, controlled in the
sources.list file, we could at least restrict what third-party packages
would do.


Not just third-party packages: this isolation feature could limit the
damage that could occur from buggy maintainer scripts in Debian's own
scripts too.


For example, there's no reason why a package like Chromium should be
able to run stuff as root.


What about running Chromium as root? Certainly not recommended, but what
are the user's expectations if they try it anyway?

I don't know whether it's still true but at some point in the past
Chromium's sandbox feature required part of it to be suid root in order
to isolate itself.


Yes well, we *could* consider rewriting Debian to be based on
appimage/flatpak/snappy


Appimage does not provide the isolation features we are discussing here.


--

⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Jonathan Dowland
⢿⡄⠘⠷⠚⠋⠀ https://jmtd.net
⠈⠳⣄

Re: Limiting the power of packages

[Simon McVittie]

On Thu, 04 Oct 2018 at 08:34:15 +0200, Florian Weimer wrote:
> * Paul Wise:
> > To fully solve the problem you need a whitelist based approach that
> > ends up something completely different like Flatpak.
> 
> Flatpaks don't work this way.  Try installing gedit and open a file
> like ~/.ssh/id_rsa with it.  There are no security prompts whatsoever,
> yet the software in a flatpak can read your SSH private key.

That particular app's whitelist presumably includes "share the entire
host filesystem"; the existence of a whitelist doesn't mean the whitelist
isn't large. General-purpose development tools and text editors generally
have larger whitelists than more limited apps, with GNOME Builder at
the extreme of least-confined.

% flatpak --user install flathub org.gnome.gedit
Installing in user:
org.gnome.Platform.Locale/x86_64/3.28 flathub 2823e3d81b74
org.gnome.gedit/x86_64/stable flathub a03b66681bce
  permissions: ipc, wayland, x11
  file access: host, xdg-run/dconf, ~/.config/dconf:ro
   
\- this is why it can read arbitrary files
  dbus access: ca.desrt.dconf, org.gtk.vfs.*
org.gnome.gedit.Locale/x86_64/stable  flathub c2974b37ef08
Is this ok [y/n]:

I think the intention is that GUIs like GNOME Software prompt for apps
that need special permissions in a more user-friendly way, something
like how Android handles app permissions, although I don't think that's
actually implemented yet.

I don't know specifically why gedit has the host file access
permission: it's unnecessary for File->Open and File->Save
As... (e.g. org.gnome.Recipes is a good example of an app that
doesn't, but can still import and export recipes) but presumably some
of gedit's IDE-like features involve opening files other than the one
you directly asked for.

smcv

Re: Limiting the power of packages

[Paul Wise]

On Thu, Oct 4, 2018 at 3:24 PM Florian Weimer wrote:

> Flatpaks don't work this way.  Try installing gedit and open a file
> like ~/.ssh/id_rsa with it.  There are no security prompts whatsoever,
> yet the software in a flatpak can read your SSH private key.

AFAIK, the only way a Flatpak can read your SSH private key would be
because you told the file portal that runs outside the Flatpak
container to pass an fd of that file into the Flatpak container for
the app to read.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: Limiting the power of packages

[Florian Weimer]

* Paul Wise:

> To fully solve the problem you need a whitelist based approach that
> ends up something completely different like Flatpak.

Flatpaks don't work this way.  Try installing gedit and open a file
like ~/.ssh/id_rsa with it.  There are no security prompts whatsoever,
yet the software in a flatpak can read your SSH private key.

Re: Limiting the power of packages

[Paul Wise]

On Thu, Oct 4, 2018 at 11:31 AM Antoine Beaupré wrote:

> Yes well, we *could* consider rewriting Debian to be based on
> appimage/flatpak/snappy, but that would be a rather controversial
> change. I think there are smaller, incremental steps we can take before
> that to improve the situation without rewriting the whole world.

I definitely wasn't suggesting rewriting Debian, but about
automatically transforming existing Debian binary packages into
Flatpaks. This would also allow backporting apps to stable when it
isn't feasible to use the Debian backports repository.

> Beyond this issue, what I'm mostly concerned about these days is
> isolation between different apps. Our only solution on the desktop right
> now is Qubes and it seems rather overengineered for my needs.

Our solution here is AppArmour. It would be nice to see more of Qubes
(or Subgraph for that matter) in Debian though.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: Limiting the power of packages

[Guillem Jover]

Hi!

On Thu, 2018-10-04 at 08:38:09 +0800, Paul Wise wrote:
> On Thu, Oct 4, 2018 at 1:19 AM Lars Wirzenius wrote:
> > The problem: when a .deb package is installed, upgraded, or removed,
> > the maintainer scripts are run as root and can thus do anything.

Paul prompted a similar discussion the other day on #debian-apt after
posting a link to

(which BTW seems like a complete bogus report to me, but oh well).

> anarcat wrote this related wiki page that covers this general topic:
> 
> https://wiki.debian.org/UntrustedDebs
> 
> The maintainer scripts are just the first problem that comes up when
> installing untrusted packages.
> 
> There are myriad ways a package could install files that allow it to
> get root. setuid binaries, cron jobs, systemd units, apt keyring
> information, sudoers files and so on. The amount of stuff that can
> lead to root completely depends on the packages one already has
> installed. Then there are myriad other things that don't allow root
> that untrusted applications should not get hold of (like your private
> diary, some keys or passwords etc).

IMO the whole premise is flawed. If you do not trust the .deb, then you
should not be even installing it using dpkg, less running it unconfined,
as its paradigm is based on fully trusting the .debs, on using shared
resources, and on system integration. Let me expand:

 * To "safely" install an untrusted .deb we'd need (at least) to disarm
   the following (current or future) features:
   - any dependency (Provides, Replaces, (Pre-)Depends, Conflicts, Breaks).
 + can be used to pull in new attack vectors, for their interfaces,
   vulnerabilities, or to interpose functionality for some of their
   optional features, f.ex.
   - any maintainer script.
   - any trigger activation.
   - any future declarative diversions, alternatives or user creation.
   - any char/block device.
   - any symlink.
   - any suid bit.
   - any future xattrs, acls.
   - installation on anything that is part of the standard paths,
 including **/usr**, /var, /etc, /bin, /sbin, /lib, etc.
 + installing under /usr, means you can interpose programs, or
   takeover names for optional functionality used by other
   privileged programs, or install things that might end up being
   used by a privileged user.
 + the only viable candidate might be /opt, and existing programs
   might be even trying to read from there, so it might not even
   be safe.

 * To "safely" (perhaps, but I'd rather not) run these untrusted
   programs, you'd better contain this as much as possible, different
   real users, namespaces, virtualization, whatever, but definitely
   not running these directly from the PATH unconfined.

   (But then, I'm personally not very impressed with the security state
   of Linux (or any Unix) due to layers upon layers of complexity and
   patchwork to plug the holes. IMO any systems that is not founded
   upon a capabillity-based security paradigm is doomed.
   .)

 * Would need to define some way to denote these .debs as untrusted,
   but that should be done only by a trusted component, which (apt)?
   What happens if a user gets hold of such .deb and installs it
   manually with dpkg, not triggering the "untrusted mode"? Or we
   start signing the .deb container itself, and use debsig-verify to
   distinguish them.

 * Would need to define some kind of new metadata, that gets strongly
   validated, so that these stripped packages can get back some kind
   of integration in the system.

 * The only parts that have been "audited" and are considered attack
   vectors in dpkg are dpkg-deb and dpkg-source, as they can be used
   to analyze untrusted data. Everything else assumes fully trusted
   data.

So, while most of the above list could be implemented, what you get
left after stripping/disarming all the features, and adding back the
integration, etc., does not resemble a standard .deb, except for the
container format. :)

> To fully solve the problem you need a whitelist based approach that
> ends up something completely different like Flatpak.

Exactly, if you do not consider the original premise flawed, you might
as well use one of the tools that has been designed precisely for that
purpose?

Thanks,
Guillem

Re: Limiting the power of packages

[Antoine Beaupré]

On 2018-10-04 08:38:09, Paul Wise wrote:
> On Thu, Oct 4, 2018 at 1:19 AM Lars Wirzenius wrote:
>
>> The problem: when a .deb package is installed, upgraded, or removed,
>> the maintainer scripts are run as root and can thus do anything.
>
> anarcat wrote this related wiki page that covers this general topic:
>
> https://wiki.debian.org/UntrustedDebs
>
> The maintainer scripts are just the first problem that comes up when
> installing untrusted packages.
>
> There are myriad ways a package could install files that allow it to
> get root. setuid binaries, cron jobs, systemd units, apt keyring
> information, sudoers files and so on. The amount of stuff that can
> lead to root completely depends on the packages one already has
> installed. Then there are myriad other things that don't allow root
> that untrusted applications should not get hold of (like your private
> diary, some keys or passwords etc).

Yet I still think we should start fixing those problems. Yes, there are
a billion things that could go wrong in the current approach, but if we
had *some* safety net, controlled in the sources.list file, we could at
least restrict what third-party packages would do.

For example, there's no reason why a package like Chromium should be
able to run stuff as root. The vast majority of third-party repositories
out there mostly ship this one binary that does not require special
privileges other than installing stuff in /usr, without suid or any
special permissions.

> To fully solve the problem you need a whitelist based approach that
> ends up something completely different like Flatpak.
>
> It might become possible to convert .debs to Flatpak using something
> like the ArchLinux approach for this and a future version of
> mmdebstrap that might allow installing sub-essential.
>
> https://wiki.archlinux.org/index.php/Flatpak#Creating_apps_with_pacman

Yes well, we *could* consider rewriting Debian to be based on
appimage/flatpak/snappy, but that would be a rather controversial
change. I think there are smaller, incremental steps we can take before
that to improve the situation without rewriting the whole world.

The wiki page I wrote was a short inventory of some of that stuff. There
are somewhat low-hanging fruits in there like declarative maintainer
scripts. I would also like to see end-to-end trust verification (like we
see on Android) for .debs, although I'm not exactly sure how that could
work in practice. At least shipping the signatures to allow some manual
verification would be an easy first step.

==

The devil, of course, is in the details, and someone needs to sit down
and make sense of all that stuff. It *is* true that the flatpak model
does try to address a lot of those issues and we might want to consider
that more closely.

Beyond this issue, what I'm mostly concerned about these days is
isolation between different apps. Our only solution on the desktop right
now is Qubes and it seems rather overengineered for my needs. Compared
with the security models of iOS or Android, we still have quite a lot of
work to do to make sure (say) my IRC client cannot steal my bank
credentials or (the horror!) vice-versa. ;)

A.

-- 
Man is, at one and the same time, a solitary being and a social being,
   - Albert Einstein

Re: Limiting the power of packages

[Paul Wise]

On Thu, Oct 4, 2018 at 1:19 AM Lars Wirzenius wrote:

> The problem: when a .deb package is installed, upgraded, or removed,
> the maintainer scripts are run as root and can thus do anything.

anarcat wrote this related wiki page that covers this general topic:

https://wiki.debian.org/UntrustedDebs

The maintainer scripts are just the first problem that comes up when
installing untrusted packages.

There are myriad ways a package could install files that allow it to
get root. setuid binaries, cron jobs, systemd units, apt keyring
information, sudoers files and so on. The amount of stuff that can
lead to root completely depends on the packages one already has
installed. Then there are myriad other things that don't allow root
that untrusted applications should not get hold of (like your private
diary, some keys or passwords etc).

To fully solve the problem you need a whitelist based approach that
ends up something completely different like Flatpak.

It might become possible to convert .debs to Flatpak using something
like the ArchLinux approach for this and a future version of
mmdebstrap that might allow installing sub-essential.

https://wiki.archlinux.org/index.php/Flatpak#Creating_apps_with_pacman

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: Limiting the power of packages

[Carl-Valentin Schmitt]

It would be a possibility, for safety to create a new directory only for
brandy 3rd-party-software like skype, Google Chrome, Swift, and else
Software where huge companies are Sponsors.

This would then mean, to create a second sources list for 3rd-party-links.



Carl-Valentin Schmitt  schrieb am Do., 4. Okt. 2018,
01:06:

> in /usr only ?...
>
> I thought therefore in later years Linux had created /opt ?
>
>
>
> Lars Wirzenius  schrieb am Mi., 3. Okt. 2018, 19:19:
>
>> The problem: when a .deb package is installed, upgraded, or removed,
>> the maintainer scripts are run as root and can thus do anything.
>>
>> Sometimes what they do is an unwelcome surprise to the user. For
>> example, the Microsoft Skype .deb and the Google Chrome .deb add to
>> the APT sources lists and APT accepted signing keys. Some users do not
>> realise this, and are unpleasantly surprise.
>>
>> (Note that I'm not saying Microsoft or Google are doing something
>> nefarious here: they're trying to make sure security updates for their
>> packages will be deployed to user's system; this seems like a worthy
>> goal. But it's a surprise to some users.)
>>
>> I don't think it's good enough to say the user shouldn't install
>> third-party packages. It's not even good enough to say the user should
>> use flatpaks or snaps instead: not everything can be packaged that
>> way. Debian's own packages can have equally unwelcome surprises.
>>
>> Imagine a package that accidentally removes /var, but only under
>> specific conditions. You'd hope that Debian's testing during a release
>> cycle would catch that, but there's not guarantee it will. (That's a
>> safety issue more than a security issue.)
>>
>> A suggestion: we restrict where packages can install files and what
>> maintainer scripts can do. The default should be as safe as we can
>> make it, and packages that need to do things not allowed by the
>> default should declare they that they intend to do that.
>>
>> This could be done, for example, by having each package labelled with
>> an installation profile, which declares what the package intends to do
>> upon installation, upgrade, or removal.
>>
>> * default: install files in /usr only
>> * kernel: install files in /boot, trigger initramfs
>> * core: can install files anywhere, trigger anything
>> * maintained-by-liw: full power to do anything
>>
>> This might be implemented in various ways. For example, dpkg could
>> create a temporary directory, and bind mount the directories the
>> profile indicates are needed, into a temporary shadow of the full
>> system. Maintainer scripts would be run in the shadow environment.
>> Thus, if they try to do something that isn't allowed by the packages
>> profile, they can't.
>>
>> The profile should be in the Packages file, and each apt signing key
>> should specify which repository (i.e., Packages file) it applies to.
>> There may be per-key restrictions for what profiles are allowed.
>>
>> This is a quick thought, while I was trodding in the dark, wet, cold
>> evening to the grocery store. It's not a full specification, and it
>> may well not solve all problems that may happen when installing a
>> broken or malicious .deb. I'd like for us to solve at least the more
>> glaring problems, rather than throw our hands up and say it's to
>> difficult a problem. I'd like to be safe from my own mistakes, and if
>> that means our users are more safe and secure as well, that's a good
>> thing.
>>
>> --
>> I want to build worthwhile things that might last. --joeyh
>>
>

Re: Limiting the power of packages

[Carl-Valentin Schmitt]

in /usr only ?...

I thought therefore in later years Linux had created /opt ?



Lars Wirzenius  schrieb am Mi., 3. Okt. 2018, 19:19:

> The problem: when a .deb package is installed, upgraded, or removed,
> the maintainer scripts are run as root and can thus do anything.
>
> Sometimes what they do is an unwelcome surprise to the user. For
> example, the Microsoft Skype .deb and the Google Chrome .deb add to
> the APT sources lists and APT accepted signing keys. Some users do not
> realise this, and are unpleasantly surprise.
>
> (Note that I'm not saying Microsoft or Google are doing something
> nefarious here: they're trying to make sure security updates for their
> packages will be deployed to user's system; this seems like a worthy
> goal. But it's a surprise to some users.)
>
> I don't think it's good enough to say the user shouldn't install
> third-party packages. It's not even good enough to say the user should
> use flatpaks or snaps instead: not everything can be packaged that
> way. Debian's own packages can have equally unwelcome surprises.
>
> Imagine a package that accidentally removes /var, but only under
> specific conditions. You'd hope that Debian's testing during a release
> cycle would catch that, but there's not guarantee it will. (That's a
> safety issue more than a security issue.)
>
> A suggestion: we restrict where packages can install files and what
> maintainer scripts can do. The default should be as safe as we can
> make it, and packages that need to do things not allowed by the
> default should declare they that they intend to do that.
>
> This could be done, for example, by having each package labelled with
> an installation profile, which declares what the package intends to do
> upon installation, upgrade, or removal.
>
> * default: install files in /usr only
> * kernel: install files in /boot, trigger initramfs
> * core: can install files anywhere, trigger anything
> * maintained-by-liw: full power to do anything
>
> This might be implemented in various ways. For example, dpkg could
> create a temporary directory, and bind mount the directories the
> profile indicates are needed, into a temporary shadow of the full
> system. Maintainer scripts would be run in the shadow environment.
> Thus, if they try to do something that isn't allowed by the packages
> profile, they can't.
>
> The profile should be in the Packages file, and each apt signing key
> should specify which repository (i.e., Packages file) it applies to.
> There may be per-key restrictions for what profiles are allowed.
>
> This is a quick thought, while I was trodding in the dark, wet, cold
> evening to the grocery store. It's not a full specification, and it
> may well not solve all problems that may happen when installing a
> broken or malicious .deb. I'd like for us to solve at least the more
> glaring problems, rather than throw our hands up and say it's to
> difficult a problem. I'd like to be safe from my own mistakes, and if
> that means our users are more safe and secure as well, that's a good
> thing.
>
> --
> I want to build worthwhile things that might last. --joeyh
>

Re: Limiting the power of packages

[Mike Hommey]

On Wed, Oct 03, 2018 at 08:19:17PM +0300, Lars Wirzenius wrote:
> The problem: when a .deb package is installed, upgraded, or removed,
> the maintainer scripts are run as root and can thus do anything.
> 
> Sometimes what they do is an unwelcome surprise to the user. For
> example, the Microsoft Skype .deb and the Google Chrome .deb add to
> the APT sources lists and APT accepted signing keys. Some users do not
> realise this, and are unpleasantly surprise.

Note that packages can do that without a maintainer script.

Mike

Re: Limiting the power of packages

[Jonathan Dowland]

On Wed, Oct 03, 2018 at 08:19:17PM +0300, Lars Wirzenius wrote:

A suggestion: we restrict where packages can install files and what
maintainer scripts can do. The default should be as safe as we can
make it, and packages that need to do things not allowed by the
default should declare they that they intend to do that.


I think this is a great idea.


This could be done, for example, by having each package labelled with
an installation profile, which declares what the package intends to do
upon installation, upgrade, or removal.


And the user's local policy determines what happens? e.g. allow, deny,
prompt/log...


This might be implemented in various ways. For example, dpkg could
create a temporary directory, and bind mount the directories the
profile indicates are needed, into a temporary shadow of the full
system. Maintainer scripts would be run in the shadow environment.
Thus, if they try to do something that isn't allowed by the packages
profile, they can't.


This could more easily be achieved* (IMHO) using mount namespaces, and
more generally the collection of technologies (namespaces, seccomp
filters, etc.) that are collectively described as "containers".

I think an important step for figuring out what to contain would be
to audit all existing {pre,post}inst scripts and categorize them by
what they do (areas of the filesystem they read or write to; network
access; device access; etc.)

* on Linux, at least. Not sure about KFreeBSD.

--

⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Jonathan Dowland
⢿⡄⠘⠷⠚⠋⠀ https://jmtd.net
⠈⠳⣄ Please do not CC me, I am subscribed to the list.

Limiting the power of packages

[Lars Wirzenius]

The problem: when a .deb package is installed, upgraded, or removed,
the maintainer scripts are run as root and can thus do anything.

Sometimes what they do is an unwelcome surprise to the user. For
example, the Microsoft Skype .deb and the Google Chrome .deb add to
the APT sources lists and APT accepted signing keys. Some users do not
realise this, and are unpleasantly surprise.

(Note that I'm not saying Microsoft or Google are doing something
nefarious here: they're trying to make sure security updates for their
packages will be deployed to user's system; this seems like a worthy
goal. But it's a surprise to some users.)

I don't think it's good enough to say the user shouldn't install
third-party packages. It's not even good enough to say the user should
use flatpaks or snaps instead: not everything can be packaged that
way. Debian's own packages can have equally unwelcome surprises.

Imagine a package that accidentally removes /var, but only under
specific conditions. You'd hope that Debian's testing during a release
cycle would catch that, but there's not guarantee it will. (That's a
safety issue more than a security issue.)

A suggestion: we restrict where packages can install files and what
maintainer scripts can do. The default should be as safe as we can
make it, and packages that need to do things not allowed by the
default should declare they that they intend to do that.

This could be done, for example, by having each package labelled with
an installation profile, which declares what the package intends to do
upon installation, upgrade, or removal.

* default: install files in /usr only
* kernel: install files in /boot, trigger initramfs
* core: can install files anywhere, trigger anything
* maintained-by-liw: full power to do anything

This might be implemented in various ways. For example, dpkg could
create a temporary directory, and bind mount the directories the
profile indicates are needed, into a temporary shadow of the full
system. Maintainer scripts would be run in the shadow environment.
Thus, if they try to do something that isn't allowed by the packages
profile, they can't.

The profile should be in the Packages file, and each apt signing key
should specify which repository (i.e., Packages file) it applies to.
There may be per-key restrictions for what profiles are allowed.

This is a quick thought, while I was trodding in the dark, wet, cold
evening to the grocery store. It's not a full specification, and it
may well not solve all problems that may happen when installing a
broken or malicious .deb. I'd like for us to solve at least the more
glaring problems, rather than throw our hands up and say it's to
difficult a problem. I'd like to be safe from my own mistakes, and if
that means our users are more safe and secure as well, that's a good
thing.

-- 
I want to build worthwhile things that might last. --joeyh


signature.asc
Description: PGP signature