-
Notifications
You must be signed in to change notification settings - Fork 20
hardcoded mysql credentials in postinst #14
Comments
Hi petiepooo, Yes, this is something that needs to be done. Would you like to work on this? Thanks! |
Glad to see you're receptive to this. Is it on the roadmap already? I would like to get right on it, but am pretty busy at work right now. I probably should have been doing other things today other than researching this and writing up the issue... :) It shouldn't take too much tho, as it's fairly straight forward. And can be rolled out in phases. All I see in github is Elsa extras tho. I know I can pull sources from your ppa but how would I get changes to you; emailing patch files? That's so 1990s... I'll try to get something to you over the next few weekends. Do you know of utils or scripts that depend on MySQL root access other than those mentioned above? Also, I'm not sure how to test some scenarios without releasing to a test repo or cutting an ISO. I'm open to suggestions for that. |
I added this issue to the Roadmap a few minutes ago: I agree these should be trivial changes and shouldn't take too much time at all. My time is quite limited right now, so if you have any spare cycles to work on this, I'd very much appreciate it! securityonion-setup can be found here: securityonion-sostat can be found here: Other packages can be found here: Thanks! |
Avoiding work... :) I've got a few changes in and ready to submit pull requests. I've also found files in /var/www/squert/.scripts that appear to be part of the securityonion-squert package. There's also some in securityonion-nsmnow-admin-scripts and securityonion-sguil-db-purge that I can put together pull requests for. The securityonion-squert and securityonion-sguil-server packages don't seem to be in github, though. How do I get a pull request or patches to you for them? |
Email is fine. Thanks! |
Note: this issue also applies to securityonion-elsa, securityonion-sguil-server, securityonion-setup, and securityonion-sostat packages, but I do not know where to find the source for them. It may apply to other packages that I am not yet aware of (any that rely on accessing mysql using the root@localhost user).
It has always bugged me that the mysql root password must be left blank on securityonion servers. This means that any unprivileged user has complete access to all data stored in mysql. The installation procedure takes pains to set debian-installer's frontend to noninteractive in order to circumvent any prompts to configure a password while mysql is installed and setup. I can't help but feel there is a reason those prompts are there, and it could be a valuable defense in depth if a sensor were compromised.
Fortunately, the Debian mysql package maintainers have created a full-privileged mysql user just reconfiguring mysql, used mainly for setting or resetting the mysql root password. Its credentials are found in the root-only-accessible file at /etc/mysql/debian.cnf. Since sostat and sosetup must be run as root, and since debinst runs as root while installing securityonion-{elsa,elsa-extras,sguil-server,...}, I'm not aware of any cases where a non-root user would need direct access to mysql's root user. I would love to see securityonion use the debian-sys-maint credentials in those scripts instead. For example, the mysql server postinst script uses the command
to pull the password out of that config file. Those credentials could be extracted and used in the elsa, elsa-extras, and sguil-server postinst scripts to create the appropriate users and DB schema, and also in sosetup, sostat, and sostat-quick (as well as any others I'm not yet aware of) rather than relying on the root user having a blank password.
Implementing this would allow securityonion-all (or server or sensor) to be installed on an Ubuntu system that already has mysql installed with a root password set. Or a user could set mysql's root password during or after install (a recommended server hardening practice) and not break the sosetup/sostat* scripts.
The text was updated successfully, but these errors were encountered: