4 ms·

Five minutes might tell you there is no (eval) in the path but I don't see how thats useful.

metroholografix 6y ago
It's useful in that it demonstrates a reduced attack surface. You can immediately see that there are no command injection possibilities. Additionally, there is no potential for integer overflows, memory corruption, undefined behavior, compiler optimizing your safety checks away and so on. A parser bug in Emacs Lisp will signal an error inside Emacs which will end up in either a debugger popup buffer or a message in * Messages*. So using Emacs for IRC is pretty much the same order of bananas as using a .NET or Java client. Do you think that's bananas too?
- WhatIsDukkha 6y ago
  I wouldn't run any irc client without firejail these days... I think Emacs should change enough that thats more viable then it is today. Really you are only poking at one set of vulnerabilities anyway? Why argue for more complacency? There is plenty of that, it never needs a champion.
  - metroholografix 6y ago
    I'm not arguing against firejail, just trying to understand your threat model. Security exists on a spectrum and there are multiple trade-offs one has to think about. Do you run Python scripts that interact with the network in firejail? I've outlined areas of Emacs where exploitable vulnerabilities could lurk. But in my view, it's far from being a "bananas" situation.
    - WhatIsDukkha 6y ago
      IRC has decades of vulnerabilities and unexpected behavior atop its simple protocol. Sitting on irc with 100 channels full of randos, Emacs modules that aren't irc but also process text coming through for X or Y, misconfiguration, mime link handling, irc protocol handling, sloppy bot making "hey the builtin pretty printing for python code snippet had more implications then I anticipated", "stuff" running in emacs in between network and the irc client, add that to "noone seems to talk about or care about security issues in Emacs", yeah a big pile of risk that pretty tough to just write off, for me, to that point I think it's bananas. Especially when compared to the trivial alternative of sandboxing another client that has much less surface then a fully configured single process Emacs. You are doing what you are doing and on some level we aren't too far apart in viewing the safety of a sandboxed raw emacs+some tight set of irc+a convenient plugin X and Y vs another irc client sandboxed. But I bet you aren't doing that. I really dislike the words "threat model" in security conversations like this. Neither of us has actually done any of that formal process for this, so why ask for it?
      - metroholografix 6y ago
        Why do you dislike "threat model", it's a necessity. There can be no productive security discussion without a model present to frame and ground it in actuality. Given a determined, resourceful adversary, you're toast regardless of what you do to protect yourself. It makes sense therefore to have a realistic model and prepare accordingly. The probability that "100 channels full of randos" are going to use any of the -aspecific, hand-wavy- vectors you mentioned to defeat my security posture (which includes an IRC client written in a memory-safe language whose code I've reviewed that is masquerading through CTCP version as something else entirely) is miniscule. I can live with that but I've also spent some time to configure Emacs according to guidelines I previously mentioned and review code that I'm using and exposing to potential attacks.
- deleted 6y ago
  [deleted]

It's useful in that it demonstrates a reduced attack surface. You can immediately see that there are no command injection possibilities. Additionally, there is no potential for integer overflows, memory corruption, undefined behavior, compiler optimizing your safety checks away and so on. A parser bug in Emacs Lisp will signal an error inside Emacs which will end up in either a debugger popup buffer or a message in * Messages*. So using Emacs for IRC is pretty much the same order of bananas as using a .NET or Java client. Do you think that's bananas too?

WhatIsDukkha 6y ago
I wouldn't run any irc client without firejail these days... I think Emacs should change enough that thats more viable then it is today. Really you are only poking at one set of vulnerabilities anyway? Why argue for more complacency? There is plenty of that, it never needs a champion.
- metroholografix 6y ago
  I'm not arguing against firejail, just trying to understand your threat model. Security exists on a spectrum and there are multiple trade-offs one has to think about. Do you run Python scripts that interact with the network in firejail? I've outlined areas of Emacs where exploitable vulnerabilities could lurk. But in my view, it's far from being a "bananas" situation.
  - WhatIsDukkha 6y ago
    IRC has decades of vulnerabilities and unexpected behavior atop its simple protocol. Sitting on irc with 100 channels full of randos, Emacs modules that aren't irc but also process text coming through for X or Y, misconfiguration, mime link handling, irc protocol handling, sloppy bot making "hey the builtin pretty printing for python code snippet had more implications then I anticipated", "stuff" running in emacs in between network and the irc client, add that to "noone seems to talk about or care about security issues in Emacs", yeah a big pile of risk that pretty tough to just write off, for me, to that point I think it's bananas. Especially when compared to the trivial alternative of sandboxing another client that has much less surface then a fully configured single process Emacs. You are doing what you are doing and on some level we aren't too far apart in viewing the safety of a sandboxed raw emacs+some tight set of irc+a convenient plugin X and Y vs another irc client sandboxed. But I bet you aren't doing that. I really dislike the words "threat model" in security conversations like this. Neither of us has actually done any of that formal process for this, so why ask for it?
    - metroholografix 6y ago
      Why do you dislike "threat model", it's a necessity. There can be no productive security discussion without a model present to frame and ground it in actuality. Given a determined, resourceful adversary, you're toast regardless of what you do to protect yourself. It makes sense therefore to have a realistic model and prepare accordingly. The probability that "100 channels full of randos" are going to use any of the -aspecific, hand-wavy- vectors you mentioned to defeat my security posture (which includes an IRC client written in a memory-safe language whose code I've reviewed that is masquerading through CTCP version as something else entirely) is miniscule. I can live with that but I've also spent some time to configure Emacs according to guidelines I previously mentioned and review code that I'm using and exposing to potential attacks.
deleted 6y ago
[deleted]