Re: JEP 411: sandboxing use case
Thanks to Sean and Peter for your answers (sorry, I did not manage to answer your messages because of issues with my e-mail provider so I answer mine instead). As Peter observes, putting student code in a restricted VM or container (while the grading code would be more priviledged) does not seem like a great solution. It is unclear how to make this setup reasonably secure, and it complicates the code very much as I can then no more access the student code as with running unit tests (using shared memory space and querying their objects directly from the grading code), I’d need to serialize and de-serialize everything. It seems like I don’t have any other choice than waiting for finalizers to be removed and call interception to be available. This is okay for me: I just wanted to make sure that some solution is coming. In the meantime, my application warns that I am using deprecated APIs. I believe that it is a mistaken decision from JEP 411 that I can do nothing to disable these warning. This could make my application look unprofessional to at least those advanced users that will look at those warnings, and thus, has a negative impact on me, whereas I can do nothing against that (no replacement option has been made available yet, and none is coming very soon) and it is not my fault. I know that this has been discussed here previously, and I have read the rationale for this decision, but these reasons do not justify harming Java developers’ reputation. Not that it is a very grave mistake, but I wanted to voice this concern in hope of another decision next time if similar situations happen. Le lundi 10 janvier 2022 à 15:22 +0100, Olivier Cailloux a écrit : > Dear list, > > I would like to share my use case for currently using the security > manager mechanism (SM) in my software. Now that JEP 411 is there, any > advice about any currently existing solution for replacement would be > welcome, if this is already possible; alternatively, I hope that a > replacement for these needs will be available soon. > > My software grades student work. It download their code from GitHub, > compiles it, runs it, and observe the results (similar to running > JUnit > tests, but on pluggable code). Their code is then graded > automatically > depending on the expected versus actual results. > > I currently use SM to prevent student code to alter the system on > which > the code runs or have external impact. I don’t want them to read > files > or send network requests (they usually do not need to do anything > like > this for the exercices assigned to them). I currently use a simple > “no > priviledged calls at all” configuration, where everything that can be > forbidden by SM is forbidden for their code, as they only need to be > able to deal with their own objects and classes from the JDK that > operate “taint-free” (as Chapman Flak puts it), such as classical > List > or Set structures. > > Though I do not currently need such more advanced feature, I > considered > as a good bonus that SM allowed me, if I wanted to, to give exercices > that also deal with file writing (through telling SM that their code > can access a restricted set of files). If any replacement solution > could also allow this kind of flexibility, that would be nice. > > I am aware that their code could implement a denial of service; I am > okay to live with this risk as any resulting damage would be low > (worst > case, just restart the computer). But I’d like to reduce the risk > that > their code would read or modify files or other aspects of the system > it > is running on, for example, as the resulting damage could be much > higher (such as: alter the way the system works so that the grading > of > other students, graded next, would be modified; read personal files > from the account that is running the grading software and posting > their > content on the internet; inadvertently delete files on the host > system…) > > I implement code isolation so that one student code does not see or > interact with the code of other students classical using class loader > mechanisms, for which JEP 411 does not create problems. But I ignore > how to prevent file writing, socket opening, or similar stuff, using > other means than SM. > > My needs resemble (but are not identical to) the ones exposed by > Chapman Flack in “JEP 411: Missing use-case: user functions in an > RDBMS”, https://marc.info/?m=162216583127042. I share the concern of > this poster (https://marc.info/?m=162221303911911) that it currently > seems that I’d have to come up with various, specialized mechanisms > to > prevent various kinds of operations (file system access, socket > access, …), which seems inelegant and error-prone. > > Even after reading the insightful article of Ron Pressler, Shallow > Java > Sandboxes > (https://inside.java/2021/04/23/security-and-sandboxing-post- > securitymanager/), > it is unclear to me whether I can get rid of SecurityManager with > existing Java 17
Re: JEP 411: sandboxing use case
Hi Olivier, After JEP 421 (deprecation of finalizers) and a JEP is assigned to removal of finalizers, it will be possible to instrument java methods and intercept their calls. While finalizers exist, instrumenting constructors would allow finalizer attacks to circumvent the permission check. OpenJDK has no intention of developing a new authorization framework / api. Until such time as finalizers are removed, SM is the only option currently available for authorization within the JVM. You can make a JVM process less privileged, or sandbox a JVM within a VM, but if the JVM (without SM) is able to generate a students result, then student code will also be able to. I did consider briefly the possibility of using two processes, one for the student code (isolated in an unprivileged process or VM) and one for the grading code, but I think the grading jvm would be susceptible to some form of injection attack, as it has to parse untrusted data. Be sure to disable Serialization, as SM doesn't prevent its use and any other forms of potentially dangerous data parsing. -Djdk.serialFilter=!*,\ -Dcom.sun.jndi.ldap.object.trustSerialData=false,\ Regards, Peter. On 12/01/2022 7:49 am, Sean Mullan wrote: On 1/10/22 9:22 AM, Olivier Cailloux wrote: Dear list, I would like to share my use case for currently using the security manager mechanism (SM) in my software. Now that JEP 411 is there, any advice about any currently existing solution for replacement would be welcome, if this is already possible; alternatively, I hope that a replacement for these needs will be available soon. You may want to consider container technologies. This is mentioned in the last paragraph of the Motivation section of JEP 411. --Sean My software grades student work. It download their code from GitHub, compiles it, runs it, and observe the results (similar to running JUnit tests, but on pluggable code). Their code is then graded automatically depending on the expected versus actual results. I currently use SM to prevent student code to alter the system on which the code runs or have external impact. I don’t want them to read files or send network requests (they usually do not need to do anything like this for the exercices assigned to them). I currently use a simple “no priviledged calls at all” configuration, where everything that can be forbidden by SM is forbidden for their code, as they only need to be able to deal with their own objects and classes from the JDK that operate “taint-free” (as Chapman Flak puts it), such as classical List or Set structures. Though I do not currently need such more advanced feature, I considered as a good bonus that SM allowed me, if I wanted to, to give exercices that also deal with file writing (through telling SM that their code can access a restricted set of files). If any replacement solution could also allow this kind of flexibility, that would be nice. I am aware that their code could implement a denial of service; I am okay to live with this risk as any resulting damage would be low (worst case, just restart the computer). But I’d like to reduce the risk that their code would read or modify files or other aspects of the system it is running on, for example, as the resulting damage could be much higher (such as: alter the way the system works so that the grading of other students, graded next, would be modified; read personal files from the account that is running the grading software and posting their content on the internet; inadvertently delete files on the host system…) I implement code isolation so that one student code does not see or interact with the code of other students classical using class loader mechanisms, for which JEP 411 does not create problems. But I ignore how to prevent file writing, socket opening, or similar stuff, using other means than SM. My needs resemble (but are not identical to) the ones exposed by Chapman Flack in “JEP 411: Missing use-case: user functions in an RDBMS”, https://marc.info/?m=162216583127042. I share the concern of this poster (https://marc.info/?m=162221303911911) that it currently seems that I’d have to come up with various, specialized mechanisms to prevent various kinds of operations (file system access, socket access, …), which seems inelegant and error-prone. Even after reading the insightful article of Ron Pressler, Shallow Java Sandboxes (https://inside.java/2021/04/23/security-and-sandboxing-post-securitymanager/), it is unclear to me whether I can get rid of SecurityManager with existing Java 17 technology. Any advice would be welcome. If not possible, please consider this use case when thinking about further progress in replacing the security related APIs. (I am quite worried by the wording of JEP 411 Future Work not mentioning this kind of sandboxing need.) Olivier
Re: JEP 411: sandboxing use case
On 1/10/22 9:22 AM, Olivier Cailloux wrote: Dear list, I would like to share my use case for currently using the security manager mechanism (SM) in my software. Now that JEP 411 is there, any advice about any currently existing solution for replacement would be welcome, if this is already possible; alternatively, I hope that a replacement for these needs will be available soon. You may want to consider container technologies. This is mentioned in the last paragraph of the Motivation section of JEP 411. --Sean My software grades student work. It download their code from GitHub, compiles it, runs it, and observe the results (similar to running JUnit tests, but on pluggable code). Their code is then graded automatically depending on the expected versus actual results. I currently use SM to prevent student code to alter the system on which the code runs or have external impact. I don’t want them to read files or send network requests (they usually do not need to do anything like this for the exercices assigned to them). I currently use a simple “no priviledged calls at all” configuration, where everything that can be forbidden by SM is forbidden for their code, as they only need to be able to deal with their own objects and classes from the JDK that operate “taint-free” (as Chapman Flak puts it), such as classical List or Set structures. Though I do not currently need such more advanced feature, I considered as a good bonus that SM allowed me, if I wanted to, to give exercices that also deal with file writing (through telling SM that their code can access a restricted set of files). If any replacement solution could also allow this kind of flexibility, that would be nice. I am aware that their code could implement a denial of service; I am okay to live with this risk as any resulting damage would be low (worst case, just restart the computer). But I’d like to reduce the risk that their code would read or modify files or other aspects of the system it is running on, for example, as the resulting damage could be much higher (such as: alter the way the system works so that the grading of other students, graded next, would be modified; read personal files from the account that is running the grading software and posting their content on the internet; inadvertently delete files on the host system…) I implement code isolation so that one student code does not see or interact with the code of other students classical using class loader mechanisms, for which JEP 411 does not create problems. But I ignore how to prevent file writing, socket opening, or similar stuff, using other means than SM. My needs resemble (but are not identical to) the ones exposed by Chapman Flack in “JEP 411: Missing use-case: user functions in an RDBMS”, https://marc.info/?m=162216583127042. I share the concern of this poster (https://marc.info/?m=162221303911911) that it currently seems that I’d have to come up with various, specialized mechanisms to prevent various kinds of operations (file system access, socket access, …), which seems inelegant and error-prone. Even after reading the insightful article of Ron Pressler, Shallow Java Sandboxes (https://inside.java/2021/04/23/security-and-sandboxing-post-securitymanager/), it is unclear to me whether I can get rid of SecurityManager with existing Java 17 technology. Any advice would be welcome. If not possible, please consider this use case when thinking about further progress in replacing the security related APIs. (I am quite worried by the wording of JEP 411 Future Work not mentioning this kind of sandboxing need.) Olivier
JEP 411: sandboxing use case
Dear list, I would like to share my use case for currently using the security manager mechanism (SM) in my software. Now that JEP 411 is there, any advice about any currently existing solution for replacement would be welcome, if this is already possible; alternatively, I hope that a replacement for these needs will be available soon. My software grades student work. It download their code from GitHub, compiles it, runs it, and observe the results (similar to running JUnit tests, but on pluggable code). Their code is then graded automatically depending on the expected versus actual results. I currently use SM to prevent student code to alter the system on which the code runs or have external impact. I don’t want them to read files or send network requests (they usually do not need to do anything like this for the exercices assigned to them). I currently use a simple “no priviledged calls at all” configuration, where everything that can be forbidden by SM is forbidden for their code, as they only need to be able to deal with their own objects and classes from the JDK that operate “taint-free” (as Chapman Flak puts it), such as classical List or Set structures. Though I do not currently need such more advanced feature, I considered as a good bonus that SM allowed me, if I wanted to, to give exercices that also deal with file writing (through telling SM that their code can access a restricted set of files). If any replacement solution could also allow this kind of flexibility, that would be nice. I am aware that their code could implement a denial of service; I am okay to live with this risk as any resulting damage would be low (worst case, just restart the computer). But I’d like to reduce the risk that their code would read or modify files or other aspects of the system it is running on, for example, as the resulting damage could be much higher (such as: alter the way the system works so that the grading of other students, graded next, would be modified; read personal files from the account that is running the grading software and posting their content on the internet; inadvertently delete files on the host system…) I implement code isolation so that one student code does not see or interact with the code of other students classical using class loader mechanisms, for which JEP 411 does not create problems. But I ignore how to prevent file writing, socket opening, or similar stuff, using other means than SM. My needs resemble (but are not identical to) the ones exposed by Chapman Flack in “JEP 411: Missing use-case: user functions in an RDBMS”, https://marc.info/?m=162216583127042. I share the concern of this poster (https://marc.info/?m=162221303911911) that it currently seems that I’d have to come up with various, specialized mechanisms to prevent various kinds of operations (file system access, socket access, …), which seems inelegant and error-prone. Even after reading the insightful article of Ron Pressler, Shallow Java Sandboxes (https://inside.java/2021/04/23/security-and-sandboxing-post-securitymanager/), it is unclear to me whether I can get rid of SecurityManager with existing Java 17 technology. Any advice would be welcome. If not possible, please consider this use case when thinking about further progress in replacing the security related APIs. (I am quite worried by the wording of JEP 411 Future Work not mentioning this kind of sandboxing need.) Olivier
