[clug] How you know your Free or Open Source Software Project is doomed to FAIL

[Paul Harvey]

On 30 July 2015 at 20:30, Scott Ferguson <scott.ferguson.clug at gmail.com> wrote:

[snipped insightful and useful things]

> The rules I use, which shouldn't be confused with a formally proven
> correct approach, is:-

That's a very wise list. I can't say I've always got the priorities
and balance right... perhaps one day.

>> core/standard packages. And even then... So I've always liked the idea
>> of application whitelisting, it's just a shame there's no open source
>> kernel modules for Linux to do it (one day, I'll find the time).
>
> SELinux and AppArmor will do that. To which people often come up with
> the most convoluted excuses on why they'll just sprinkle holy water on
> the computer :D (Ohnose! SELinux is NSA - Russell Coker is the anti-christ)

This is one of those things about debian that could be better.
AppArmor profiles are usually quite absent or flimsy unless you
write/tune them yourself. SELinux is great, but they whitelist
behaviour - not code. In a way, this probably has more scope for
securing systems than application whitelisting by itself, but I think
is still orthogonal...

In an ideal world, app whitelisting would involve more code signing.
And simpler ways of specifying and reasoning about policy and what
should run (specific app-versions, specific apps, or perhaps just a
few trusted publishers - handy for devops who don't have sysadmins at
all!)

I think many infosec pros forget that an important aspect of security
must be usability. Although it's great we have the opportunity to add
more rituals and dances and incantations to harden our systems, they
should strive to be secure by default. Complexity is the enemy of
security, and diverts energy onto admin busy-work instead of freeing
us to take care of what should be more important higher-level things,
like key management.

These thoughts are not an excuse for turning off SELinux/AppArmor or
running everything in a single subnet without a single firewall rule
in sight... just an observation that the status quo is far from good
enough: insecurity should be much harder to achieve than it is today,
and I think more code signing might be part of the answer :)

> Don't start me on why passwords are dumb when keys should be enforced -
> I get drowned in spit before I even point out that key management is no
> harder than password management - let alone the limitation of the login
> buffer and why fail2ban is aptly named (have you heard of proxies?)

Or IPv6! Your attacker merely has to attack you on your IPv6 address
and fail2ban, fails.. 2.. ban. And it shouldn't be so hard for a
daemon to run as a non-root user...

[snippage for brevity]
>> It
>> seems as if all the distro packaging ecosystems have nearly all the
>> signatures and shasums lying around already, but then there are those
>> that would argue that whitelisting *all* binaries contained in
>> packages signed by package maintainers wouldn't be enough hygiene
>> either.
>
> As a sole measure - I'd agree (FWIW). That's the limitations of sole
> measures. Transparent proxies, VMs, snapshots, filesystem hash sum
> checks are all good measures for limiting damage (did I mention
> segregation?).
> Which is also another way of forcing dangerously naive endeavours to be
> abandoned. :)   (telling people their baby is ugly is an
> under-appreciated job)

These are all sensible measures. But as you've alluded earlier, proper
architecture can make the easiest path the safest one. Or at least
mitigate badness. And so I suspect that if Linux had a sensible app
whitelisting solution, it'd be turned on sometimes, and in those cases
people would be forced to stop plonking arbitrary mystery code with
next to zero provenance or reproducibility, because if they start
signing things or blessing them into a fleet-wide whitelist they might
accidentally start doing some SDLC :-)

Not to mention that this kind of feature might be able to buy some
benefits (reward!) by perhaps creating an ability to report on what
software is *actually* running: hit counts against bits of a whitelist
might give some signals about which machines are running what stuff.

Sadly I haven't yet cracked scripting languages. Or things that invoke
interpreters with the script in an argument rather than a file, etc.
The whole exercise is pointless additional obfuscation unless all
those cases are plugged, so it's perhaps doomed - I haven't delved
into how the commercial solutions do it.

Thanks for the great insights!