Marc Weber <[email protected]> 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 > [email protected] > http://lists.science.uu.nl/mailman/listinfo/nix-dev _______________________________________________ nix-dev mailing list [email protected] http://lists.science.uu.nl/mailman/listinfo/nix-dev
