![]() ![]() I just got unnecessarily bent out of shape about being denied something when running as root, on the base concept of what that account is supposed to represent. In the end, I understand what both of you are getting at, and I have some setup steps to re-consider on my end, but with the way this bug was closed, I was really hoping that there was a very specific "if you run the database setup as a privileged user, then it puts the database into an especially vulnerable state where malicious actors can ", when in the end, it sounds like you're basically talking about that concept as a theoretical best practice, not that the msfdb init does anything especially dangerous when run as root or is somehow processing untrusted input itself. Combined with my impression that most users end up executing msfconsole with sudo anyway because they want to bind listeners to 80/443, then the common setup is already effectively running as root, assuming they haven't taken the time to use setcap or authbind to work around default port restrictions. As-is, it's not as though 'postgres' or 'nobody' will have access to the msf ruby environment to be able to run the msfdb program in the first place, so it was looking like I would need to create a new user, set them up with rvm, install metasploit as that user, init the database as that user, and then delete that user just to use the convenience functions provided by msfdb init, which had started feeling not so convenient at that point. Indeed, in this situation, my automated process has already got postgresql installed and running as a low-privilege user, I'm just trying to init the database as root, as that's where the rest of my setup process happens. I appreciate you mentioning that it is possible to just comment out this check, as I think I can make a simple work-around for that with a lineinfile in ansible if I want to do it my way, but in the end, I may have to just acknowledge that if I'm going to write reports stating that people shouldn't be logged in as admin on their desktops, maybe I shouldn't be logged in as root on my servers I absolutely realize that postgresql drops privileges to the postgres user by default, which is part of why I was suggesting that if the script doesn't want root that maybe it could automatically drop privileges as well. On top of that, viewing database setup/configuration (not execution) as an administrative task, not being able to do that as root made no sense from where I was sitting. (Or can you please describe the threat more specifically so I can at least understand why this is such a bad I am of course familiar with the concept of least privilege, and perhaps I'm wrong in the end as I'm the one trying to throw caution to the wind for a simple setup process. The only user on my system is root, and IMO I shouldn't have to create a new user just to install metasploit because of a non-specific database threat, especially when that database is only listening on localhost. ![]() I'm currently automating the install of metasploit for repeatable builds of cloud C2 infrastructure through ansible. If you're going to make a statement about how running database setup as root is bad, why not make your script account for that and drop privileges during setup? Especially considering that metasploit is a tool where users are going to want to bind privileged ports in many situations, installing as root is probably one of the most common non-latest-kali use-cases.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |