Home_greyopenFATE - openSUSE feature tracking > #307745
Dashboard | Search | Sign up | Login

Please login or register to be able to edit or vote this feature.

Let the admin ("root") download and install untrusted third-party RPMs from known URLs guided via YaST

Feature state

openSUSE Distribution


I would like to have it evaluated whether or not it is allowed
to implement a dialog in YaST which lets the system admin
(i.e. "root") download and install untrusted third-party RPMs
from known URLs.

In any case "root" can download and install any software manually.
This request is about to provide a guided and restricted way
for some particular cases.

My current use-case are the printer driver packages
which are available via OpenPrinting at the Linux Foundation:
where LSB compliant driver RPM packages are available.

From my point of view those packages are on the one hand
untrusted third-party RPMs but on the other hand
their download location is "well known" which makes
those packages "well known third-party packages".

I assume that from a strict security point of view
any kind of third party software is "strictly forbidden"
but I like to propose a more useful way here:

The system admin (i.e. "root") can in any case
download and install whatever software he likes.
This may invalidate e.g. whatever support contract
but it is up to the admin to know what he does.

Currently we have no idea at all which third-party printer
drivers an admin may download and install on his own.

When he has a printer for which there is no driver
provided by us, the admin may download whatever
driver software from any totally unknown location
and install it with any unknown consequences.
(E.g. some time ago there was a printer driver from
a printer manufacturer where its installation script
set setuid root bits on various user application
programs to mak it "just work".)

Currently we even do not tell the admin about the
well known printer driver locations at OpenPrinting.

From my point of view it would be a big improvement
when I could implement a dialog in the YaST printer module
which shows a very explicite text that this is about
untrusted unsupported third-party software.
This text would require explicite confirmation by the admin.
Then it downloads RPMs only from hardcoded URLs
from OpenPrinting and inspects the downloaded RPM
whether it overwrites already installed files on the system
and if not, it installs it without running any RPM scripts
because normal printer drivers do not need to run
RPM scripts during installation.
If the above conditions are not fulfilled it shows a very
explicite warning text and does not install anything.

In contrast to now where we leave the admin totally
on its own how to get a driver for a printer for which
we do not provide a driver, the above described
guided and restricted way to download and install
drivers via YaST would help both the admin and us
because in many cases we could make sure this way
that we know at least which third-party driver
the admin has installed.

Please do not confuse this request
with the different request how a third-party
(e.g. OpenPrinting or a printer manufacturer)
could provide software packages in a way
which is in full compliance to our package
installation and management tools (i.e. via a
repository which provides also updates and so on).

This request is meant for third-party RPMs "as is"
where the vendor/provider simply does not want
(because of whatever reason which is beyond our control)
to provide his RPMs in compliance to our package
installation and management tools.


icons/user_comment.png J. M. wrote: (4 years ago)

FYI what other distributions currently do you may have a look at what Till Kamppeter wrote about a "Printer Driver Auto Download Service at OpenPrinting":


icons/user_comment.png J. M. wrote: (4 years ago)
icons/user_comment.png M. E. wrote: (4 years ago)

Openening a machine for software downloads (a PPD is also to be considered software) from arbitrary sources in arbitrary (file) formats is a security nightmare.

In my view, the Open BuildService provides openSUSE with an infrastructure, where the demand for quick availability is combined with the capabilities for peer review and availabililty in a (per distribution (RPM, DEB, ...)) standard format.

icons/user_comment.png J. M. wrote: (4 years ago)

For me it is perfectly o.k. when requests for such kind of functionality get officially rejected.

I only want to have it evaluated and an official decision as result.

icons/user_comment.png R. D. wrote: (4 years ago)

Understood, JJohannes.

Two components:

The current architecture does not make a significant difference between executables and other content. One could theoretically install a movie with an RPM package, but other than the permissions of the file there is no difference to an extremely bloated binary of some package. Besides the fact that you (usuallly) can't execute a movie, of course.

Our package management, due to 1), does not make a difference between packages from one source and another, between trusted sources and rather non-trusted ones. If a package has been installed, package repositories can be added by the package, or it can download all kinds of material by itself, thereby undermining the security architecture that may be in place elsewhere.

There are only few ways to mediate this conceptional weakness:

  • packages and repos CAN be subverted. This is a simple fact, and there is no point in denying or over-emphasizing it. A defeatist opinion ("You can't do anything about it, therefore, you should just take the risk and live with it, you are probably already subverted anyway....") is very counterproductive. As a consequence, a healty dose of mistrust to start with - at least not accepting and trusting everything by default - is needed. The decision to install material from unknown sources must default to no, and a YES-decision must be made.
  • The user/admin MUST make informed decisions about which repositories and packages to add to his system: whatever understanding of trust the user has, he should make use it. The system MUST NOT make those decisions on behalf of the user.
  • A chain is only as strong as its weakest link. It is in the interest of any software company that the system enables and encourages the admin to make educated decisions concerning system security, so that the admin does not make himself the weakest link of the security chain around him and his system.
For the purpose of downloading and installing printer drivers:

It should not be done at the same (securty-relevant) abstraction level as the installation of packages, for reasons outlined above. Also, non-root privileges are mandated. If drivers are downloaded, the download should be inpected for correctness (is it a driver that was extracted from foo.zip?), and it should only be done from identified sources (https connection to printer manufacturer's servers). The installation of the drivers should have a verbose log that is only accessible for root. If files are modified, state snapshots of those files must be made to be able to roll back. A catalog of the added and/or changed files should be made (accessible for root only), ideally with hashes of each file that document the state of the system.

Last change: 4 years ago
Score: 2
  • Negative: 4
  • Neutral: 2
  • Positive: 6
Feature Export
Application-xmlXML   Text-x-logPlaintext   PrinterPrint