Advertisement
Guest User

Untitled

a guest
Dec 12th, 2019
386
Never
Not a member of Pastebin yet? Sign Up, it unlocks many cool features!
  1. Hi,
  2.  
  3. I've been working with erlang/elixir for the past year and I really miss
  4. SECCOMP like features in the BEAM. So I started an implementation based on
  5. https://github.com/erlang/otp and I wanted to know what you people think about
  6. it.
  7.  
  8. The idea is to provide a way to blacklist/whitelist function calls on a
  9. process level, so for example if I'm evaluating human input for a calculation,
  10. I can guarantee that no other function except the ones that are necessary are
  11. called. Going further, in a case where my erlang cookie is leaked, I know
  12. that only a limited set of functions are callable using rpc or node.spawn/2.
  13.  
  14. The way I envision it (and I'm implementing it) is adding a byte to the
  15. process struct with the following meaning:
  16.  
  17. 0 1 2 3 4 5 6 7
  18. +-+-+-+-+-+-+-+-+
  19. |E|M|S|I|U|U|U|U|
  20. +-+-+-+-+-+-+-+-+
  21.  
  22. Where:
  23. E -> Whether the mechanism is active (0:Off/1:On)
  24. M -> Operation Mode (0:Whitelist/1:Blacklist)
  25. S -> Disable Spawn (0:Can spawn new process/1:Cannot spawn new process)
  26. I -> Whether a child process will inherit the
  27. U -> Unused
  28.  
  29. There are some implicit rule in this byte:
  30. - M,S, and I are unused whether E is set to 0
  31. - I is unused if S is set to 1
  32.  
  33. I choosed to use a byte because bitwise operation are cheap and are the least
  34. expensive way I could think, and bitmasks can be combined in a meaningful way.
  35.  
  36. The verification of this byte would occur at the apply function, so we can
  37. check the byte every time a function is called. To know which function is
  38. whitelisted/blacklisted I added an Eterm to the process struct. This Eterm is a
  39. NIL terminated list of tuples, each tuple contains two atoms representing the
  40. module name and the function name which is whitelisted/blacklisted.
  41.  
  42. Probably a hashmap, or a binary tree of hashs would be quicker to search.
  43. But I don't know if there is any good low level way to introduce it without
  44. adding a lot of code to the code base.
  45.  
  46. To implement process inherit capabilites, I added a verification on spawn,
  47. but there are some possible bypasses that would need to be treated latter on.
  48.  
  49. For example:
  50.  
  51. -------------------------------------------------------------------------------
  52.  
  53. If there is a process running as a dynamic supervisor (P1), some other
  54. process (P2) may send a message to spawn some worker (P5) and the father
  55. process would be the supervisor (P1), which may not have the mechanism active.
  56.  
  57. Diagram below:
  58.  
  59.  
  60. | |
  61. | P1 - Dynamic Supervisor | P2 (With active mechanism)
  62. V |
  63. =============== |
  64. | P3 | P4 V
  65. V V
  66.  
  67. When P2 asks P1 to spawn a new worker, the diagram will look like the
  68. following:
  69.  
  70.  
  71. | |
  72. | P1 - Dynamic Supervisor | P2 (With active mechanism)
  73. V |
  74. =============== |
  75. | P3 | P4 | P5 V
  76. V V V
  77.  
  78. Where P3, P4, and P5 are spawned with P1 as a parent, so it will not inherit
  79. any rules from P2. At this point P5 can execute any code and send a message to
  80. P2, bypassing the mechanism.
  81.  
  82. -------------------------------------------------------------------------------
  83.  
  84. On another case a process (P1) on Node 1 which is under this mechanism may
  85. spawn another process (P2) to Node 2, and then P1 spawns another process (P3)
  86. on Node 1. If process generated by spawns of other nodes are less secure than
  87. the process that called the spawn function, it will lead to privilege
  88. escalation.
  89.  
  90. Diagram below:
  91.  
  92. +---------------+ +---------------+
  93. | | | |
  94. | Node 1 | | Node 2 |
  95. | | | |
  96. | P1 | spawn/2 | |
  97. | ------------> -------------> --------+ |
  98. | calls | | | |
  99. | | | | P2 |
  100. | | | | |
  101. | P3 | spawn/2 | calls | |
  102. | <---------- <------------- <---------+ |
  103. | | | |
  104. +---------------+ +---------------+
  105.  
  106. If P3 restrictions are less strict than P1, then P1 escalated privilege.
  107.  
  108. -------------------------------------------------------------------------------
  109.  
  110. The code that I'm working is at https://github.com/Supitto/OTP/tree/maint
  111. and it is built upon the maint branch. It still quite imature and have some
  112. edges to trim (I'm still figthing with allocations and Eterms). But if this
  113. idea is apreciated I will implement everything on the main branch. Also if
  114. you can think of some other scenario where this mechanism is defeated, please
  115. infome me :D
  116.  
  117. Thanks,
  118.  
  119. Henrique Almeida Marcomini
  120.  
  121. Telegram -> @supitto
  122. IRC (freenode) -> Supitto
  123.  
  124. Ps. The code on the repo may be not working (depends on the commit), but the
  125. idea is there.
  126.  
  127. Pps. I made everything in ASCII so to see it properly use monospace fonts
Advertisement
RAW Paste Data Copied
Advertisement