E2 extension menu with first-run?

[AbigailBuccaneer]

There's been a lot of squabbling about which extensions should be disabled by default (#1007 #1009). Those on the disabled-by-default side are aware that many of these extensions are terrible for security (as you can eg. allow either the server or other clients to make arbitrary HTTP requests), those on the enabled-by-default side are aware that most admins are hard to reach and don't care enough about E2 extensions.

I think a reasonable solution to both of these problems is to have an initially very conservative set of extensions enabled (ie. nothing that gives you access to anything outside of the game world), but to have a graphical interface for admins to enable/disable them. Then, it could automatically show up when it's not been run before (which we could keep track of with a simple convar, maybe storing a version so it can automatically show up again when new extensions are added).

Each entry in the list could have a link to a page on the wiki about the extension, what functions it adds, etc., and also list security risks inline. (Maybe we should assign each extension a high/medium/low security risk?)

Would this settle the arguments on both sides? @TomyLobo @Divran @immibis @Nebual

(I don't want to get caught up in more arguing, so frankly if the majority of actual Wiremod devs think this is a good idea then I'm likely to implement it myself and disable a bunch of extensions by default.)

[Divran]

Sounds great. Just maybe don't go into too much detail on why the extensions could be risky. Don't want to give abusive admins any ideas.

On Mon, Nov 9, 2015 at 11:16 AM, Abigail notifications@github.com wrote:

There's been a lot of squabbling about which extensions should be disabled by default (#1007 https://github.com/wiremod/wire/issues/1007 #1009 https://github.com/wiremod/wire/pull/1009). Those on the disabled-by-default side are aware that many of these extensions are terrible for security (as you can eg. allow either the server or other clients to make arbitrary HTTP requests), those on the enabled-by-default side are aware that most admins are hard to reach and don't care enough about E2 extensions.

I think a reasonable solution to both of these problems is to have an initially very conservative set of extensions enabled (ie. nothing that gives you access to anything outside of the game world), but to have a graphical interface for admins to enable/disable them. Then, it could automatically show up when it's not been run before (which we could keep track of with a simple convar, maybe storing a version so it can automatically show up again when new extensions are added).

Each entry in the list could have a link to a page on the wiki about the extension, what functions it adds, etc., and also list security risks inline. (Maybe we should assign each extension a high/medium/low security risk?)

Would this settle the arguments on both sides? @TomyLobo https://github.com/TomyLobo @Divran https://github.com/Divran @immibis https://github.com/immibis @Nebual https://github.com/Nebual

— Reply to this email directly or view it on GitHub https://github.com/wiremod/wire/issues/1012.

[AbigailBuccaneer]

don't go into too much detail on why the extensions could be risky. Don't want to give abusive admins any ideas.

This would only be available to super-admins (as enabling/disabling E2 extensions is only allowed by super-admins), and the risk in most of these cases is to the server rather than the players. I don't think it's worth hiding info from super-admins just in case they're corrupt and secretly want to ruin the server.

[Divran]

Superadmins can still be abusive admins. And if they're super admin on one server and see a detailed description of how http can break shit, they can go to a different server where they're not admin and break shit

On Mon, Nov 9, 2015 at 11:46 AM, Abigail notifications@github.com wrote:

don't go into too much detail on why the extensions could be risky. Don't want to give abusive admins any ideas.

This would only be available to super-admins (as enabling/disabling E2 extensions is only allowed by super-admins), and the risk in most of these cases is to the server rather than the players. I don't think it's worth hiding info from super-admins just in case they're corrupt and secretly want to ruin the server.

— Reply to this email directly or view it on GitHub https://github.com/wiremod/wire/issues/1012#issuecomment-155026284.

[ghost]

I was already thinking this is great idea, till you said you will add notes about how YOU think how risky they are... so, now I will not only have to somehow get owner's attention to that, but then to somehow get him to understanding that http for example worked for a long time and never caused security problems... impossible. And additionnaly, you want to block some more now? Awesome.

[TomyLobo]

It has to be an informed choice though. Not just an "Enable HTTP" checkbox.

Everyone clicking that checkbox needs to be aware that this means people can make arbitrary HTTP GET requests from your server. Thankfully there's no way to make POST request or we'd be totally hosed.

If you need the owner to be ignorant to convince them, you're doing something wrong. Yes, they'll probably refuse and rightfully so. Give them a whitelist as I proposed, and that problem fades away. "access to pastebin and youtube plz" is much less scary than "access to anything plz"

[ghost]

If you need the owner to be ignorant to convince them

I don't.

Give them a whitelist as I proposed, and that problem fades away.

Would you as admin wanted to waste your time for every user in personal, allowing him to do something special, which will also require you to change server files and probably restart? No way. Also many people are running own hosting for that stuff (there are many free too), not just youtube, etc.

It has to be an informed choice though. Not just an "Enable HTTP" checkbox.

Well, you can write everything you want to a big license field and have agree\disagree buttons, like google... xD Just don't make it big red sign saying it was just a big mistake that these all worked for such a long time and "you must disable them all to be secure", Ok?

[immibis]

Nothing wrong with making server owners more informed. The only problem I can think of is it might annoy server owners who don't care - it would mean Wiremod is no longer completely "plug 'n' play"

[ghost]

Yes, I think this is great idea actually (on topic, not disabling http). It will show owners what they are probably missing too. And I think you can add voting to that, so admins who don't know what they are doing or don't care at all can just rely on community's choise and press "popular set" button. And active server's admins who know can vote +1/-1.

[oldmud0]

Wiremod Server Community Edition. Security vs. convenience yet again. It's like comparing nginx (full manual config) to MySQL (out-of-the-box, preconfigured optimal settings).

[brandonsturgeon]

I like this idea a lot. @Divran I think it's always a potentially losing battle to prevent admin abuse, though I do really appreciate the efforts made by the wiremod devs to at least help the issues.

It's can be tough to remember that there are good admins out there too, and they might not be very savvy with things like wiremod or lua. What would you think about including some slightly more detailed descriptions in the wiki or something?

[Divran]

All that really needs to be said is

Think about it before you enable http, as it could potentially bring security concerns. Make sure your server is properly protected

or something like that. We probably don't have to say more about that specific issue. Aside from that, of course we can add detailed information about what exactly each extension does, like the wiring extension could say

With this extension, E2 becomes a wire tool. Users can create wires from any entity they control to any other entity they control. Also allows users to fetch wirelinks from any entity they control.

These would then show up inside the menu, so that superadmins can see what's happening

[ghost]

@Divran

Think about it before you enable http, as it could potentially bring security concerns. Make sure your server is properly protected

Just make it clientside and no problems (no more than already exists because you still run server's lua)

Aside from that, of course we can add detailed information

Sure, this is very nice.

[immibis]

@BoggLog

And I think you can add voting to that, so admins who don't know what they are doing or don't care at all can just rely on community's choise and press "popular set" button. And active server's admins who know can vote +1/-1.

Disagree; this is not worth the complexity. And if you let users vote, this would probably be equivalent to enabling all extensions, because players who are not admins have no reason to care about the server's security.

By the way, "there's no reason to disable these" seems to be a common argument. I'd like to point out that adding restrictions can make a game more fun by adding more stuff to do. (For example, there's approximately no reason to use gates in current Wiremod, unless you're on a server that disables E2, so on servers with E2 enabled gates might as well not exist. And on servers with E2 disabled, there's a whole new aspect of Wiremod to explore)

(that's for wiring/remoteupload/propcore/everything else, not so much for HTTP)

[ghost]

And if you let users vote

Just don't let users vote? Make voting only available for owners/admins on dedicated servers, then it'll be far more objective with much less load.

adding restrictions can make a game more fun

exactly - adding restrictions - just if you want, and not by default, and more not for functionality that has already been working and everybody used to. Just don't break things and that's all right (even if it turns out it was a bug - it looks the same for everybody)

[TomyLobo]

software security should not be a function of popularity

[ghost]

@TomyLobo

software security should not be a function of popularity

Nobody said that. We're just talking about functionality, which only adds fun to game, not adding any security concerns.

[AbigailBuccaneer]

@BoggLog you seem to somehow forget every 30 seconds that the HTTP extension is a security concern.

[ghost]

@AbigailBuccaneer did you read all the topic? If http is made cliendside, there's no any more security concerns than we already have because we can' get rid of lua

[TomyLobo]

@BoggLog You're discounting bugs in duplication systems (the latest of which will follow us around for at least a year to come, I promise), social engineering and just plain stupidity. None of these requires any involvement by an admin, but would allow person A to dictate what person B's chip does.

[TomyLobo]

@TomyLobo

software security should not be a function of popularity

Nobody said that. We're just talking about functionality, which only adds fun to game, not adding any security concerns.

If you have admins/owners/people vote for what's enabled by default, you're doing exactly that. Or have I misunderstood you? The person whose name is on the bill should be the one calling the shots, not a simple majority of admins.

[ghost]

You're discounting bugs in duplication systems (the latest of which will follow us around for at least a year to come, I promise)

holy rabbits... can I help fixing them somehow? Are there any you can't still know about?

social engineering and just plain stupidity.

You can't change that anyway (or do that, I'll be happy to be wrong)

would allow person A to dictate what person B's chip does.

This will never happen without person B's explicit agreement for that. And that's how things work. In my opinion, restricting something is the worst way.

If you have admins/owners/people vote for what's enabled by default, you're doing exactly that. Or have I misunderstood you?

Seems so, because I was not talking about extensions, adding any security concerns. Only ingame, probably (like constraint core). And in HTTP,s case, then, definitely, we must fix all bugs and make it clientside, and after that I believe it should be treated like not causing any security concerns, nothing to do with stupidity.

The person whose name is on the bill should be the one calling the shots, not a simple majority of admins.

I don't have a person on my bills, only some buildings which I don't trust to... xD

[TomyLobo]

Who is talking about restricting people? If anything, you are trying to restrict people in their ability to make an informed decision about whom to allow HTTP requests from their machine.

Do you really think people make an informed decision to allow your chip to make HTTP requests when they copy the chess chip you offered them?

This is one way social engineering works. If, for the sake of the argument, we assume that it cannot happen to you because you are smart and strong-willed, there are still the duplicator bugs, one of which was mentioned on the other thread and you're also discounting people who are, for whatever reason, susceptible to social engineering.

I think I repeated the same argument 3 times now without hearing a counter-argument. At one point I'll just give up talking to you people and just go ahead and disable HTTP by default until we (that is the people who are willing to be convinced by a good argument) can agree on a permanent solution (such as a whitelist and/or moving the whole shebang client-side).

[oldmud0]

@TomyLobo That's how fights start, because a developer with write privileges chooses to make a call that goes with the opinion of that developer, not one that is consistent with the general consensus. This has happened plenty of times (remember when Chrome saved passwords couldn't even be password-protected? That was a big debate because the dev(s) did not want to accept any requests to change that, despite a billion cries from end users to add it.)

The bottom line is, you should remain neutral and wait until the debate is over.

[immibis]

@oldmud0 So far the general consensus among all developers seems to be that it should be disabled by default.

On Tue, Nov 17, 2015 at 12:57 PM, oldmud0 notifications@github.com wrote:

@TomyLobo https://github.com/TomyLobo That's how fights start, because a developer with write privileges chooses to make a call that goes with the opinion of that developer, not one that is consistent with the general consensus. This has happened plenty of times (remember when Chrome saved passwords couldn't even be password-protected? That was a big debate because the dev(s) did not want to accept any requests to change that, despite a billion cries from end users to add it.)

The bottom line is, you should remain neutral and wait until the debate is over.

— Reply to this email directly or view it on GitHub https://github.com/wiremod/wire/issues/1012#issuecomment-157212933.

[bigdogmat]

duplicator bugs, one of which was mentioned on the other thread

@TomyLobo It was one bug and will hopefully be fixed soon if the pr is pushed ( last comment on it was 9 days ago ), either way I'm fine with disabling it until it's switched to client-side.

[oldmud0]

When will it be switched to clientside, then? Next year?

[TomyLobo]

@oldmud0 I don't intend to make that change against the will of other devs. I'm going to talk to @Nebual too, first. If his arguments hold water, I won't do it. And no I don't remember that. I have never used any of those browser-integrated password managers. I use KeePass. Also, the change I'm talking about will increase security, not decrease it.

@bigdogmat how do you determine that this is the last one? There likely are also servers outthere that don't update all the addons very often, so it's going to stick with us for a while.

[bigdogmat]

@TomyLobo Afaik the only issue was with the AdvDupe2 area copy and there are only 2 places to get AdvDupe2 and that's the old google code git which if anyone is using it's their fault for using it, and the github version which I'd think most servers would have auto update with svn.

I mean I guess I could see a server downloading it from github and not updating it ever, but that's their fault for not updating, at least imo it is.

[ghost]

Who is talking about restricting people? If anything, you are trying to restrict people in their ability to make an informed decision about whom to allow HTTP requests from their machine.

Both of us and none of us at same time: we're just talking about different strategies of user's control: opt-in and opt-out.

Do you really think people make an informed decision to allow your chip to make HTTP requests when they copy the chess chip you offered them?

Yes and no. Yes, because they always make this decision based on trust to some source, where they got that e2. You always do the same when you open any .exe, .msi, .bat, or (not so obvious) .pdf, .docx, .cdr... No, because they never read anything, you know, they just push that green "Accept" button not knowing they will have to give their soul and everything to third parties for free. So what I think? The last is not a problem of developer. Though good developer can try to make security concerns as obvious as possible, without taking down any functionality (expecially which was already working for a long time), like in cases with .exe win prompts you "you have downloaded this from internet...blabla", .pfd asking if you want to run it's scripts (don't remember). So IMO when they spawn this chess, they should be asked if they understand the riscs with "ok, remember" and "view code" buttons and that'll be all right.

If I was dev here, I would just remain it enabled, but added blacklist for all these local requests and services, first-run menu with enabled checkbox but with text about what it is and what risks you take, and a prompt for users when you're spawning e2s with that. And sure I would fix all the related bugs and make it clienside as soon as possible, if it's not making it too limited (will it still be possible to transfer about 1mb of data?)

[oldmud0]

Don't forget to add a 10s timer on the OK button on the first-time run..

[bigdogmat]

but added blacklist for all these local requests and services

Someone could easily make a site that redirects to the local ip and we can't control that.

if it's not making it too limited (will it still be possible to transfer about 1mb of data?)

It'd probably get a longer cooldown time because it has to network all the data from the client, other than that I don't see any other limits that'd arise.

[ghost]

@bigdogmat

Someone could easily make a site that redirects to the local ip and we can't control that.

You can't have 100% security. Just forget about this idea. Or, if you can't, then start from something serious, which is not wiremod for sure. Don't trust anyone. Your life will become very very hard then, believe me.

It'd probably get a longer cooldown time because it has to network all the data from the client, other than that I don't see any other limits that'd arise.

Not much a problem then.

[immibis]

@BoggLog Actually, modern OSes (Android, iOS, Windows 10, etc) do have reduced functionality in order to alleviate security concerns. For example, iOS prevents apps from making non-TLS HTTP requests. And the whole thing where they try to prevent you rooting your device.

[ghost]

@immibis Too bad examples. Non-TLS HTTP only means that you have to have SSL sert for yr app backend, and (if, idk actually) it also applies to browsers, then it's just too obvious why it was added. Same with rooting - don't you get they want to not just sell you some piece of... thin metall in best case, they want to know everything about you, to have all your data, and to prevent everybody else to stop that. These are not OSes, they are OverSpyingSystems, actually. And I'm pretty sure there were not any cases they removed some functionality, which can't be replaced with new one, and did that just because of some security concerns at least for cases where end users were not NSA or something closely related to business info.

[ghost]

@immibis Yes, but I don't see how is it related to topic. We already came to opinion we need to make http clientside. That's some security. You can't be secure using lua. Actually, you can't be secure even not using lua, ... what that security even is? You can't get it anyway.

[immibis]

@BoggLog "You can't be secure using lua" <- what?

[AbigailBuccaneer]

@BoggLog you seem to be saying "we need to make http clientside" as if that's a trivial task. It's not, and nobody seems to be rushing to implement it. It'll require a lot of careful thought as to how synchronising between the client and the server will work. Making HTTP clientside is a separate issue that won't just happen by magic because you wave your hands and yell about it.

[ghost]

@immibis I mean if you just play gmod and join any servers you already are insecure, because any smart kid can attack you using some lua. And if it's not some kid... you can't be 100% secure even in closed metal room with your pc disconnected from internet and running from generator xD There are sooo many vectors of attack...

@AbigailBuccaneer Hm, I thought it's maybe not trivial but not so hard to implement. Am I wrong? Anyways, I'm ready to help, to discuss, and to write it myself as far as I can. I'll look into it. Let's make a separate issue then.

[TomyLobo]

@BoggLog "Some security holes exist in gmod, therefore we should not fix our security holes." - did I sum up your argument correctly?

[ghost]

@TomyLobo "You can just leave your pack of money (whatever) on the crowded street, or pack it to some nicely locked case, but result is the same for you". There are some things you just can't fix, until you haven't fixed people. So the only thing you can do is to teach them. And you know already, I'm all for making http clientside. I'll make that issue btw, we're already talking too much off-topic on it.

[TomyLobo]

In both cases, it's my fault that I lost the money, since I left it on the street.

In your analogy, we give server admins jackets with holes in the pockets and we're not fixing them after being made aware of them.

[ghost]

@TomyLobo yes, yours - user's. It's coming from solutions you use: your hardware, router, internet provider, software... a lot of layers of software. It's all like crowded street - you can't take much control of it. ... uh, all that analogies... it's becoming somewhat phylosophycal xD We can have a talk in tox (do u have it?) if you want. Or add me on steam, i'm Bogg_[RUS] It's still not much related to "E2 extension menu with first-run" topic xD

[TomyLobo]

How can you hope to hold on to your money with holes in your pockets?

[oldmud0]

Do we have to lock this issue as well?