Developer Zach Posted April 27, 2016 Author Developer Share Posted April 27, 2016 Only took 3 years to add a SecurityManager.... If you trace its history, the commit for it was made in June 2014. Since that point in time, it's stayed disabled by requests from multiple scripters. So technically it only took 2 years overcome that consensus and finally enable something that's been around, simply disabled. We have an fairly relaxed culture and we wanted to keep it around, hence the hesitancy around it. There would have been no need for manual code review when users committed changes to their SDN repos. I'm sure if people understood the pros/cons years ago there would have been a big push to implement it. If you think that it'll get rid of manual code reviews, you need to re-assess how you think security. It won't replace manual code reviews. Unless you have a poorly configured SecurityManager or the end user is using a modified version of OSBot I really don't see even "top notch" scripters being able to come up with any sort of bypass lol. Your thinking is way too closed minded. The key to security is looking at every angle. You're just not thinking about everything and I'm certainly not going to hand ideas out for people to use. A SecurityManager alone won't be getting rid of manual reviews, that's for sure. Edit: Since it wasn't clear, please note that I mentioned "security systems" in the original post, not specifically a SecurityManager. So for clarity purposes, yes, manual code reviews could be decreased as part of the broader security system, but it is unlikely that they will be completely gone. A SecurityManager alone won't cut it. Link to comment
DragonAlpha Posted April 27, 2016 Share Posted April 27, 2016 (edited) Unless you have a poorly configured SecurityManager or the end user is using a modified version of OSBot I really don't see even "top notch" scripters being able to come up with any sort of bypass lol. The security manager is extremely tight. I am one of the reasons it has not been fully enacted yet. They have been trying to avoid going the way of the other bots. OSBot is like an android mobile free and open, the other bots are like a locked-down iPhone which you must jailbreak to use freely. Sadly these dumbed-down scripters that can't make money from releaseing quality premium scripts (due to having a low IQ) must resort to hacking others. I honestly believe it was one person doing this, and they clearly must have had some programming knowledge. There are some work-arounds atm that require a lot of programming knowledge, but Zach has described the security manager and that the code is ready to instantly block these if the maliscious code releasers do it. I had a well known scripter talking to me on Skype a few weeks ago asking me how to use ClassLoaders, it may have been a coincidence that recently we've been seeing the malicious scripts use ClassLoaders to remotely load maliscious files, but it's clear to me the people or person releasing these has very little knowledge and does this bare minimum needed to hack people, so we can be safe in the knowledge they can't do much. It is disappointing to see the restrictions, but positive at the same time. The issue is scripters creating fake-alt accounts and posting malicious scripts, if we restricted Local Scripts to scripter rank only (and require x months on the forums) this would be a nicer solution to locking everything down, but it's become unavoidable now. SDN could be automated, you may have noticed my Dragon-Script-Loader, which is kind of like my own SDN. I just don't like the waiting times of the official SDN so made my own for the testing phase, and for Experimental releases. These low-IQ scripters are ruining it for everyone else. But unless the SDN approval system is rock-solid it's unlikely to be automated for now. Although I wish it was NOTE: there are always going to be bypasses, always. The bypasses become increasing more complex the more that Security Manager tightens down. Edited April 27, 2016 by DragonAlpha Link to comment
Final Posted April 27, 2016 Share Posted April 27, 2016 The accessibility was unreasonable anyway, by no means should a script have so much control as they have had in the past. I believe an automated SDN for already approved scripts would be very helpful, we could weed out malicious code for those updates and keep awful scripts out by having a manual review process as we already do. It's a step in the right direction regardless. Link to comment
Fratem Posted April 27, 2016 Share Posted April 27, 2016 Thanks for the updated security! Great work of you guys as always ^_^ Link to comment
Solution Posted April 28, 2016 Share Posted April 28, 2016 If you need additional permissions for something, let us know in the Client Bugs and Suggestions section. Scripters can post in the Client Bugs and Suggestions section or the thread in the Scripters' section. Does this mean exceptions can be made for specific users, or that exceptions will be made to the system in general? Nice addition nonetheless, and sad to see such action was required. Link to comment
Dark Magician Posted April 28, 2016 Share Posted April 28, 2016 I think this is a very good way forward. Link to comment
Yellows Posted April 28, 2016 Share Posted April 28, 2016 Seems like a good-way forward to help protect users. Link to comment