Bug#990381: sources.list(5): clarify whether file URI schema is secure or not

[Christoph Anton Mitterer]

Package: apt
Version: 2.2.4
Severity: wishlist


Hey.

It would be nice if the sources.list(5) manpage could clarify whether
file URI schema is secure (or not) when the archive is not under local
control by a trusted user.

copy
The copy scheme is identical to the file scheme except that packages
are copied into the cache directory instead of used directly at their
location. This is useful for people using removable media to copy
files around with APT.

So my understanding is that with file:
- at some point the file is verified (apt-secure)
- then read from the specified location directly (not from a cached copy)
... and installed

But wouldn't that also mean, that if the (local) user controlling that
location ... or e.g. the NFS owner, could replace the valid file with a
rogue version, right after it has been read the first time (for validation)?


Or is there another validation of the hashes, right when it's read in for
the actual installation?

Cheers,
Chris.

[Christoph Anton Mitterer]

Few more further minor things in sources.list(5):

1) Check-Date, unlike all the other options, doesn't mention it's
default.



2) For:
• Valid-Until-Min (valid-until-min) and Valid-Until-Max
(valid-until-max) can be used to raise or lower the time period in
seconds in which the data from this repository is considered valid.

my understanding was the following:

The Release file has Date: and (possibly) Valid-Until: .
If I set Valid-Until-Max = 1 day, the regardless if what Valid-Until:
says in the release file, it would be valid at from the Release’s Date:
+ 1 day.

However, the description using the the terms raise/lower rather implies
that an existing value is raised/lowered, ... e.g. for the example
above, as if the Release file had a validity period of 1 week... it
would be 1 week + 1 day.

Similarly, the following is not clear, I guess:

If the Release file would say the validity period is effectively 1 day,
but Valid-Until-Max = 1 week,... which one wins? "-Max" kinda implies
it would be the maximum value, but a smaller Valid-Until would still be
enforced?


3) The EXAMPLES section seems to imply one can set multiple values in
Suites: (last example), but the "THE DEB AND DEB-SRC TYPES: GENERAL

Suites: suite
Components: [component1] [component2] [...]

Thanks,
Chris.

[Christoph Anton Mitterer]

One more (yes I know, it's not really belonging to the original bug
report, but it seems stupid to open another one just for this):


apt.conf(5) references:
/usr/share/doc/apt/examples/configure-index.gz

but this is apparently no longer a .gz


Cheers,
Chris.

[Julian Andres Klode]

Post by Christoph Anton Mitterer
Package: apt
Version: 2.2.4
Severity: wishlist
Hey.
It would be nice if the sources.list(5) manpage could clarify whether
file URI schema is secure (or not) when the archive is not under local
control by a trusted user.

copy
The copy scheme is identical to the file scheme except that packages
are copied into the cache directory instead of used directly at their
location. This is useful for people using removable media to copy
files around with APT.

- at some point the file is verified (apt-secure)
- then read from the specified location directly (not from a cached copy)
... and installed
But wouldn't that also mean, that if the (local) user controlling that
location ... or e.g. the NFS owner, could replace the valid file with a
rogue version, right after it has been read the first time (for validation)?
Or is there another validation of the hashes, right when it's read in for
the actual installation?

The file: method is not secure against third-party attacks. Neither
metadata like Packages files nor debs are copied anywhere; so they can
be replaced at any time and are not revalidated.

This has been the subject of much discussion the past weeks and I'm
leaning towards renaming it to `insecure-file` to make users explictly
(aware of, and) acknowledge the risks.

This means that file:/ URLs will create a warning saying that file
is insecure and to read a manual page and switch to copy or
insecure-file.

[Christoph Anton Mitterer]

Post by Julian Andres Klode
I'm
leaning towards renaming it to `insecure-file` to make users
explictly
(aware of, and) acknowledge the risks.

What about introducing an option instead, that controls whether or not
file is allowed, and which eventually defaults to disallow?


Or alternatively and perhaps even better:

An option that controls how file: works, default would be like copy:
... and an alternative mode would be like the current file: (i.e. no
copy), but that being documented as insecure on untrusted sources?

Probably that would then again need to be a per repo option, too.


The advantage with both would be not to encode a usage warning in the
schema name (like we don't use insecure-http://).

Th advantage of the 2nd would be that we could use the well recognised
file: schema.


Cheers,
Chris