Kendall Sears - 08 February 2013 05:39 PM
You’ve made a lot of assumptions that aren’t correct. CMS (aka valentinadb) does not access “content” only its database file. Studio uses the path returned by the CMS to access the files. Also, EVERY modern SQL database uses TCP ports for communications, it is how it goes. Blame Apple for botching Darwin’s configs to make OSX more “Windows Like” for the DB running as a privileged user. MANY MANY MANY OSX “services” are in that same boat.
Protecting the port(s) from access is part of setting up any Unix system. A simple tcp-wrappers entry will suffice to stop unwanted connections to the ports. Any “security minded” person would know enough to have at least tcp-wrappers set for installed software. Something as heavy as a sandbox is unnecessary in this context. That thinking is for Windows, not Posix.
It would behoove you to research what you are working with a bit more before making blanket statements.
Kendall
My assumptions attempted to give DAZ CMS the benefit of the doubt, that it has good reason to run as root, and that it doesn’t have defects that may make machines vulnerable to denial-of-service or worse due to it opening a port to the world. The part about being able to telnet to the server from another machine on the LAN, or check lsof -i available service entries, that can be independently verified. It is unlikely, but not impossible, that my machine is misconfigured. I did do a fresh install of DAZ Studio 4.5.1 after running an uninstall of the CMS this afternoon, just to be certain.
Not all modern database systems require TCP ports open to the world. MySQL can, and often is, set up to only allow connections from localhost, rather than everything. In other words, it binds the loopback (127.0.0.1) adapter only so that only clients co-hosted on the machine can connect. SQLite doesn’t require a daemon at all and is sufficient for many purposes, including multiple process simultaneous access on a single machine. Localhost-only binding is probably appropriate for the DAZ CMS since it’s dealing with files and applications that are, well, local.
I don’t have source code access to DAZStudio, nor do I fully know (nor is it really my business to know) the requirements that were considered that made ValentinaDB a good choice over SQLite or MariaDB or MySQL or PostGRES. It may have superior development tools, or object features that make it very useful for managing the metadata. I would still like to think that the one-line change required to make the service bind localhost instead of everything would be an improvement, and arguably a bugfix to the software, that would not impact function at all.
There is also the express possibility that DAZ CMS spawns itself into a chroot jail or sandbox where it can only access the database files it needs to - I would be interested to hear if it does. Possibly I can test it. Still, that is only a partial defense from black hats.
Setting the wayback machine a few years, tcp-wrappers was a shim which allowed inetd to launch unprotected service tasks with filtering protections from outside attack. Using specialized launchd entries on OS X could be done to only launch the database on-demand or even on-login if you really wanted to go there, but DAZ has opted toward always-on service mode (/Library/LaunchDaemons/com.daz3d.content_management_service.plist) and I doubt that they’ve linked the daemon with libwrap.
It may also be an assumption (but a pretty good one) that end-users will install the software as instructed by the installer software. That installation sequence requests administrator privilege from the user in order to install DAZ CMS, and conveys that privilege to the CMS launchd configuration (again, the plist file, “Username” = “root”), circumventing firewall and code-signing security features of the OS. It’s true that OS X’s firewall defaults are “all or nothing” and lack finesse - you either block tasks from external networking (which would currently make the CMS database useless) or fully allow it. Most users will not take the time to research the necessary pfctl firewall tuning rituals required to lock out outside-world access to port 27997. By the way, you basically have to add “block quick on { en0, en1 } proto tcp from any to port 27997” to /etc/pf.conf and then pfctl -Rf /etc/pf.conf - on a machine with ethernet and wifi and firewall enabled, at least. And it differs between 10.7-and-newer versus 10.6-and-older. Not really the Mac way of doing things, it’s got that Linux smell. (Not to say I don’t like Linux - I do tons of it for my dayjob.)
Yes, Apple binds a bunch of services like the MDNS responder, netbios services, network printing, etc, to listen globally. It’s necessary to their function. Dropbox opens a port; again, necessary to its function - and turning off LAN sync at least opts you out of the TCP *:17500 open port. It boils down to this: I do not believe having an open port to the outside is necessary to DAZ CMS’ function - and it should be easy to fix! And yes, I did submit tickets in 2011 on the topic, and they have been acknowledged, and I still await further action on them. Which means I may be very patient and hoped they’d get to it sooner or later, or that I’m very busy, or that I was satisfied with the workarounds, albeit disappointed in what would have otherwise been a reasonable solution to a real problem of data management.
Anyway:
If there is no need for administrator access, best practices are to run it as an unprivileged user with access to only its database files.
If there is no need for outside-the-machine client support, best practices are to bind localhost:27997 instead of *:27997, or a unix-domain socket.
Those best practices date back to the days of tcp_wrappers, even.
I’ll try to keep this cordial and informative and stop here. Have a great weekend!
