[Nix-dev] security - observing changes - example authorizedKeys

Marc Weber marco-oweber at gmx.de
Sun Jul 22 15:45:30 CEST 2012


@ Eelco: sshd should be restarted: I'll check.

You make a false assumption: That the kernel operates the way it should
- thus that files which are "unreadable" stay unreadable.

Eg have a look at this case:
http://www.h-online.com/security/news/item/Root-exploit-for-Linux-kernel-published-742541.html [1]
And on our kernels no security audits are done - and no - I don't think
that regular penetration testing tools can test that (@Eelco) because it
may not be know today.

But why does btrfs devs work on online filesystem checks?

Maybe limiting the request to "security" concerns is not enough.
Se let me just list a view things which can go wrong I want to detect:

I might be using btrfs - and that in combination with my kernel (or
the kernel used by hosting providers) might be buggy.
So if something is different than I expect it to be - I want to know.
This includes:
* store paths of the booted/current system (maybe of all user
  environments, too)
* .ssh/authorized_keys (for security reasons)
* ports (for security reasons - every app listening to the outside
  world is suspicious)

cosmic ray could cause corruption (and if it happens you may want to
consider setting up a new system moving your data there).

> If something should not be changed, it has to be made impossible 
Well - I hope you agree on the usefulness of continuous integration and
automatic tests. However the search space is that huge that it would be
hard to write test cases for all kinds like [1].
In the end that would mean dropping C/C++ and using other languages.
And that's not feasible.

So if you'd tell developers "Don't write tests - make sure it doesn't go
wrong" I'd ask you twice about why you think thats enough. Basically I
agree - but I also feel uncertain about everything - because I code
myself - and humans sometimes fail (so do kernel devs - even though they
shouldn't).

Next sample: If you run PHP code which was written for 5.2 on 5.3 you
may git segfaults in some cases. segfaults can be used by attackers etc.

You just can't make sure that such never happens.

I agree that by monitoring some files I don't feel perfectly safe.
But at least I have a chance to detect all kind of changes and take
action.

And trusting the nix store hash sums (nix-store --verify
--check-contents) is not safe either - because the database could have
been compromised (then the attacker would know nixos very well).

Such kind of verification should happen always from the outside.
So yes - verifying that the checksums didn't change is another thing to
monitor.

> Like I said, I haven't started any of this, but I think it's a nice idea
> to have things activated/setup beyond /etc and to just have the full
> (mandatory) system in store.

Additional unexpected files in /etc are also suspicious and worth
knowing about.

Marc Weber


More information about the nix-dev mailing list