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

Mathijs Kwik mathijs at bluescreen303.nl
Sun Jul 22 08:42:38 CEST 2012


Marc Weber <marco-oweber at gmx.de> writes:

> I just had a look at the user.name.openssh.authorizedKeys.keys
> option:
>
> - That you can choose adding a section /overriding everything is great
>
> problems:
>
> - it doesn't get run in the activation phase (?) - Thus you have to
>   restart sshd (which is non obvious without reading code)
>
>   How to fix? Add it to the activation phase & ensure its run after the
>   code creating the users ..
>
>   Thus which is the way to go? add postUserSetup script like options?
>
> - if you want to control that file entirely - should the script be run
>   by a cron-job every X hours - and should be there a way to report
>   violations?

As ssh checks for weird permissions/ownership of ~/.ssh most tricks I
used in the past (symlinking, own by root) lead to warnings/problems.
However, I found that chattr +i (which the nix store also uses) on .ssh
and .ssh/authorized_keys works well. Just make sure other files that a
user should be able to modify (config, known_hosts) are created first.
>
> I mean you don't want to ssh every 3 days to make sure that all
> authorized_keys files contain what you think they contain.
>
> That's only one use case. Checking ports, permissions on files (eg home
> directories) and much more should be checked regularly if you want feel
> save.
>
> Does this make sense?

Anything that just checks "regularly" doesn't make me feel safe.
What if I find something was wrong? Now I need to investigate what bad
effects could have been caused because of it!

If something should not be changed, it has to be made impossible to do
so. For root, this is nearly impossible, so root should always be used
very carefully. But there are enough possibilities to lock down normal
users.

>
> Has anybody else thought about how this should be implemented?

I think there a quite a few intrusion-detection applications that can
check for changes to certain files, check logs, monitor ports and more.

However, I don't think the problems you mentioned (permissions on
homedirs, content of important files) should be handled by checking
after the fact, but just be hardened up front.

I haven't really experimented yet, but as the nix store itself is pretty
good at making stuff unchangeable (and detecting it, through checksums),
I would like to use the nix store itself for defining mandatory
directories and file contents (as an overlay).
I know there are a lot of difficulties, as things in store are publicly
visible and cannot have files/dirs owned (uid/gid).
But most of that can be overcome by using (on-the-fly) fuse layers
- encfs for decryption of stuff that's encrypted into the store
- posixovl for ownership/mode
- aufs for merging the result with the real system

Of course, every one of these layers might give new problems, and
there might be a performance impact as well.
Another way is to just have a bunch of gpg'd tarballs in store and an
activation script (for the system, or through PAM on user login) that
sets things up.

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.

>
> I mean nobody wants to get hacked - but if you do - you should know
> about it. That's why I think about how to detect that case as well.
>
> It will be very hard (if not impossible) to make sure that nixos is
> total secure. I feel nobody can pay full penetration testing after each
> small update - which is why I think about finding alternatives.
>
> I'm aware that chowning large email directories could have impacts on
> performance which makes me think that what I'm looking for is not
> feasible?
>
> Marc Weber
> _______________________________________________
> nix-dev mailing list
> nix-dev at lists.science.uu.nl
> http://lists.science.uu.nl/mailman/listinfo/nix-dev


More information about the nix-dev mailing list