You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The "postscript" protocol conveys read/write access to the user's console environment by executing an arbitrary script provided by the delegated notion executable in the user's console environment. If there are any places where this access is granted to untrusted code (such as via notion exec), that access could potentially be leaked to the untrusted code.
I'm not sure how much damage can be done with full access to the console's environment, but we shouldn't ever give more privileges than necessary.
I believe we should be able to lock this down by only using the protocol when the wrapper script detects that the command is activate or deactivate, which are the only commands that require this access. We should also document in those commands that they must never invoke untrusted code since they have increased env privileges.
This should have the additional benefit of shaving some boot time latency off, since generating the random bits for the postscript variable takes time, which we can limit to only the (off-the-beaten-path) activate/deactivate commands.
If we want a bit more paranoia, we could add extra logic to any commands that call untrusted code to censor the NOTION_POSTSCRIPT environment variable first. (I doubt that should affect measurable performance.)
The text was updated successfully, but these errors were encountered:
The "postscript" protocol conveys read/write access to the user's console environment by executing an arbitrary script provided by the delegated
notion
executable in the user's console environment. If there are any places where this access is granted to untrusted code (such as vianotion exec
), that access could potentially be leaked to the untrusted code.I'm not sure how much damage can be done with full access to the console's environment, but we shouldn't ever give more privileges than necessary.
I believe we should be able to lock this down by only using the protocol when the wrapper script detects that the command is
activate
ordeactivate
, which are the only commands that require this access. We should also document in those commands that they must never invoke untrusted code since they have increased env privileges.This should have the additional benefit of shaving some boot time latency off, since generating the random bits for the postscript variable takes time, which we can limit to only the (off-the-beaten-path)
activate
/deactivate
commands.If we want a bit more paranoia, we could add extra logic to any commands that call untrusted code to censor the
NOTION_POSTSCRIPT
environment variable first. (I doubt that should affect measurable performance.)The text was updated successfully, but these errors were encountered: