Yes, this can also be a solution. Can you write a little VSP for this? Maybe whith a whitelist combinied with hash values of the allowd plugins and implemt a command for Players to show loaded VSP and if the hash values are ok?
The rest is the job of the providers. Greetings DeaD_EyE 2011/2/14 Kigen <theki...@gmail.com>: > 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 > _______________________________________________ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds_linux
