Please Do Not use setSecurityManager Or createSecurityManager.

[PonyPC]

Please Do Not use setSecurityManager Or createSecurityManager.

I'm a hosting to serve player's bukkit or mcpc.

And I have set the default java policy to prevent java attack or execute system command or view root files.

The FML detected if the createSecurityManager or setSecurityManager privilege exists, or stop going.

Any other server like bukkit , spigot , minecraft_server won't request these 2 functions.

Please! Please!

Thanks.

[LunNova]

Alternatively add a system property which can be set to disable it. -Dfml.disableSecurityManager=true?

[PonyPC]

@nallar Still not working T_T

[Parker8283]

He was suggesting that it be added to FML. That's not a property currently.

[PonyPC]

@Parker8283 All right. Thank you, sir. Wish it can be added as soon as possible.

[cpw]

@PonyPC why? It won't be disabled. Delegation is a possibility, however, noone has given me a legitimate justification. What library are you using that provides a security manager in minecraft?

[PonyPC]

@cpw I start java process by pass these arguments: ...... Djava.security.manager -Djava.security.policy=java.policy ....... to prevent a user upload plugin which can execute Runtime.getRuntime().exec(). Think about it: exec('rm -rf /home/java') or exec('cat /etc/password'); That is very dangerous.

[PonyPC]

@cpw if the FML request security manager and set null, the plugins also can set some privilege to skip limitation.

[LexManos]

Please provide full details, these half-bits are not useful. Allowing for the removal of FML's Security Manager will do nothing but cause Modders to continue there unfriendly activities. Yes, allowing for exc is a rather bad idea in mods. And may be another thing that we explicitly deny in FML's SecurityManager.

However we need to see your full setup in order to find a solution that protects everyone without opening a major hole for anyone that is not you.

[PonyPC]

@LexManos please provide a property to disable FML setting its custom security manager. If I set '-Djava.security.manager -Djava.security.policy=java.policy' in java execute parameters, and don't allow this permission in java.policy: // permission java.lang.RuntimePermission "createSecurityManager"; // permission java.lang.RuntimePermission "setSecurityManager"; the FML will not able to set its custom security manager in: FMLSecurityManager(since 1.7.2) and throw a exception of 'FML was unable to install the security manager. The game will not start'. Then server is stopped. If we allow the FML to set custom security manager, yeap, the FML won't do harmful operation, and won't stop at that exception above, BUT any other plugins can overwrite custom security manager and set permission to touch root file, execute external commands, etc. So please give us a property to disable force install security manager in case of we using our java policy files, to set global security. Thank you !

[Kubuxu]

@LexManos I've seen that you created TerminalTransformer so the security manager in no longer necessary. It is extremely counter productive. Treat it as ability to toggle off signature check. In rare cases(apart from dev setup) it is really useful. Recently I had to quickly fix corrupted map. The breaking part were particles but there was no sign of which mod was causing it. Adding bits of code here ant there allowed me to fix it quicker than setting up whole dev space.

[davboecki]

@Kubuxu The thing is, that the transformer can be easily bypassed. So the security manager would still be necessary.

[Kubuxu]

Everything can be bypassed by requiring customized version of forge. It is necessary to find balance. If you are worried that some modders might require users to use this option just don't stop launch if security manager can't be changed or add option for suppressing this failure.

[PonyPC]

@Kubuxu yeah! I totally agree with you. Please give us an option to disable or enable FML security manager, not stop launch.

[Kubuxu]

@PonyPC I am in the same situation as you. The worst case scenario is we would have to build each version our selves. But I don't like using extremely complex system for task like that.

[PonyPC]

@Kubuxu OMG,we must build every new Cauldron and forge version to fix this problem . Big job & headache @_@

[LexManos]

@PonyPC "BUT any other plugins can overwrite custom security manager and set permission to touch root file, execute external commands, etc." This is actually incorrect if you understand anything about Security manager.

I've spoken with cpw, the answer is No. Last time we removed it a slue of mods came out that did the exact thing we are preventing. If you have a valid concern speak publically about it, I have requested your policy information so that we may find a solution to satisfy everyone. This SecruityManager has nothing to do with signatures so @Kubuxu's issue is null and void.

If you are TRULY a server host then do your job and secure your servers. nothing that FML has done prevents you from doing so, The 'default' implementation is a joke which even with a nicely crafted policy list can EASILY be bypassed.

So again. state your issues, provide the specifics of what security issues you're running into and we can address them. A simple 'omg remove it cuz I no like it' will not suffice.

Sacrificing the security and end user experience will not fly, it is a sad day that we even need to THINK about a SecurityManager but we do.

If it is THAT much of a issue you can EASILY write protection schemes into either plugins for Forge or custom versions of the Forge server for your service. 'Big job & headache @_@' .... big job.. right... its a 1 line change and 2 line build. This just shows that you have no idea what you're doing, or the ramifications of what you are asking.

[ArcanoxDragon]

I think for once I actually completely agree with Lex here. Disabling custom security managers does NOT secure your server from Java attacks; you should be using proper sandboxing and virtualization instead. You shouldn't be running a server-hosting company if you can't provide proper security.

[cpw]

One concession we could make Lex, is to provide a 'write protection' - specifically, add a system property that would stop any write/read attempts outside the game and assets dirs. I think this would have to default to off, but it could provide a compromise..

[PonyPC]

@-LexManos As I mentioned, I did not want to remove FMLSecurityManager. I just wanna a property to disable it which some people use their own java.policy file. Everyone can keep FML's security manager working. The truth is we cannot choice enable or disable it. If you are not allowed FML setSecurityManager, the FML is going to close the game server. And if we give the privilege to use setSecurityManager, the customer can upload a modified server jar that contains a harmful code to enter system directory, use Runtime.getRuntime.exec() to execute external command, etc. And you can see my policy file:

/** HIDEN **/

And I also want to say: security is always the first things in internet even everywhere.

@-briman0094 Disable it and use our own policy is the significant, NOT disable it and run it anyway. Java is a sandboxing if you know its security policy.

@-cpw Yes, you guys do the right. But you are write into code which can be modified by the hacker or replace the whole jar. Controlling the security from system runtime isn't a better way? What do you think?

---

disappointed, bye everyone

[octylFractal]

@PonyPC If you want to do this right, you would create an account for each user, give them their own sandbox directory, and allow the permissions on their directory. GoDaddy did this for their hosting. I used PHP to pop open a shell, and I could only mess around inside my sandbox area. I could remove things, blow it up, but it wouldn't harm anyone else. If you don't sandbox, you aren't doing this right. If your customers have access to rm -rf / then something is seriously wrong with your setup because you don't even need Java to do that. If you want me to show you that your protection is worth nothing, I'll even try to hack it for you.

[cadyyan]

Along with @kenzierocks suggestion, you could use a chroot or something similar to prevent access to places the user shouldn't be.

[GUIpsp]

The PR I submitted should fix this, allowing for further securitymanager checks.