Bukkit and its plugins are less GSP-friendly than hMod and operate in a non-secure way.

Here's the way the plugin architecture works in Bukkit, as I understand it:

• Bukkit automatically loads everything in plugins/. hMod only loaded the 'plugins=' line.
• Bukkit plugins (e.g. WorldEdit) sometimes expect to have write access to plugins/.

WOAH!!!

That might be sort of acceptable if you're just running it standalone by yourself. In a game service provider environment, both of those things are BAD NEWS.

As a GSP, I have two concerns with this: Automation and security. With hMod, my server-side stuff simply had to write a change to server.properties to change which plugins were loaded. The plugins themselves were in a central location, owned by a different user so that they cannot be overwritten by malicious plugin code, and the central directory they were in was simply symlinked into each server's directory. This is the most elegant way I know of doing this.

The Bukkit way of doing this - and please correct me if I've missed something - requires a copy of the plugin to be in each server's plugins/ directory. This means that instead of maintaining a single repository, I have to write in extra logic to create/delete symlinks in each server's plugins directory. That's really messy. It would be better if we could just specify which plugins to load in a config file, like what was possible with hMod.

Furthermore, the plugin directory has to be owned by the same user that the server is running under for certain plugins to work, which is bad from a security standpoint. A malicious plugin can now create files in the plugins directory, including other plugins. If the server admin is not smart enough to chmod the plugin files so that they're not writable by the user the server runs as, it would be possible for a malicious plugin to do some really malicious stuff:

• User downloads a cool plugin that has malicious code. The plugin creates two additional plugins, as follows:
• The plugin writes a copy of itself in the plugins/ directory, but it leaves out the malicious code. If the copy is ever decompiled, it will appear to be as pure as the driven snow.
• The original plugin then writes another plugin. This one does something malicious, like installing a back door into some other developer's plugin so that if any forensics are conducted it will look like someone else did a bad thing. It could also just delete the world or do other annoying things.
• The second plugin deletes the original one and renames the "clean" copy to the original's name. It then does whatever bad thing it's designed to do, and then deletes itself. Server admins would have to use Tripwire or some other software to even detect it. (How many of you guys have even heard of Tripwire?)

Don't believe a mod author would ever do something like this? Well, as it turns out, at least one already has. There are probably more, which we haven't heard about simply because they haven't been caught. In case you don't like clicking links, here's what you need to know:

"I hosted my own server, got a few friends to play on it. I was using MCAdmin. Some guy comes on called Doridian with a [DEV] in front of his name, couldn't speak English very well and thought, oh what a funny guy. Blatently trying to troll my server. So I banned him.

Next five minutes I get banned from my own god damned server. I realise there is a global ban option so I disable it. Still can't connect, start reading through the server log. See that there is an entry there called "Heartbeat fail: Unban Doridian!". Okay maybe this guy is real, so I unbanned him and waited for him to come back."​

Dinnerbone, if you're reading this, you are the guy who decompiled MCAdmin and spilled the beans on exactly what rotten stuff he was doing. I'm sure I don't need to go out of my way to emphasize these things to you.

The rest of the thread contains the most incredible examples of entitlement complex I have seen in years. It's a great read. The people behind that plugin apparently think that you running the plugin on your server gives them the right to do whatever they want behind your back - even banning you from your own server. I would not be surprised if a security audit for all the available Bukkit plugins found a few here and there that had similar backdoors. (For that reason, I will not run any closed-source plugins on any of my machines.)

There is also this discussion on Reddit:

03:18 Doridian i could abuse the autoupdate feature
03:18 Doridian to make them run ANY code i want
03:18 Doridian sooo
03:18 FullDisclosure Indeed you could
03:18 Doridian i technically have all power
03:19 FullDisclosure Indeed you do
03:19 Doridian so they should not bitch about one little thing
03:19 Doridian allowing me to run commands on their server​

Doridian is not an unusual case at all. The most popular alternative Second Life viewer for a long time was made by the Emerald Team, some of whose members were found to be doing really nasty shit like stealing things out of other peoples' inventories. (To give some perspective, this is a 100x bigger deal in Second Life than it is in Minecraft.) They had the exact same sense of entitlement, and eventually their viewer was banned outright. Any time you run a binary from some random dude on the internet, there's a chance that random dude is a sociopath whose code shouldn't be trusted to run on a solar powered calculator, let alone your computer.

I really hope you folks are beginning to see just how important it is to button up security on your servers, and how important it is for all server mod/plugin authors to realize this and incorporate it into their work. This is the kind of stuff we're up against.

The second issue I wanted to address: Some plugins create additional directories under plugins/ to store their configuration files, such as WorldEdit. Again, this breaks the central plugins directory that makes sense in a GSP environment. It would be better to store these in a separate directory, e.g. plugin-configs/. It's also a bad idea for the reasons I've stated above.

In summary:

• Please let us specify which plugins to load. Automatically loading everything in plugins/ is a security risk.
• Plugin authors, please do not assume you have write access to plugins/. It's FANTASTIC that you don't want to clutter up the main directory. As a GSP, seriously... THANK YOU. However, please put your configuration files somewhere else.
• This is the best time to implement these changes, as Bukkit has not yet been officially released. Ideally, plugins would store conf files in a standardized way. The Bukkit team ought to consider formalizing this somehow, e.g. "always store your configuration files in plugin-configs/".

I hope some other GSP types will chime in on this. I can't possibly be the first person these things have occurred to.

 

I endorse this message.

 

You could possibly develop a plugin to do this.
Make one plugin, and only put this one in plugins directory.
That plugin would then have code similar to:
https://github.com/Bukkit/CraftBukkit/blob/master/src/main/java/org/bukkit/craftbukkit/CraftServer.java#L55
which calls
https://github.com/Bukkit/Bukkit/bl...rg/bukkit/plugin/SimplePluginManager.java#L82
which would call (for Java plugins)
https://github.com/Bukkit/Bukkit/bl.../bukkit/plugin/java/JavaPluginLoader.java#L78
which is where you'd have to have that relative to the players server instead.

In fact, instead of a plugin, it'd be better to fork craftbukkit for your own multiserver flavour. Bukkit itself is very simple to use for the common folk, which is what a large amount of people are (you make a business off them).

If your still after the plugin route, my theory is:
Essentially, have your manager script edit the configuration holding the names of the plugins for that server. This plugin would read that when enabled, and load those plugins from that path, or error out when it's not in your master plugin directory.
Most plugin should be using getDataFolder() to create their config path, and bukkit manages that.

My only question for if this would would is if the Plugin Manager had problems adding/enabling a plugin while enbling another.

Actually. It looks like there's a secret option (i think) in the server.properties config for if your interested.
plugins=directory_filepath
That would be hectic for a shared repo as the data folder for each plugin is the same for each server.

But uh, if you want official, I shouldn't be talking. >.>

Edit:
Actually, it'd probably be easiest to just add a plugins_data_folder in the server config.
And I guess you could check a pluginsautodetect option alongside a pluginlist option.

So uh, yeah...afterthoughts. >.>

 

Very informative post. From what my un-informed self can tell, we do seem to need a deticated plugin-config directory.
Since plugins would only be run from the plugin directory it would prevent any chance of a plugin creating a new plugin or injecting malicious code into another plugin.

 

I would love to get into plugin development. I already know how to do stuff in Java. Unfortunately, we're still in beta, and I'm running the technical side of my company pretty much as a one-man band. Running server farms, doing performance tuning on the machines as well as Java itself, developing software for the website to securely talk to the servers, writing a control panel that knows all about mods (including dependencies and incompatibilities), scouring server logs and doing other things to catch assholes who torch things and sign-hack and generally do similar socially retarded things, etc. etc. etc. is basically a full time job and then some. There are times when I stay up until 8AM or later, just working on this stuff.

I would certainly like to develop Bukkit plugins and give them away for free. I already give away some of my best work in Second Life. (Serious stuff, flight simulation that literally took years to perfect.) I like writing awesome code and get a kick out of knowing that people enjoy my work. I just don't have the mental resources to dive into developing for Bukkit right now.

The suggestions I've made don't just make sense for me. The automation stuff is highly relevant to GSPs, which are a big part of Minecraft's success and are certainly a major consumer of Bukkit. The security aspects have an impact on everyone. That's why I think it makes more sense to nip this in the bud now and give the results to everyone as part of the standard installation.

Plus, we have a real chance to influence Mojang. If I wrote this in an email to Notch, I have no doubt that it would go ignored. Bukkit has a direct chance to influence how plugins work when they're officially supported in Minecraft, because Mojang actually talks to the Bukkit team. If we fix this now, we have a better chance of not being locked into an architecture that exposes us to unnecessarily high risk from sociopaths like Doridian.
--- merged: Mar 4, 2011 1:29 PM ---

That also makes sense from a "keeping things clean" perspective. Some plugins have recipes and configuration files and so on that currently wind up getting stored under plugins/. Keeping them separate would make things easier to keep track of.

 

Ack. Too much to read. I'll tackle this bit by bit and come back later.

First, I want to stress this, the design of bukkit is not final and we are constantly changing.

We will have a method of saying which plugins are loaded and not. The current system is temporary just to get them working at all. We haven't settled on the best way yet.

First I'd like to point out the command line argument for specifying what folder to load plugins for. Next, I'm going to tell you how inadvisable this is.

We tell plugins to store their data in {folder}/{plugin name}. We do not guarantee them access to any other folder, and they should never access data from any other folder. This folder is theirs to do as they wish.
The reason we do this is so that they don't clutter up your root directory (hmod anyone?), and for easy uninstallation & backups. Instead of tracking down every file and folder for every plugin, you just delete or backup or restore a single folder.
If you have multiple plugins specifying the same plugin folder, data will become mixed and screwed up.

Once we get Fill up, we specifically won't give plugins our Walrus of Approval if they're closed source. Just want to mention that. Most likely as a GSP you'd want to only allow installation of our approved plugins, for being trusted.

Next, actual security. We are looking to do the best we can but this is an extremely delicate and tricky thing, not something we want to rush into breaking crap and causing panics. Some things in this are just out of our control, too, and we can't do a thing to stop them. For example, it's entirely possible for a plugin to crash every client who connects *and we can't do a thing to stop it*. Furthermore it's possible for them to crash the server itself, and we can't stop it. We find and patch up every major exploit as we're told about them but minecraft has thousands, and it's very complicated to do.

We will impose security restrictions on what plugins can access in the future, but we have to get back to it as a later thing. We have other things to worry about first, before attempting another impossible task.

We're going to investigate the best ways to go about this, without breaking too much and still keeping things clean.

• It's temporary, and it's temporary.
• Yes.
• Yes.

 

Thanks so much! This is exactly the level of engagement I was looking for. In the process of setting up a GSP, I've learned a lot of stuff. If there's any way I can help you guys out by adding that perspective, I'll be more than happy to do so.

If I can specify one directory for plugins (e.g. a symlink pointing to a single plugin directory owned by another user, which is under version control & only has to be updated once per machine) and another for plugin configs (a separate per-Minecraft directory), and have the ability to specify which plugins to load, that would be exactly what I need. (Plugins are supposed to read their conf directory out of a variable supplied by Bukkit, right?)

If you're not architecturally in a good place to do that right this second, I'll understand. However, I'm willing to donate to the Bukkit project in order to have it prioritized. I've got about 40 people who want it!

 

I link my plugins in the plugins/ folder for version control. I guess I could set the actual plugins somewhere else owned by a different user. you can shut off write the the plugins/ folder and leave it for each config folder. If suppose you could get away with setting everything to -w by default and then just open up the configs that need to be written. This assumes a *nix environment. I have no idea if you can do something like that in windows.

hmm, Let me test that: (this looks like it works)

Code:

dr-xr-xr-x  7 minecraft minecraft    4096 2011-03-04 08:42 plugins
...
minecraft@server:~/bukkit_dev/plugins$ ls -al
total 24
dr-xr-xr-x  6 minecraft  minecraft  4096 2011-03-04 08:22 .
drwxr-xr-x  8 minecraft  minecraft  4096 2011-03-04 08:31 ..
drwxr-xr-x 16 minecraft  minecraft  4096 2011-03-04 08:19 backup
drwxr-xr-x  2 minecraft2 minecraft2 4096 2011-03-04 08:19 plugins_safe
drwxr-xr-x  2 minecraft  minecraft  4096 2011-03-04 08:22 WorldEdit
lrwxrwxrwx  1 minecraft  minecraft    33 2011-03-04 08:20 WorldEdit.jar -> plugins_safe/WorldEdit.jar.4.0.b8
drwxr-xr-x  2 minecraft  minecraft  4096 2011-03-04 08:22 WorldGuard
lrwxrwxrwx  1 minecraft  minecraft    34 2011-03-04 08:20 WorldGuard.jar -> plugins_safe/WorldGuard.jar.4.0.a1
minecraft@server:~/bukkit_dev/plugins$ touch evil
touch: cannot touch `evil': Permission denied
minecraft@server:~/bukkit_dev/plugins$ rm *.jar
rm: cannot remove `WorldEdit.jar': Permission denied
rm: cannot remove `WorldGuard.jar': Permission denied
minecraft@server:~/bukkit_dev/plugins$ rm plugins_safe/WorldEdit.jar.3.2.2
rm: cannot remove `plugins_safe/WorldEdit.jar.3.2.2': Permission denied
minecraft@server:~/bukkit_dev/plugins$ ../start
08:52:59 [INFO] Starting minecraft server version Beta 1.3
08:52:59 [INFO] Loading properties
08:52:59 [INFO] Starting Minecraft server on *:26565
08:52:59 [INFO] This server is running Craftbukkit version git-Bukkit-0.0.0-491-g3df6906-b490jnks (MC: 1.3)
08:52:59 [INFO] Preparing level "world"
08:52:59 [INFO] Preparing start region
08:53:00 [INFO] WorldGuard loaded.
08:53:00 [INFO] [iConomy] Failed to connect to database: org.sqlite.JDBC
08:53:00 [INFO] WorldEdit 4.0-beta8 enabled.
08:53:00 [INFO] WorldEdit: No known permissions plugin detected. Using configuration file for permissions.
08:53:00 [INFO] WorldGuard: No known permissions plugin detected. Using configuration file for permissions.
08:53:01 [INFO] WorldGuard: Single session is enforced.
08:53:01 [INFO] WorldGuard: TNT ignition is PERMITTED.
08:53:01 [INFO] WorldGuard: Lighters are PERMITTED.
08:53:01 [INFO] WorldGuard: Lava fire is blocked.
08:53:01 [INFO] WorldGuard: Fire spread is UNRESTRICTED.
08:53:01 [INFO] WorldGuard 4.0-alpha1 enabled.

(yes I know I didn't set up iconomy right

this doesnt protect plugins' config files.. and it wont let a plugin make it's own dir. on first start since I set plugins to -w. So when I install the plugin I have to set plugins/ +w, link the plugin, make it's config dir by hand, set plugins/ back to -w, then start the server and let the plugin make the configs. but that can be scripted.

 

It's a good idea, but you still have to write logic to screw around with adding and deleting symlinks. It can be done, but it's really clunky and I'm not sure a reasonable analog exists in Windows. (I know you can link directories, but shortcuts don't act the same as symlinks.) Not that I use Windows, but I know some people do.

 

the advantage there is that you could have a script run all of the linking and permissions and have that script called by your web-admin-control-panel-thingy assuming you have one. this way users get the security without the hassle. but i agree it's clunky

edit: oh ya, and that windows thing

 

I personally am not a fan of attempting to impose arbitrary limits on environments because even if good design goes into place, there's always the likelihood of exploits. The entire system will then fall apart if someone finds just a single one, and when you're installing many different plugins, the risk only quickly grows. Java has a security manager that can be used to very specifically control what the JVM can do, and I find that to be a far safer approach than trying to enforce certain design guidelines. Jailing the server entirely into its own sandbox would be an even safer approach.

In my opinion, you should not control which executable code can run, but rather what executable code can do.

 

It would be interesting if Fill eventually told you what elevated permissions a .jar needed, like in the Android Market. A chat color changer that needed network access would stand out!