Ubuntu packages can break the OS on update

[mario7-pl]

I'm using OSSEC on Ubuntu Server 18.04 - packages from https://updates.atomicorp.com repository.

I noticed that postinst script of deb packages causes issues when package is being updated.
https://github.com/ossec/ossec-hids/blob/master/contrib/debian-packages/ossec-hids/debian/postinst
The issues are:

1. postinst script changes permissions and ownership of some of libraries in /lib/x86_64-linux-gnu/
   I think this happens due to lines 41 and 42 in postinst script
   chmod -R 550 ${DIR}
chown -R root:${GROUP} ${DIR}
   for some reason files in /var/ossec/lib/x86_64-linux-gnu/ (there are libnss_* and libresolv libraries) seem to be hardlinks to files in /lib/x86_64-linux-gnu/ and this way postinst script affects original files.
   This leads to changed permissions and makes parts of the system not able to resolv hostnames or not able to access the libraries at all (chmod 550 and chown root:ossec). Symptoms of this issue is "I have no name!" instead of username in shell prompt and plenty of apps not working properly.
   After each OSSEC update I have to manually set proper chmod on affected so files to make system fully work again, like this:
   chmod o+rx /lib/x86_64-linux-gnu/libnss* /lib/x86_64-linux-gnu/libresolv-2.27.so
   I couldn't find what creates those hardlinks in /var/ossec/lib/ and why they are created at all. I'm not even sure it they are needed in the first place... Maybe they aren't and could be deleted?

2. postinst script cannot properly add ossec user
   Line 27 in the script looks like this:
   if ! getent passwd | grep -q "^ossec"
   so in fact it checks if there is anything starting form ossec (including other users like ossecr or ossecm which are created few lines below).
   It would be better to just let getent check if there is given user rather than grepping it manually (with broken regexp...).
   For me this didn't work - somehow ossec user was removed on update and it was not re-created because ossecr user was already existing.
   In the end update failed and it couldn't recover automatically until I modified the postinst script.

3. after failed update my local_rules.xml file was lost.
   Due to issue no. 2 above, update failed and when I completed it - my customized local_rules.xml file was replaced with empty template.
   Fortunately I have backups, so I could restore it easily, but really this shouldn't happen...

4. backup-rules.* dirs do not contain proper backups
   postinst script is supposed to create backup of rules (backup-rules.* directory) but local_rules.xml in every of backup directories is default template instead of actually modified file. So the backup does not contain backup...

It would be nice to see those issues fixed in the next release.

[atomicturtle]

Great report! Would you be available to help me test the fixes for this on our slack channel (invite: slack@ossec.net)? I'm not as familiar with ubuntu and I could use the help, thanks!

[mario7-pl]

Sure, I've just sent an e-mail.

[atomicturtle]

Added in build 12034

1. I also couldnt replicate this condition, so what I did was removed the overkill -R method used in the script for something more RPM-like, where we declare each directory and only perform the action against that path. This should eliminate this if by some chance some other action (definitely not package related!) does add lib to the /var/ossec/ dir.

2. getent is definitely not the right thing to use here. I duplicated the method we used in the RPM package with the id command.

3. Tagged local_rules.xml as a %config file, so this shouldnt be overwritten in any condition without user approval

4. Moved the backup rules condition to the %pre stage, it was happening in the %post stage before so basically it would make the backup AFTER it had been overwritten

Thanks again for the report!