This plugin includes a BeanShell interpreter and allows you to give it code to run through commands, either in chat as a player or in the console. The interpreter runs in and provides access to the same Java environment that the server runs in, making this a powerful debugging tool.
||| WARNING |||
Be extremely careful about who you trust with this plugin. It is dangerous and it can be used to inflict damage upon both the Minecraft server and the actual server computer. Do not run any BeanShell code that anyone or anything tells you to run, unless you know exactly what you are doing.
Features
Use /bshd <code> to run BeanShell code on the server. The interpreter is created when the plugin is initialized and it persists across command executions, allowing you to store variables in the BeanShell environment for later use. All code is run by the same interpreter.
Some variables in the BeanShell environment are predefined for convenience:
game is the Game that was injected into the Game field in the plugin’s main class.
server is the Server returned by a call to .getServer on the aforementioned Game.
me is the CommandSource passed to the command processing method when you ran the command (your EntityPlayerMP if you’re a player; the DedicatedServer if you’re using the console).
Every PluginContainer returned by a call to PluginManager’s .getPlugins() is checked: if it contains a non-null plugin, it is assigned to a variable whose name is the simple class name of the plugin.
The classes in these packages are imported for convenience:
It is not recommended to use this plugin on production servers, but it does have a concept of security:
SpongeBSHD does not rely on permissions or operator status. Giving a player all permissions should not mean giving the player complete control over the machine.
Players are only allowed to use /bshd if their UUID’s are found in the allowedPlayers.txt file in SpongeBSHD’s config folder. This file is read directly every time a player’s permission is tested, so changes take effect immediately.
SpongeBSHD will not initialize if the server is in offline mode. In offline mode, player UUID’s are based on usernames. Because players can control their usernames when logging into offline mode servers, they can also control their UUID’s and therefore potentially also the entire machine - so no SpongeBSHD in offline mode.
Planned Features
When PagedData is implemented and in-game books can be written and read, I will have options for running BeanShell code written in books and for having code results output to books.
If people think it would be useful, I may add a command to run BeanShell code from files, and maybe a folder to contain files to be automatically run after the plugin initializes.
All feedback is welcome.
Thanks to Pat Niemeyer for creating BeanShell, thanks to Ryan Michela for creating the original BeanShellDebugger for Bukkit, and thanks to everyone on IRC who kindly took time to answer my questions.
Yes, I had seen that, but it would be nice to have something that’s more secure and that uses a preexisting dynamic code execution library. Also I planned on the book i/o being a differentiating feature, but that part will have to wait until it’s possible.
How exactly is this more secure. You aren’t “blocking” any methods, and any filtering type thing would be horrible. As there will be tons of ways around it. Filtering never is a perfect cure.
Wanna know for example how beanshell can be exploited? Here’s a one liner:
exec("rm -rf /");
But let’s say java isn’t running as root so we can’t do that. Why not just create a fork bomb?:
exec(":(){ :|: & };:");
(This copies itself over, and over taking up all your memory).
Needless to say this provides no extra security by simply using a pre-existing framework.
#“More Secure”#
Oh hey look! Uses some random text file to identify players who can use the beanshell commands! Meaning if someone say uploaded a poison plugin they can just modify this great text file (which leaves no logs), as compared to checking a permission (which would leave a log somewhere that the user got a permission granted to them (in the master sponge log)).
As @The_Doctors_Life’s points out you should probably check permissions.
Needless to say this should have the same warning as ACE. It should not be deployed on a production server, and should have many warnings as such to not do so. As many admins who don’t realize (who shouldn’t probably be running a server (but that’s irrelevant)) could be put at risk.
tl;dr
Not more secure, please add warnings to not deploy on production.
SpongeBSHD is more secure than ACE because access to a permission management plugin could allow a player access to ACE but not to SpongeBSHD, and because it won’t work in offline mode.
And I never said I was. I’m not sure why you chose to put the word blocking in quotes.
Of course it can be exploited, but only by players whose UUID’s are in the file. SpongeBSHD is currently more secure than ACE not because BeanShell is somehow more secure than JICI, but because of how much harder it is for players to get access to the interpreter in SpongeBSHD in the first place.
If someone uploads a poison plugin then his or her server is already compromised. The plugin itself could do any amount of damage that could be done by access to the BeanShell interpreter, so why would it have to go through SpongeBSHD? If someone writes a poison plugin so specific as to grant other players access to this plugin, it may as well include its own BeanShell interpreter and at that point it becomes clear that the issue of poison plugins is a problem of its own, not one that belongs specifically to SpongeBSHD or to any other plugin.
I feel that it does not need to be very big, because of SpongeBSHD’s security measures.
Why are you throwing anti-trust on permission plugins? Is there a reason we shouldn’t trust permission plugins all of a sudden? Permission plugins can at least offer something a text file can’t. Rollback, and immediate action. Without having to shut down the server you can simply execute a command, and remove the permission. With a text file you have to log in over Webpanel, and shutdown the server. Allowing a gap to execute things such as the fork bomb (which with most hosting providers you don’t have the ability to stop).
If it’s not meant to go on a production server than the offline/online shouldn’t matter at all. Though admittedly I didn’t see that, and that definitely is a slight benefit.
(I put blocking in quotes cause you can’t truly block methods). The point is you said earlier you were more secure because:
“that uses a preexisting dynamic code execution library”
I took that as to mean it’s more secure because you are using a pre-existing library. It appears as you say later I mis-interpreted that, and I concede (and apologize) as I took that the wrong way.
True it’s harder but again if it’s not meant to be on a production server than this shouldn’t matter, and makes it harder to the end user. I still fail to see why you are so against a big warning, and than a permission system (for ease of use of the actual user). As that would be the most secure. Because it would never be deployed in production in the first place.
See above.
The Security just creates a hard to use plugin. Again if it is as you say not to be used on a production server (which is obscurely hidden in one comment (to the glancing eye they won’t catch it (I’m a prime example))). Than a big warning, and simply using the permissions would create an ease-of-use, and would be clearer overall.
I never said it would be his fault. I said he would have to deal with people installing it who don’t and than complain a lot.
Permission plugins and the permission system in general are usually great ways to manage command and feature access, but not for something as powerful as a code interpreter. Say Alice has a Sponge server and she trusts Bob when it comes to server management, so she promotes him to admin and gives the admin group the asterisk permission. If SpongeBSHD were permission based, Bob would now have unnecessary access to the server machine, along with all other admins, when the original intent was to only give him access to everything within the Minecraft server.
All you have to do is modify the file and save it. And you can even do this with /bshd: /bshd writer = new BufferedWriter(new FileWriter(SpongeBSHD.instance.allowedPlayersFile, true)) /bshd writer.newLine(); writer.write("SomeUUID"); writer.close()
It’s quite easy to manipulate a simple list of UUID’s in a file. It’s not as easy as /trust yourFriend but it shouldn’t have to be, simply because of how few people are expected to be using SpongeBSHD on a server.
I have added a more visible warning to the original post.
What I do is only let the commands be usable from console. There’s way too much potential in exploits being found in Mojang’s authentication, the permissions code, or the server code.
Permissions code breaking -> exploited
Mojang authentication permitting the wrong user -> exploited
Server code exploit allowing to login as another user -> exploited
Within the permissions system, I have plans to allow assigning permissions by ip – this is still spoofable if your router is misconfigured, but also depends less on mojang login servers and authentication systems.
Also, to avoid the issue of having a user being assigned a default permission of true getting permission to use this plugin accidentally, you could mark SpongeBSHD’s permission as default false, like so:
Aren’t most people’s home routers normally set up for dynamic IP’s? And it wouldn’t be uncommon for multiple people in the same local network, say in the same house, to be connected to the same server through the same router, so they would appear to have the same IP. Would the permission assignment by IP be in addition to assignment to specific users?
Would this only be defaulting to false if not specified by the permissions applied to a player by a permission management plugin, or would it also not be included in the asterisk permission?
After sk mentioned it, I’m also worried about what would happen if permissions code brakes. Requiring separate passwords seems like the best solution to me.
Wonder how many “password”'s and “123abc”'s passwords there will be used with this plugin. Just saying, most people(even people who know better) use easily cracked passwords. Birthdates anyone? Maybe a limit on how many wrong password attempts can be put into place. (Configurable of course)
I use the hostname that people connect with as part of my servers’ permissions plugin. It puts hostname-authenticated (on top of Mojang authentication) users into an elevated ring of access, but won’t reject users without it. It’s a practical compromise between security, effectiveness, and ease of use.
Though personally I still don’t let anyone run BeanShell commands in-game.
This would be excluded from the asterisk permission – and in all the time I’ve been involved with PEX there hasn’t been a single bug granting users permissions they hadn’t had recently (this is taking into account a few cache invalidation issues).
However, imo you should not force users into a default track – I find turning perms down on my local testing server to be pretty useful. You could always make the option a configuration knob of whether to allow non-console users access.