Re: [lmi] Where in /etc are customizations preserved?

[Vadim Zeitlin]

On Tue, 18 Aug 2020 21:36:14 +0000 Greg Chicares <gchicares@sbcglobal.net> 
wrote:

GC> On 2020-08-17 21:35, Vadim Zeitlin wrote:
[...]
GC> > and that these files must have been
GC> > explicitly removed by the system administrator for some reason. Perhaps
GC> > they didn't really upgrade the system at all but just re-imaged it?
GC> 
GC> No, they left /srv and /opt untouched, as well as the directories
GC> in /etc/schroot that are created by schroot installation. Looking
GC> through root's command history, I see:
GC> 
GC> unalias -a; e1='161803399999999'; e2='314159265358979'; b='[[:blank:]]';
GC> 
GC> apparently because pi can be calculated in double precision but
GC> phi cannot, and
GC> 
GC> echo __QUALYS\\_EOC__7__;umask 077 && umask;echo __QUALYS\\_EOC__8__
GC> 
GC> which means they must be using this:
GC> 
GC> 
https://qualysguard.qualys.com/qwebhelp/fo_portal/module_pc/policies/special_data_point_status_codes.htm

 I see, thanks for the investigative work. I think I've heard about Qualys
before, but I definitely have no idea about how it works (and its web site
doesn't really help with its explanation that it "detects heterogeneous
threats with six sigma accuracy"). I guess to really understand what
happened we'd have to find and read its technical documentation, but I'm
not sure if it's really worth it (and I won't hide that this doesn't look
like an especially appealing thing to do).

GC> >  Again, I don't really know what happened, but I strongly suspect they've
GC> > just recreated all system directories. Have your other modifications, e.g.
GC> > lmi group creation, survived this update?
GC> 
GC> Interesting question. User 'nemo' is still in /etc/passwd,
GC> and 'lmi' is still in /etc/group, with the right members,
GC> so whatever was mangled was very specific.

 Could they have just deleted the files that are not supposed to exist in
a "secure" installation?

[speaking about etckeeper]
GC> > I guess? I also run "git push --mirror" to some remote repository on
GC> > the machines that I really care about, but in this case perhaps you
GC> > could just keep a mirror of it on the same machine, but in your home
GC> > directory, to at least be able to restore the files from it easily.
GC> 
GC> You do that manually?

 No, I use cron job/systemd timer to do it. Recent (probably quite old by
now) versions of etckeeper also have PUSH_REMOTE option in etckeeper.conf,
which you've already discovered, but I don't use it because I often amend
its automatically created commits to add some notes about the changes, and
I'm not sure how well does it work in this case (i.e. whether it
force-pushes or complains that it can't push if the already existing
commits at the configured remote are modified locally). It should work fine
for your use case, however, and is even simpler to configure than a timer,
so I'd definitely do this already, as you really don't lose anything by
doing it (just make sure your pushed-to directory has the permissions
making it inaccessible to anybody but root because it will contain copies
of /etc/passwd, /etc/shadow and all the rest).

GC> I haven't tried this yet, but it looks like it would do the same thing
GC> automatically, unless you've disabled daily autocommits:

 FWIW I do disable daily autocommits, and also automatic commits before
install -- I prefer to commit the changes manually with a meaningful commit
message. But you don't need to be such a history junkie as I am.

GC>   git remote add origin file:///home/greg/
GC>   sed -i /etc/etckeeper/etckeeper.conf 
-e's/PUSH_REMOTE=""/PUSH_REMOTE="origin"/'
GC> 
GC> or maybe add an /etc/etckeeper/commit.d/65_push_mirror script
GC> if you want to customize it.

 I haven't even looked at this before, but I now have the answer to my
question above: it doesn't force push, but it could if I added "--force" to
/etc/etckeeper/commit.d/99push. Thanks for letting me learn something new
today.

 And please let me know if you'd like me to learn more about Qualys or if
we can just settle on considering it as an unpredictable and unavoidable
natural disaster and concentrate on recovering from it.

 Thanks,
VZ

pgpqpZ79hgCg1.pgp
Description: PGP signature