Date: Mon, 22 Feb 2016 21:13:45 -0800
From: Isaac Dunham <ibid.ag@gmail.com>
To: Alba Pompeo <albapompeo@gmail.com>
Cc: alpine-devel@lists.alpinelinux.org
Subject: Re: [alpine-devel] What could be done to make Alpine distribution
 more secure
Message-ID: <20160223051344.GA4173@newbook>
References: <CAJDAfTCpbH1OxjJsQ95TcU4VSSDxzAeXKNDLZRJdetRGfmeNog@mail.gmail.com>
Precedence: list
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CAJDAfTCpbH1OxjJsQ95TcU4VSSDxzAeXKNDLZRJdetRGfmeNog@mail.gmail.com>
User-Agent: Mutt/1.5.24 (2015-08-30)

On Mon, Feb 22, 2016 at 10:16:13AM -0300, Alba Pompeo wrote:
> A few days ago Linux Mint's website was hacked and their ISOs were
> replaced with backdoored images.

The most obvious precaution for this is
-sign the images
-checksum the images (ideally, sha256/sha512 and md5)
-sign the checksums
-include checksums and signatures in the release announcements
-have a link to a separately administered archive containing the
 announcement; you want some place that would have to be compromised
 separately.
 (ie, if there's a gmane archive, link there)

> This is a great security concern and I think a good opportunity for
> Alpine Linux to rethink its distributions of ISOs and what could be
> improved.
> I'll start with the obvious HTTPS support. The download links on
> http://www.alpinelinux.org/downloads/ all point to a HTTP link.
> If you try to manually change it to HTTPS you get the message -
> wiki.alpinelinux.org uses an invalid security certificate.

HTTPS downloads will add to the CPU load, without preventing the typical
hacks.
It prevents MITM attacks when endpoint attacks are typical.
Checksums and signatures should be available over HTTPS, though.
(The security benefit proportional to the cost is greater.)

> What else can you think about that would make alpine distribution more secure?
> The most advanced security feature I've seen a few distributions doing
> is reproducible builds, but it appears to be very hard and maybe not a
> priority right now. But for the future maybe it could be an idea.

Reproducible builds are not as hard as you'd think (says someone who spent
a few years poking at Debian packages, which were almost fully reproducible
before anyone got into that).
The fundamental requirements are:
-there must be a fully deterministic set of packages installed, if the
 build can vary based on installed packages.
 Solution: use minimal autobuilders, like Debian and Alpine do

-the configuration should be overspecified, not underspecified
 Solution: write out the config options longhand, rather than relying
 on defaults. (We're partway there.)
 This is important for cross-compiling, anyhow.

-the build options (optimization, hardening, and linker flags) must be
 deterministic.
 Solution: specify them in the build scripts and in systemwide,
 distro-provided config files, like Debian and Alpine do.

-the build ID, if provided, should correspond to the source and options,
 rather than varying with the path in which it was compiled.
 This is just a few bytes that can vary.
 Solutions:
 (a) don't build with debug flags, since gcc encodes the path to the
 source in the debug information, making the object files have a variable
 checksum. (True of some packages, but far from all.)
 (b) between prepare and build, come up with a checksum based on the
 build options and the source code checksums.
   For example:
   BUILDID=`{ find -type f -o -type l -exec shasum '{}' +
   echo "$CC $CXX $CFLAGS $CXXFLAGS $CPPFLAGS $LDFLAGS } | sha512sum |cut -c -128`

-there should be no way to circumvent the rules for build environment
 Solution: use a build server instead of package uploads, like Alpine does.

In other words:
Other than the build-id, it should be possible to reproduce Alpine packages.
And if you set up an autobuilder per the standard directions, it should
be fully reproducible.


Now, as far as running from r/o media goes (another possibility that was
mentioned)
-this doesn't prevent hacks, but only prevents adding permanent backdoors.

-this does prevent security updates without physical presence

-a 'cheap' halfway measure would be bind-mounting every path that's only
rarely written to over itself, but readonly.
This doesn't prevent someone who has a root shell from writing,
but it does prevent someone from exploiting symlink attacks or other ways
of writing to arbitrary files without shell access.

Example:
ROPATHS="/usr /lib /bin /sbin /boot /etc /var/www/isos"
for DIR in $ROPATHS; do mount -o bind,ro $DIR $DIR; done
# ... do stuff ...
for DIR in $ROPATHS; do umount $DIR; done
apk update
apk upgrade
for DIR in $ROPATHS; do mount -o bind,ro $DIR $DIR; done

Note that a few scripts may need adjustment to work with RO /etc.

Thanks,
Isaac Dunham



---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---