Gentoo Archives: gentoo-dev

From: "Michał Górny" <mgorny@g.o>
To: gentoo-dev@l.g.o
Subject: Re: [gentoo-dev] [v1.0.1] GLEP 74: Full-tree verification using Manifest files
Date: Mon, 30 Oct 2017 16:11:33
Message-Id: 1509379878.1517.7.camel@gentoo.org
In Reply to: Re: [gentoo-dev] [v1.0.1] GLEP 74: Full-tree verification using Manifest files by "Robin H. Johnson"
1 W dniu nie, 29.10.2017 o godzinie 20∶39 +0000, użytkownik Robin H.
2 Johnson napisał:
3 > On Sun, Oct 29, 2017 at 08:07:56PM +0100, Michał Górny wrote:
4 > > File verification model
5 > > -----------------------
6 > > The verification model aims to provide full coverage against different
7 > > forms of attack. In particular, three different kinds of manipulation
8 > > are considered:
9 >
10 > s/three/four/
11 > > 1. Alteration of the file content.
12 > >
13 > > 2. Removal of a file.
14 > >
15 > > 3. Addition of a new file.
16 >
17 > Add:
18 > 4. Metadata replay attacks [C08].
19
20 This isn't covered by the file verification model but merely
21 by the timestamp field which is described in a separate section.
22
23 >
24 > > In order to prevent against all three, the system requires that all
25 > > files in the repository are listed in Manifests and verified against
26 > > them.
27 >
28 > s/three/four/.
29 >
30 > > Timestamp field
31 > > ---------------
32 >
33 > ...
34 > > A malicious third-party may use the principles of exclusion and replay
35 >
36 > Insert [C08] after 'replay'.
37
38 Done.
39
40 >
41 > > Strictly speaking, this is already provided by the various
42 > > ``metadata/timestamp.*`` files provided already by Gentoo which are also
43 > > covered by the Manifest. However, including the value in the Manifest
44 > > itself has a little cost and provides the ability to perform
45 > > the verification stand-alone.
46 >
47 > Implementation Note: with TIMESTAMP, some of the old timestamp files will be obsolete; they
48 > will already need special handling in Manifest generation, because they are
49 > added VERY late in distribution. Sadly not all of them, because of legacy
50 > dependencies (they will get IGNORE entries instead, as they are populated much
51 > later than manifest generation).
52
53 Tried to word it somewhat without getting too detailed.
54
55 >
56 > > References
57 > > ==========
58 >
59 > Additions:
60 >
61 > .. [#C08] Cappos, J et al. (2008). "Attacks on Package Managers"
62 > (https://www2.cs.arizona.edu/stork/packagemanagersecurity/attacks-on-package-managers.html)
63 >
64
65 --
66 Best regards,
67 Michał Górny