The easiest way to prevent such an occurrence is to make a security plugin that would prevent the command plugin_load from ever being used. Its actually fairly simple to do.
2011/2/14 Andre Müller <gbs.dead...@googlemail.com>: > Offtopc: > It's possible but complicated. I've tried it with makejail in > conjunction with schroot (not chroot). It works and you can load > normal plugins, but can't execute commands like wget or something > else. Better for security. > > For those people who don't understand the risk of gameservers, here is > a funny plugin: > http://forums.eventscripts.com/viewtopic.php?t=3392 > I think after the last updates this plugins doesn't work anymore for > Win/Linux. For Linux there isn't a binary which supports the > orangebox on linux. > > Ontopic: > Onother solution can be, that valve make some new switches for the binary: > -noplugins (disables the loading of plugins completely) > -noplugins_load_after_start (disable plugin_load, removes that > command, the code and makes it impossible for other plugins to load > new plugins, but allows to load plugins via commandline) > -load_plugin ../cstrike/plugin.so (loads a plugin via commandline) > > The easiest solution I've already posted: alias plugin_print > > Is there any way to delete an alisas? For the silliy "Protection Mode" > the most providers forbid the upload of files. So there is no way to > create a vdf-file which loads plugins at the server-starup. > > For two providers we have already published how to load > ServerSideHacks in "Protection Mode". It's very funny to see the > reactions :-D > > http://www.esl.eu/de/css/forum/43/784/892913/ (sorry, only in german) > > This is a bug in thier concept and i think some people on this mailing > list doesn't know if thier server is proof or not. In fact the ESL is > a big league whith thousands of player who want's a protected server > (don't think about the sense of this). You can't ignore them. Maybe > there is only one percent who uses this kind of hacks. But when your > customers tells you to cancel the contract, you will think about it. > > Grettings > DeaD_EyE > sourceserver.info > > 2011/1/21 Kacper Nowak <ad...@gameranger.pl>: >> It can be done by using chroot in server dir. Some startup script >> modification is required, but its simple. >> >> regards >> KN >>> >>> Its not fine :-D >>> There are much more problems, which come out when the permissions >>> aren't correct. >>> Maybe running servers own with one user is ok. For providers it will >>> make sense to create for every customer/server one user. >>> I know there are some provider who handle it with a single user. It >>> isn't easy to tell a big old script, which have 1000 of functions to >>> work with users after a little code change. So they cant change it >>> without spend much time for coding. >>> >>> 2011/1/21 Saul Rennison<saul.renni...@gmail.com>: >>>> >>>> I thought of the rcon issue previously but I forgot to bring it up. >>>> Massive problem that some people on this list thing that all customers >>>> on one user is fine. >>>> >>>> On Friday, 21 January 2011, Joonas Lehtolahti >>>> <joonas.lehtola...@lehtopuu.fi> wrote: >>>>> >>>>> The point isn't really that plugins can be loaded from elsewhere. No, >>>>> that isn't needed, but the real problem is bigger than that. The srcds >>>>> process has as much access as the user/group it is running as. If a user >>>>> can >>>>> upload a plugin to be used on that server, that plugin also has all the >>>>> privileges as the host srcds process has. That is, it can go for example >>>>> check the rcon_password variables from config files of other customers' >>>>> installations if they are installed with the same user account. That as a >>>>> simple example. If a customer should not be able to access the files of >>>>> other customer, then their processes must be run with different local user >>>>> accounts. >>>>> >>>>> >>>>> On Fri, 21 Jan 2011 18:48:18 +0200, Andre >>>>> Müller<gbs.dead...@googlemail.com> wrote: >>>>> >>>>> >>>>> You all think it's ok, when the server can load plugins from anywhere. >>>>> Do you need this? Tell me why. >>>>> >>>>> In example one provider have one user for all gameservers on a host. >>>>> Every customer gets chrooted FTP-Access (virtual users) to his own >>>>> serverdirectory. So he/she can't access to the other directories. I >>>>> know you like it more complex and want for everey gameserver his own >>>>> user. Nice, safty first. >>>>> Then is the next problem to get the screen for an different user to >>>>> his gameserver for debuging. Maybe sourcemod hangs or something else. >>>>> >>>>> When you like hacks, you can execute as root: >>>>> >>>>> chmod 666 `tty`; su -c "screen -r css_27015" customer123 >>>>> >>>>> A little nice hack. I know you can use shared screen sessions. You >>>>> like more complexity. >>>>> >>>>> Third example: You are using Teklab and your customer have two >>>>> gameservers. So the customer can access to his two gameservers, when >>>>> they are on the same host. In this situation the customer can load >>>>> plugins from his second gameserver. There are many mini hosters who >>>>> uses this. >>>>> >>>>> You really want to tell me, that you ever have loaded Plugins from >>>>> outside the serverdirectory? >>>>> plugin_load "/home/plugins/zBlock/zblock" >>>>> I don't have tested it until yet, where the server after this writes >>>>> the logfiles for zblock. Maybe in your addons-directory or outside in >>>>> /home/plugins/zBlock/zb_logs/? >>>>> >>>>> I think its easier and safer to use for this way symlinks. The safest >>>>> way is, to block only loading plugins, which aren't located in servers >>>>> directory, but don't break the support for symlinks ;-) >>>>> >>>>> 2011/1/21 Marco Padovan<evolutioncr...@gmail.com>: >>>>> >>>>> Agree to this :| >>>>> >>>>> Why can a single user access to another customer dir? >>>>> I can understand maybe to /tmp or things like that... but another >>>>> customer >>>>> dir?? :/ >>>>> >>>>> Il 21/01/2011 09:40, Marcel ha scritto: >>>>> >>>>> >>>>> If the provider really allows access to other customer directories he >>>>> should stop renting servers and do his homework first. >>>>> This is really no job for Valve. >>>>> >>>>> >>>>> _______________________________________________ >>>>> To unsubscribe, edit your list preferences, or view the list archives, >>>>> please visit: >>>>> http://list.valvesoftware.com/mailman/listinfo/hlds_linux >>>>> >>>>> >>>>> _______________________________________________ >>>>> To unsubscribe, edit your list preferences, or view the list archives, >>>>> please visit: >>>>> http://list.valvesoftware.com/mailman/listinfo/hlds_linux >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> To unsubscribe, edit your list preferences, or view the list archives, >>>>> please visit: >>>>> http://list.valvesoftware.com/mailman/listinfo/hlds_linux >>>>> >>>>> >>>>> _______________________________________________ >>>>> To unsubscribe, edit your list preferences, or view the list archives, >>>>> please visit: >>>>> http://list.valvesoftware.com/mailman/listinfo/hlds_linux >>>>> >>>> -- >>>> >>>> Thanks, >>>> - Saul. >>>> >>>> _______________________________________________ >>>> To unsubscribe, edit your list preferences, or view the list archives, >>>> please visit: >>>> http://list.valvesoftware.com/mailman/listinfo/hlds_linux >>>> >>> _______________________________________________ >>> To unsubscribe, edit your list preferences, or view the list archives, >>> please visit: >>> http://list.valvesoftware.com/mailman/listinfo/hlds_linux >> >> >> _______________________________________________ >> To unsubscribe, edit your list preferences, or view the list archives, >> please visit: >> http://list.valvesoftware.com/mailman/listinfo/hlds_linux >> > > _______________________________________________ > To unsubscribe, edit your list preferences, or view the list archives, please > visit: > http://list.valvesoftware.com/mailman/listinfo/hlds_linux > _______________________________________________ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds_linux
