[packaging] Useing distro package managers. Was: Re: Meeting next week to discuss trusted third-party repositories

Dan Kegel dank at kegel.com
Sun Dec 21 07:44:51 PST 2008


On Sun, Dec 21, 2008 at 7:08 AM, Tom spot Callaway <tcallawa at redhat.com> wrote:
> On Sun, 2008-12-21 at 14:18 +0000, Tortanick wrote:
>> 1) Non root install, because ROOT is EVIL ;) basically I will be
>> useing this package manager to install programs I know I don't trust,
>> games with DRM to me not giving them root permissions is important.
>
> A) Non root installs... where do they go?

Into /opt/$vendor, and all files should be owned by a pseudouser $vendor
rather than by the user doing the install.

> B) What of the security implications? Surely, you want the non-root
> installed bits in the various paths (libraries found by ldconfig,
> binaries in the executable path), but if any non-root user (legit or
> not) can put files in locations where all users automatically find them,
> that's a security problem. It's probably possible to minimize risk here
> by forcing such files to come at the end of the various "paths", well
> after distribution installed files.

I'd prefer to minimize it even further.
For binaries: your suggestion of putting
them at the end of PATH is good, but doesn't help with conflicts
between vendors.   We could have the package manager look at
/opt/$vendor/bin, choose binaries that obey a set of naming rules,
and put symlinks to them in /opt/bin.  The naming rules would probably
be something like "binary's name must be registered in LANANA,
or must start with the vendor's name and a dash" (following the existing
LSB naming rules that aren't widely known or followed yet).
For libraries: I'd like to disallow packages from /opt going into
ldconfig, and only allow them to be used as plugins to
applications such as firefox, chrome, and apache which look for
plugins in a specific directory and don't need them registered with ldconfig.

> Assuming all system users get access to this, you'd have to have a
> baseline level of trust on the non-root installed bits, since the
> distribution packaging system now uses bits put in by non-root users to
> resolve future dependencies. If an non-root app puts in a copy of
> libfoo.so.3 (heavily modified, but not renamed or soname altered), and
> the packaging system checks that dependency off as met, there is a good
> chance of unexpected failure.

Yes, we have to prevent that.

> Namespacing the added dependencies (either
> in the distribution packaging db or the library naming itself) would
> work around this, but it defeats a key value proposition from the
> distribution: security. When the distribution provides libfoo.so.3, it
> is able to patch it and keep it reasonably secure, and know that all
> applications which use it are covered. When non-root apps start putting
> additional copies of libfoo.so.3 on the system (modified or not), there
> are now security vulnerabilities that could be fixed. That leads into
> the bigger question of tracking updates and cross repository pain.

We can't prevent ISVs from bunding libfoo for their internal use,
but we can prevent them from referencing any other vendor's copy.

>> 3) Restrictive postinstall scripts: current postinstall scripts can
>> do anything, for unstrusted packages I'd like a far more limited
>> script with a short list of permitted commands.
>> I think that all you'd need is a command
>> that makes a symlink in /opt/bin and one for xdg-desktop-menu,
>> desktop-icon, mine and icon resource. Prefrably xdg-utils will keep
>> as much as possible inside /opt, for examlpe .desktop files go
>> somewhere like /opt/menu
>
> Again, there are security concerns here, unless the distribution owns
> those symlinks/files in /opt (which seems to be counter to the point
> of /opt, but that's semantics).

I think the distro should own them, in the sense that it is the final
arbiter of whether the app is allowed to put them there, and won't
allow it if they pose a potential conflict.

>> 4) a trust network, when you install a third party package the package
>> manager should read a list of trust servers the user trusts, ...
>
> It is worth noting that this assumes constant networking availability.
> GPG keysigning should probably suffice for this. Trust the key, trust
> the package.

The only constant networking needed would be for revocation, I think.
We can go with the same signing currently used for packages and repos;
the distro simply lists the signing keys it 'trusts'.

>> 5) limit dependencies to the LSB.
>
> I suspect this will lead to increased duplicate shared library
> proliferation, rather than increased adoption of the distribution
> provided libraries. (Alternately: It will encourage static library use.)

As the LSB becomes more complete, ISVs will need to bundle fewer libs.
Until then, we probably want to whitelist some system libraries
that are needed by lots of apps, seem to be ABI-compatible across
the most popular distros, and are likely to make it into the
next version of the LSB.
- Dan


More information about the packaging mailing list