I would like to install the Bitdefender GravityZone agent on a new machine which will run Fedora Kinoite.
The Bitdefender Agent comes as a ./installer file which is provided by Bitdefender through my webinterface at their website. As far as I understand, this will be installed onto the system but Kinoite is read-only and only allows layering through rpm-ostree with .rpm files. So I can’t just run the ./installer?
Is there a way to create a .rpm package out of that ./installer or what is the sane way of installing Bitdefender GravityZone on Fedora Kinoite?
Additionally the installed Bitdefender Agent needs to be able to update itself.
Alright, so I got a reply from Bitdefender support. There is a way to download an .rpm file. Yay!
They also told me that for this type of systems you need to ensure that all the files related to user and group management are writable during the installation process. The installer needs to create a bitdefender user, and this cannot be achieved if the needed files are immutable:
etc/passwd
/etc/shadow
/etc/group
/etc/gshadow/
I understand, that this is what the rpm-ostree if for?
So it should install just fine?
The remaining question is: Will the bitdefender agent also work without any issues if the system is read-only.
I just installed the Bitdefender GravityZone Agent on the latest Fedora 42 Kinoite via rpm-ostree using the provided .rpm package.
New services aren’t enabled by default after installing so I enabled them manually.
After a reboot the agent didn’t start properly because it reports an error about files in “/opt/bitdefender-security-tools/var/run/” failed to open: read-only file system
The bitdefender support team told me that several customers are already successfully deploying the agent on immutable systems. So I am waiting for their feedback on the issue.
Edit:
Well it seems like something didn’t work during the install process. Bitdefender is supposed to create a user but nothing new shows up inside /etc/passwd
So I guess rpm-ostree didn’t allow modyfing this.
This seems a bit odd since /etc and /opt aren’t read-only on Fedora Atomic systems. It will be interesting to see what feedback you get from the support team.
Well the support team asked me to create logs but those would be created on the read-only system which ofcourse won’t work :S
Additionally I noticed that rpm-ostree can be run without root/sudo.
It could happen that someone tries to install Bitdefender GravityZone without sudo and then ends up with it not working while not getting any error.
It breaks my head why rpm-ostree can be run without sudo anyway.
Why would I ever want a normal user without sudo to install something to the read-only file system. This basically terminates any security that the immutable system ever tried to create in the first place lol.
I can see the argument for requiring sudo. But the current implementation doesn’t allow any normal user to run rpm-ostree, only “admins with local access”. (I assume that means members of the ‘wheel’ group but don’t know for sure.)
It tries to save logs to /opt/bitdefender/var/logs/
Ye well the standard user is most likely in wheel. So basically any malicious script that in some way gets executed could trigger rpm-ostree to install something onto the system. Crazy in my opinion. It is even worse than Windows UAC because even that one has stricter default rule sets.
If the user is not in the wheel group, an rpm-ostree install command will ask for a wheel user’s password, and so are other rpm-ostree commands that would change the structure of the system (e.g. rpm-ostree uninstall).
A user in the wheel group won’t be asked for a password for most of the commands, for the reasons mentioned above, however, more advanced commands, such as rpm-ostree override remove will still ask for a password, even in case of a wheel user.
rpm-ostree upgrade falls in neither of these categories, as it can be considered an automated process.
So I don’t understand all the detail of these issues. But it seems that, although /opt is writeable during normal operation of the system, if a package tries to write to subdirectories of /opt during “installation” with rpm-ostree, those end up becoming symlinks to somewhere inside /usr, which of course is read-only.
That becomes a problem for a package that wants to write runtime data somewhere inside /opt, which is what seems to be happening with Bitdefender.
So far I was under the impression that on other Linux distros a user in the wheel group is basically a standard user but with the privileges to run something as root via sudo by entering the password.
From how you describe it the user in wheel group on Kinoit can basically run root-like commands (rpm-ostree) without the need of a password.
One would need to be a user without wheel to escalate privileges to rpm-ostree like a wheel user would do with sudo.
Why not make rpm-ostree behave like sudo does?
But maybe this is also too off topic for this topic :S sorry in that case!
I guess this is a usability vs security mitigation approach. It’s also consistent with the way flatpak install command works.
As mentioned, for more advanced rpm-ostree commands, even the wheel user will be asked for password, probably based on some polkit rules.
We’re so accustomed with the traditional way of doing things, that any deviation from the norm seems “wrong” at first. But yes, this might be a bit off-topic, so please feel free to open a new topic if you want to start a discussion on the subject.
