DirectAdmin <= 1.33.6 Symlink Permission Bypass

Hello,

1) I've had a thought which may work as a good all-round solution to solve everything.

If we run tar as "user:apache", instead of "user:user", that would satisfy the backup creation. It would also limit the security issue much less than it was before. I'd have an option to shut it off, but based on the current response, it will have to be on by default. Since the backup must see the apache files, the only 2 process IDs that can see them are apache, and root, hence that's currently the top solution in my mind. Having DA run through all files before each backup isn't a great option in my mind, but I don't mind coding it if it would offer a better solution (in a manner I'm not seeing).

Note, I'll leave the file-checker running at update time, and available to be run at anytime, since it's a good way to check the state of things.

2) Another option is to leave the current backup system as is, and have a pre-check to run through everything to chmod to 755 or 644 if it's apache 600, etc.. This issue with that is if a file is created after the check, and before the backup. This method would also increase the system load when backups are created due to the pre-checks.

3) or.. go to the old backup system with higher backup rights, and again have a pre-check but only for dangerous files. This one is riskier, but will have fewer errors. The risk is again the delay after the check, before the backup is created. Also, it doesn't rely on unix security, it would put all faith in the pre-check, which may not account for future/unforseen issues.

4) Probably something that's going to end up happening regardless, since everyone has a different opinion on this.. options for all of the above in the directadmin.conf. This allows for all levels of tastes to be satisfied, since each method has pros and cons. If this is the decided method (all of them), then the issue then falls down to what the default should be, as this is what 95% people would likely be using. Security vs Functionality.

Comments welcome.

John
 
I would like to vote for option 1, first lesson in programming KISS. This first option sounds like the most elegant, fastest, secure and most easy to implement.

Also great news for me and probably lot of others by the way, this extra change will save me hours/days of work, getting all the file creation masks right in all those different PHP scripts on our servers. Let alone having all our customers know to configure newly installed scripts in the future this way.

Another option I was pondering about was to keep an ignore list per user of all those directories with apache created files like cache/temp directories. But option 1 is way better since you still want to backup some of those files like php uploaded files in a CMS for example.

Now you're into the backup script, maybe a nice time to implement that encryption option we talked earlier about as well, pretty please :)
 
Last edited:
Hello,

After a lot of feedback, it seems like #3 is going to be the solution.

Having apache as the group creates the original issue again, just with a lower permission level. It would allow linking to other home directories, and even bypass the secure_access_group method, since apache is in the secure_access_group. So using #1 would require a pre-check anyway.

The other issue is that many clients seem to be using chmod 0 on install directories, so many errors get thrown. It was mentioned to me that backups need to back everything up, in it's current state, no matter how wrong the clients have it set. I'd have to agree with that to a good degree. Admin's just don't have time to fix those small details, as they are valid unix options. If I don't want a directory to be accessed, I too would set it to 0, but would also want it to be in the backup.

Anyway, everyone is going to have their own specific needs for this.

What I'm going to do is as follows:
1) create a pre-backup check, on by default, that scans for hard links. It can be shut off in the directadmin.conf.

2) create backups the old way, to prevent any errors, but again, I'll add an option to run the backups as user:apache, in case admin's want that extra margin of safety. Again, with the apache group method, a pre-check is still going to be required.

John
 
Hello,

I'm almost done coding it.

1.35.1 should be ready in a few hours (assuming all goes well, and testing works out)

John
 
Nope.

1.35.1 has been released.
This is the change:
http://www.directadmin.com/features.php?id=1061

Basically, by default, it uses the old way of creating backups, but has a check that runs first to ensure there are no hard links.

There are options to shut off the check (if you want) or to change the backup to use the user:apache method. (although, the apache method didn't seem to work the way we were hoping: it requires g+r on the files)

John
 
You must log in or register to reply here.
Back
Top