6.6. Kiểm tra Tính xác thực Gói

Vấn đề an ninh rất quan trọng đối với các quản trị viên của Falcot Corp. Theo đó, họ cần đảm bảo rằng họ chỉ cài đặt các gói được bảo đảm đến từ Debian mà không bị giả mạo trên đường đi. Một máy tính cracker có thể cố gắng thêm mã nguy hiểm vào một gói hợp pháp khác. Một gói như vậy, nếu được cài đặt, có thể làm bất cứ điều gì mà nó được thiết kế để làm, bao gồm cả việc tiết lộ mật khẩu hoặc thông tin bí mật. Để phá vỡ nguy cơ này, Debian cung cấp một con dấu chứng minh giả mạo để đảm bảo - khi cài đặt - một gói thực sự đến từ người quản lý chính thức và không bị một bên thứ ba sửa đổi.

The seal works with a chain of cryptographic hashes and a signature and is explained in detail in apt-secure(8). Starting with Debian 10 Buster the signed file is the InRelease file, provided by the Debian mirrors. There is also a legacy file called Release. Both contain a list of the Packages files (including their compressed forms, Packages.gz and Packages.xz, and the incremental versions), along with their SHA256 hashes, which ensures that the files haven't been tampered with. These Packages files contain a list of the Debian packages available on the mirror, along with their hashes, which ensures in turn that the contents of the packages themselves haven't been altered either. The difference between InRelease and Release is that the former is cryptographically signed in-line, whereas the latter provides a detached signature in the form of the file Release.gpg.

APT needs a set of trusted GnuPG public keys to verify signatures in the InRelease and Release.gpg files available on the mirrors. It gets them from files in /etc/apt/trusted.gpg.d/ and from the /etc/apt/trusted.gpg keyring (managed by the apt-key command). The official Debian keys are provided and kept up-to-date by the debian-archive-keyring package which puts them in /etc/apt/trusted.gpg.d/:

# ls /etc/apt/trusted.gpg.d/
debian-archive-bullseye-automatic.gpg
debian-archive-bullseye-security-automatic.gpg
debian-archive-bullseye-stable.gpg
debian-archive-buster-automatic.gpg
debian-archive-buster-security-automatic.gpg
debian-archive-buster-stable.gpg
debian-archive-stretch-automatic.gpg
debian-archive-stretch-security-automatic.gpg
debian-archive-stretch-stable.gpg

TRONG THỰC HÀNH Thêm khoá tin cậy

Khi mã nguồn gói của bên thứ ba được thêm vào tệp tin sources.list, APT cần được tin cậy để tin tưởng vào khoá xác thực GPG tương ứng (nếu không sẽ tiếp tục nhắc nhở rằng nó không thể đảm bảo tính xác thực của các gói đến từ kho đó) . Bước đầu tiên là cần có để có được khoá công khai. Thông thường thì khoá sẽ được cung cấp dưới dạng một tệp văn bản nhỏ, chúng ta sẽ gọi là key.asc trong các ví dụ sau.

To add the key to APT's trusted keyring, the administrator can just put it in a *.gpg file in /etc/apt/trusted.gpg.d/ (*.asc files are discouraged and can cause problems). This is supported since Debian Stretch. With older releases, you had to run apt-key add < key.asc, which is considered obsolete already.

While this is very common behavior, it also creates a possible issue. APT does not know which key belongs to which repository. If one of the keys in APT's keyring matches the signature of an archive, APT considers the archive as authenticated. Once a key has been added to the trusted keyring, a malicious attacker could actually provide its own "version" of a Debian mirror signed by the same key. It might therefor actually be better to put the key as *.gpg file into /usr/share/keyrings/ and use the Signed-By field in sources.list for third party repositories as shown in the example below.

Imagine, that the Falcot Corp. runs their own public repository and you want to use it. They have signed it and provide a publicly available key(ring) as well to download. To restrict the key to the repository, you can simply do this:

$ sudo wget -O falcot-keyring.gpg -P /usr/share/keyrings https://packages.falcot.com/debian/repository.gpg

deb [ signed-by=/usr/share/keyrings/falcot-keyring.gpg ] https://packages.falcot.com/debian bullseye main

Beware that adding and using third party repositories always poses a security and stability risk!

Once the appropriate keys are in the keyring, APT will check the signatures before any risky operation, so that frontends will display a warning if asked to install a package whose authenticity can't be ascertained.

Note, that binary packages are usually not signed. The integrity of a package can only be confirmed by checking its hashsums against a trusted (and possibly signed) hashsum source.

SPECIFIC CASE Unsigned repositories

While in general unsigned repositories shouldn't be used, some users might still require them, for example to provide some locally built packages. APT can be forced to accept such a repository by prepending the repository URL using allow-insecure=yes or trusted=yes. We will demonstrate it using the example from Phần 15.3, “Creating a Package Repository for APT”:

deb [ trusted=yes ] http://packages.falcot.com/ updates/
deb [ trusted=yes ] http://packages.falcot.com/ internal/