Thanks for posting on our forum! DirectAdmin has been programmed to run *very* securely. When we began programming DirectAdmin, we noticed many people posting in forums about security holes and bugs. We wanted to give them peace of mind when DirectAdmin was released.
DirectAdmin logs all suspicious activity, and you may check this log at any time. In addition, the panel itself is programmed to resist practically every exploit possible. Unless you give out your root password, you will be safe.
If you want to know, at the programming level, how we protect against hacks/abuse, please e-mail email@example.com and a technician will be able to answer your question much better than I can.
Right now we encourage any billing solutions companies to contact us to speed up the integration of DirectAdmin with billing software. More information will be available soon.
When it comes to security, we spared no expense in implementing as many security measures as possible. Firstly, and probably most importantly, buffer overruns are out the window. All variables are allocated memory based on the size of the data, no less, no more. Secondly, since we approached the way the commands are issued to DirectAdmin by saying, "these are the commands, you can't use anything else", it prevents people from trying to run things that they shouldn't be. This also ties into the security log; if someone is indeed trying to run a command out of their authority level (ie: create admin as a user), who, what, where when, from what ip, etc. will be logged. Another great security thing that is logged is the "login attempts". When someone attempts to log in, a file will store their ip and information about their attempt. Each additional attempt will be logged to that file, regardless of who they try to log in as. Once they try 10 times or more, each attempt will be placed into the secuirty log showing their ip, the number of attempts, and who they were trying to log in as. Any other out-of-the-normal thing you can really think of will be logged in the security log, or the error log if it applies.
One big one is the extensive form checking. This ensures that you don't try to pass any data that is invalid. Other control panels might not check for newlines, thus allowing someone to post data which will be written in a log giving them the ability to write whatever they which on the subsequent lines. All data passed to DirectAdmin will be thoroughly checked for validity.
If, after ALL of this (and far more smaller things that are not listed) an exploit is found, a bug fix can be made very quickly and updates will be sent to everyone, probably before they even know the bug exists, plugging the hole. Our automatic update feature makes manually updating things such as security holes and new features a thing of the past.
I'm probably forgetting some of the security features, but you can get the general idea that we made security a top priority.
As for the API you requested, we will get on that right away and should be done for you within a few days. We'll post a link under the support section when completed.
Suexec is enabled and the path required for suexec is "/home" such that users can only run cgi's from their accounts, in their cgi-bin directory. It can be manually disabled and a feature to disable suexec might be added to DirectAdmin in the future.
We don't currently chroot apache to anywhere, we just use a basic configuration (with frontpage), however, you are free to change apache and any other system services however you see fit.
When you mentioned chroot, it reminded me of the uid and gid of DirectAdmin. DirectAdmin is run as "nobody" most of the time. It's only seteuid to root when it absolutely needs it. Other than that, it runs as the "diradmin" user for user configuration files and the user's id for account modification. The filemanger does a full setuid (can't restore root) and chroot to the users /home/user directory, disabling them from doing any damange outside of that.
PHP scripts that allow browsing of other files on the system outside users home directory. Most panels lack this security and it is possible for customers to see each others data if they are looking hard enough for it.
SSH users being able to see more then they really need. If the file system is chrooted, they only get their own file system, their own set of commands, etc.
We currently don't have something like that in place, but I can promise you we will explore it after our FreeBSD release. It hasn't been something highly demanded by admins, but I do see your point. If we can integrate it, we will!
There have been one or two people asking about RH 9 / Apache 2+ support, but right now we don't offer it. The area of highest demand has been a FreeBSD version and that is our top priority at the moment.
I can say with moderate confidence that we will eventually release for RH 9, but it won't be in the immediate future.