Re: knitr and Sweave security (private round 2)
... Let's move the discussion to the devel list ... Jean-Marc Lasgouttes wrote: Le 21/12/2012 11:32, Scott Kostyshak a écrit : On Fri, Dec 21, 2012 at 5:07 AM, Liviu Andronic landronim...@gmail.com wrote: I would suggest that we _always_ have a warning when, after opening a LyX file, the user activates a dangerous converter for the _1st time_. It shouldn't be possible to don't ask me again. The logic of this would be that the warning is sufficiently intrusive to catch the attention of casual or hardcore users of the dangerous converter, but it is not intrusive enough to become a pain for those hardcore users: The warning will pop up only once, when first trying to compile a file. On the 2nd compilation this warning will be disabled, etc. If the user closes and re-opens the file, the 1st time activation-of-dangerous-converter warning should pop up again. This is a good suggestion; I didn't think about this possibility. I'm guessing that most users will find it too intrusive (although much less than if it popped up on every compilation). I personally would be fine with this though. I would personnally find it too intrusive... No strong opinions, but from the proposals I find the most convenient: 1. add 'dangerous' flag in converter(s) as proposed by JMarc 2. config option to disable warnings. 3. pop-up with warning after file opening - it can be even without don't ask me again, but there should be information 'You can disable these warnings in Preferences'. This way we assure that people really read the whole message without blind clicking and yet we offer possibility for geeks not to be obtrused. No opinion about some icons in status bar. Pavel
Re: knitr and Sweave security (private round 2)
On 12/21/2012 06:28 AM, Pavel Sanda wrote: ... Let's move the discussion to the devel list ... Jean-Marc Lasgouttes wrote: Le 21/12/2012 11:32, Scott Kostyshak a écrit : On Fri, Dec 21, 2012 at 5:07 AM, Liviu Andronic landronim...@gmail.com wrote: I would suggest that we _always_ have a warning when, after opening a LyX file, the user activates a dangerous converter for the _1st time_. It shouldn't be possible to don't ask me again. The logic of this would be that the warning is sufficiently intrusive to catch the attention of casual or hardcore users of the dangerous converter, but it is not intrusive enough to become a pain for those hardcore users: The warning will pop up only once, when first trying to compile a file. On the 2nd compilation this warning will be disabled, etc. If the user closes and re-opens the file, the 1st time activation-of-dangerous-converter warning should pop up again. This is a good suggestion; I didn't think about this possibility. I'm guessing that most users will find it too intrusive (although much less than if it popped up on every compilation). I personally would be fine with this though. I would personnally find it too intrusive... No strong opinions, but from the proposals I find the most convenient: 1. add 'dangerous' flag in converter(s) as proposed by JMarc 2. config option to disable warnings. 3. pop-up with warning after file opening - it can be even without don't ask me again, but there should be information 'You can disable these warnings in Preferences'. This way we assure that people really read the whole message without blind clicking and yet we offer possibility for geeks not to be obtrused. I think we need two kinds of disabling options: global, and per file. Otherwise, too many people will be tempted to disable globally, only because they do not want to be warned every time they open a certain sort of file. My suggestion was that the per-file disabling should be done on the basis of a per-user UUID we generate at installation, or some such time (and, as Scott suggests, can re-generate if need be). This is not perfect. If someone had your UUID, they could put that into the file, etc. But it would be better than disabling globally. If it didn't seem good enough, there are more complicated things we could do. E.g., calculate a hash of the file contents each time we save it, and then encode that hash using a per-user key. Then if the file were externally modified, you'd get warned again, and no-one would be able to send you files marked as safe for you. Richard
Re: knitr and Sweave security (private round 2)
Le 21/12/2012 16:23, Richard Heck a écrit : My suggestion was that the per-file disabling should be done on the basis of a per-user UUID we generate at installation, or some such time (and, as Scott suggests, can re-generate if need be). This is not perfect. If someone had your UUID, they could put that into the file, etc. But it would be better than disabling globally. I think that weak security can be worse that no security in some cases. JMarc
Re: knitr and Sweave security (private round 2)
On 12/21/2012 10:33 AM, Jean-Marc Lasgouttes wrote: Le 21/12/2012 16:23, Richard Heck a écrit : My suggestion was that the per-file disabling should be done on the basis of a per-user UUID we generate at installation, or some such time (and, as Scott suggests, can re-generate if need be). This is not perfect. If someone had your UUID, they could put that into the file, etc. But it would be better than disabling globally. I think that weak security can be worse that no security in some cases. I agree. In that case, we'd need the other idea. rh
Re: knitr and Sweave security (private round 2)
On Fri, Dec 21, 2012 at 10:23 AM, Richard Heck rgh...@lyx.org wrote: My suggestion was that the per-file disabling should be done on the basis of a per-user UUID we generate at installation, or some such time (and, as Scott suggests, can re-generate if need be). This is not perfect. If someone had your UUID, they could put that into the file, etc. But it would be better than disabling globally. If it didn't seem good enough, there are more complicated things we could do. E.g., calculate a hash of the file contents each time we save it, I wonder if we could skip some of the hash calculations by only calculating storing the hash each time we close a file or save a *new* file? and then encode that hash using a per-user key. Then if the file were externally modified, you'd get warned again, and no-one would be able to send you files marked as safe for you. Why would we have to encode the hash? Is this for the case that it's possible to have two documents produce the same hash or even if that weren't possible this would be desired? And all of this would not create a cost for most users because the hash would only be calculated if the knitr or Sweave module or the gnuplot template is enabled. Is that right? Scott
Re: knitr and Sweave security (private round 2)
... Let's move the discussion to the devel list ... Jean-Marc Lasgouttes wrote: > Le 21/12/2012 11:32, Scott Kostyshak a écrit : >> On Fri, Dec 21, 2012 at 5:07 AM, Liviu Andronic>> wrote: >>> I would suggest that we _always_ have a warning when, after opening a >>> LyX file, the user activates a dangerous converter for the _1st time_. >>> It shouldn't be possible to "don't ask me again". The logic of this >>> would be that the warning is sufficiently intrusive to catch the >>> attention of casual or hardcore users of the dangerous converter, but >>> it is not intrusive enough to become a pain for those hardcore users: >>> The warning will pop up only once, when first trying to compile a >>> file. On the 2nd compilation this warning will be disabled, etc. If >>> the user closes and re-opens the file, the 1st time >>> activation-of-dangerous-converter warning should pop up again. >> >> This is a good suggestion; I didn't think about this possibility. I'm >> guessing that most users will find it too intrusive (although much >> less than if it popped up on every compilation). I personally would be >> fine with this though. > > I would personnally find it too intrusive... No strong opinions, but from the proposals I find the most convenient: 1. add 'dangerous' flag in converter(s) as proposed by JMarc 2. config option to disable warnings. 3. pop-up with warning after file opening - it can be even without don't ask me again, but there should be information 'You can disable these warnings in Preferences'. This way we assure that people really read the whole message without blind clicking and yet we offer possibility for geeks not to be obtrused. No opinion about some icons in status bar. Pavel
Re: knitr and Sweave security (private round 2)
On 12/21/2012 06:28 AM, Pavel Sanda wrote: ... Let's move the discussion to the devel list ... Jean-Marc Lasgouttes wrote: Le 21/12/2012 11:32, Scott Kostyshak a écrit : On Fri, Dec 21, 2012 at 5:07 AM, Liviu Andronicwrote: I would suggest that we _always_ have a warning when, after opening a LyX file, the user activates a dangerous converter for the _1st time_. It shouldn't be possible to "don't ask me again". The logic of this would be that the warning is sufficiently intrusive to catch the attention of casual or hardcore users of the dangerous converter, but it is not intrusive enough to become a pain for those hardcore users: The warning will pop up only once, when first trying to compile a file. On the 2nd compilation this warning will be disabled, etc. If the user closes and re-opens the file, the 1st time activation-of-dangerous-converter warning should pop up again. This is a good suggestion; I didn't think about this possibility. I'm guessing that most users will find it too intrusive (although much less than if it popped up on every compilation). I personally would be fine with this though. I would personnally find it too intrusive... No strong opinions, but from the proposals I find the most convenient: 1. add 'dangerous' flag in converter(s) as proposed by JMarc 2. config option to disable warnings. 3. pop-up with warning after file opening - it can be even without don't ask me again, but there should be information 'You can disable these warnings in Preferences'. This way we assure that people really read the whole message without blind clicking and yet we offer possibility for geeks not to be obtrused. I think we need two kinds of "disabling" options: global, and per file. Otherwise, too many people will be tempted to disable globally, only because they do not want to be warned every time they open a certain sort of file. My suggestion was that the per-file disabling should be done on the basis of a per-user UUID we generate at installation, or some such time (and, as Scott suggests, can re-generate if need be). This is not perfect. If someone had your UUID, they could put that into the file, etc. But it would be better than disabling globally. If it didn't seem good enough, there are more complicated things we could do. E.g., calculate a hash of the file contents each time we save it, and then encode that hash using a per-user key. Then if the file were externally modified, you'd get warned again, and no-one would be able to send you files marked as safe for you. Richard
Re: knitr and Sweave security (private round 2)
Le 21/12/2012 16:23, Richard Heck a écrit : My suggestion was that the per-file disabling should be done on the basis of a per-user UUID we generate at installation, or some such time (and, as Scott suggests, can re-generate if need be). This is not perfect. If someone had your UUID, they could put that into the file, etc. But it would be better than disabling globally. I think that weak security can be worse that no security in some cases. JMarc
Re: knitr and Sweave security (private round 2)
On 12/21/2012 10:33 AM, Jean-Marc Lasgouttes wrote: Le 21/12/2012 16:23, Richard Heck a écrit : My suggestion was that the per-file disabling should be done on the basis of a per-user UUID we generate at installation, or some such time (and, as Scott suggests, can re-generate if need be). This is not perfect. If someone had your UUID, they could put that into the file, etc. But it would be better than disabling globally. I think that weak security can be worse that no security in some cases. I agree. In that case, we'd need the other idea. rh
Re: knitr and Sweave security (private round 2)
On Fri, Dec 21, 2012 at 10:23 AM, Richard Heckwrote: > My suggestion was that the per-file disabling should be done on the basis of > a per-user UUID we generate at installation, or some such time (and, as > Scott suggests, can re-generate if need be). This is not perfect. If someone > had your UUID, they could put that into the file, etc. But it would be > better than disabling globally. > > If it didn't seem good enough, there are more complicated things we could > do. E.g., calculate a hash of the file contents each time we save it, I wonder if we could skip some of the hash calculations by only calculating & storing the hash each time we close a file or save a *new* file? > and > then encode that hash using a per-user key. Then if the file were externally > modified, you'd get warned again, and no-one would be able to send you files > marked as safe for you. Why would we have to encode the hash? Is this for the case that it's possible to have two documents produce the same hash or even if that weren't possible this would be desired? And all of this would not create a cost for most users because the hash would only be calculated if the knitr or Sweave module or the gnuplot template is enabled. Is that right? Scott
Re: knitr and Sweave security
Scott Kostyshak wrote: knitr (and thus knitr through LyX) will not work out of the box with R. The user would have to install the package. I think that Sweave is a different story because it comes with R so I think that the user would not have to do anything else in order to be on the bad end of a harmful .lyx file. Richard, what is your opinion? Pavel
Re: knitr and Sweave security
Scott Kostyshak wrote: > knitr (and thus knitr through LyX) will not work out of the box with > R. The user would have to install the package. > I think that Sweave is a different story because it comes with R so I > think that the user would not have to do anything else in order to be > on the bad end of a harmful .lyx file. Richard, what is your opinion? Pavel
Re: knitr and Sweave security
Le 21/10/2012 03:51, Scott Kostyshak a écrit : I do not see knitr and Sweave security discussed anywhere. The Customization guide has 5 paragraphs on security regarding external templates. It is a difficult problem indeed. I do not see a better solution that marking some converters dangerous and asking people whether they really intend to use this converter (we can record the answer with the existing mechanism). JMarc
Re: knitr and Sweave security
Le 21/10/2012 08:54, Liviu Andronic a écrit : If scripts are detected then a dialogue pops up with a warning and asks the user how to proceed. This should provide a minimum of security. It is not really scripts that are used on editing like in office, but rather dangerous converters. JMarc
Re: knitr and Sweave security
Scott Kostyshak wrote: Any thoughts as far as improving security, warning the user, or documentation? Up to this moment we were trying not to include anything which could be used in the exec(rm -rf /) way (this was the only reason why gnuplot is not supported by lyx for example, there was working patch already). I didn't check your example but IIRC we used some special parameter for latex which forbids such security flaws - can you check whether your example really works? knitr/sweave stuff went in without anyone knowing it... IMHO we should either disable this by default or ask for the first time. If we have working mechanism how to notify the user, we can include gnuplot support as well. Pavel
Re: knitr and Sweave security
On Mon, Oct 22, 2012 at 12:24 PM, Pavel Sanda sa...@lyx.org wrote: Scott Kostyshak wrote: Any thoughts as far as improving security, warning the user, or documentation? Up to this moment we were trying not to include anything which could be used in the exec(rm -rf /) way (this was the only reason why gnuplot is not supported by lyx for example, there was working patch already). I didn't check your example but IIRC we used some special parameter for latex which forbids such security flaws - can you check whether your example really works? The example I made was for knitr/Sweave and that works. You are right that \write18 is disabled by default. The latex (pdflatex) - pdf (pdflatex) must be changed to pdflatex -shell-escape $$i and then it works. This is good. knitr/sweave stuff went in without anyone knowing it... IMHO we should either disable this by default or ask for the first time. If we have working mechanism how to notify the user, we can include gnuplot support as well. As annoying as an extra dialog would be, I think we should have one in this case. I think that if people know that the knitr or Sweave module is enabled in a document then the burden is on them to realize that there could potentially be malicious code inside. By ask for the first time do you mean ask for the first time that each document is open or ask for the first time that the module is used anywhere? I'm not sure what most people would prefer. I would prefer that on every new document I open, if it has the Sweave/knitr module enabled, I am notified (with an option of turning such notifications off permanently). Scott
Re: knitr and Sweave security
Scott Kostyshak wrote: You are right that \write18 is disabled by default. Fine, I'm happy to hear this. I would prefer that on every new document I open, if it has the Sweave/knitr module enabled, I am notified (with an option of turning such notifications off permanently). Yes. And would be nice nice if we have some general solution, so its easy to re-use it in other cases. Pavel
Re: knitr and Sweave security
On Mon, Oct 22, 2012 at 3:54 PM, Pavel Sanda sa...@lyx.org wrote: Scott Kostyshak wrote: You are right that \write18 is disabled by default. Fine, I'm happy to hear this. I would prefer that on every new document I open, if it has the Sweave/knitr module enabled, I am notified (with an option of turning such notifications off permanently). Yes. And would be nice nice if we have some general solution, so its easy to re-use it in other cases. That would be nice. I could look into this but not for a while. I don't think adding a warning to branch would be possible anyway because of the string freeze. So now the question is what to do for 2.0.5? Scott
Re: knitr and Sweave security
Scott Kostyshak wrote: Yes. And would be nice nice if we have some general solution, so its easy to re-use it in other cases. That would be nice. I could look into this but not for a while. I don't think adding a warning to branch would be possible anyway because of the string freeze. So now the question is what to do for 2.0.5? Thats call for Richard. Does the problem arise with vanilla LyX or do I need install specfic packages for knitr/sweave? (sorry never used this stuff...) Pavel
Re: knitr and Sweave security
On Mon, Oct 22, 2012 at 5:31 PM, Pavel Sanda sa...@lyx.org wrote: Scott Kostyshak wrote: Yes. And would be nice nice if we have some general solution, so its easy to re-use it in other cases. That would be nice. I could look into this but not for a while. I don't think adding a warning to branch would be possible anyway because of the string freeze. So now the question is what to do for 2.0.5? Thats call for Richard. Does the problem arise with vanilla LyX or do I need install specfic packages for knitr/sweave? (sorry never used this stuff...) To make a patch I don't think you would need to have R and knitr/Sweave installed. The patch would have to do with warning that a module is enabled, not with what that module actually does. But if you want to confirm that there is a problem (that you can run shell commands from within a knitr/Sweave chunk), then you need to have R installed. Sweave comes with R and knitr can be installed with a simple install.packages('knitr') within R. Let me know if you want instructions on this. Scott
Re: knitr and Sweave security
Scott Kostyshak wrote: But if you want to confirm that there is a problem (that you can run shell commands from within a knitr/Sweave chunk), then you need to have R installed. Sweave comes with R and knitr can be installed with a simple install.packages('knitr') within R. Let me know if you want instructions on this. I mean if I'm average user who have installed lyx without any specific packages (or maybe R for completely different purposes) and someone send me specially crafted .lyx file with harmful code will it work out of the box when loading and typesetting or do I need to setup some specific stuff WRT knitr before? Pavel
Re: knitr and Sweave security
On Mon, Oct 22, 2012 at 7:41 PM, Pavel Sanda sa...@lyx.org wrote: Scott Kostyshak wrote: But if you want to confirm that there is a problem (that you can run shell commands from within a knitr/Sweave chunk), then you need to have R installed. Sweave comes with R and knitr can be installed with a simple install.packages('knitr') within R. Let me know if you want instructions on this. I mean if I'm average user who have installed lyx without any specific packages (or maybe R for completely different purposes) and someone send me specially crafted .lyx file with harmful code will it work out of the box when loading and typesetting or do I need to setup some specific stuff WRT knitr before? knitr (and thus knitr through LyX) will not work out of the box with R. The user would have to install the package. I think that Sweave is a different story because it comes with R so I think that the user would not have to do anything else in order to be on the bad end of a harmful .lyx file. Scott
Re: knitr and Sweave security
Le 21/10/2012 03:51, Scott Kostyshak a écrit : I do not see knitr and Sweave security discussed anywhere. The Customization guide has 5 paragraphs on security regarding external templates. It is a difficult problem indeed. I do not see a better solution that marking some converters "dangerous" and asking people whether they really intend to use this converter (we can record the answer with the existing mechanism). JMarc
Re: knitr and Sweave security
Le 21/10/2012 08:54, Liviu Andronic a écrit : If scripts are detected then a dialogue pops up with a warning and asks the user how to proceed. This should provide a minimum of security. It is not really scripts that are used on editing like in office, but rather dangerous converters. JMarc
Re: knitr and Sweave security
Scott Kostyshak wrote: > Any thoughts as far as improving security, warning the user, or documentation? Up to this moment we were trying not to include anything which could be used in the exec("rm -rf /") way (this was the only reason why gnuplot is not supported by lyx for example, there was working patch already). I didn't check your example but IIRC we used some special parameter for latex which forbids such security flaws - can you check whether your example really works? knitr/sweave stuff went in without anyone knowing it... IMHO we should either disable this by default or ask for the first time. If we have working mechanism how to notify the user, we can include gnuplot support as well. Pavel
Re: knitr and Sweave security
On Mon, Oct 22, 2012 at 12:24 PM, Pavel Sandawrote: > Scott Kostyshak wrote: >> Any thoughts as far as improving security, warning the user, or >> documentation? > > Up to this moment we were trying not to include anything which could be used > in > the exec("rm -rf /") way (this was the only reason why gnuplot is not > supported > by lyx for example, there was working patch already). I didn't check your > example but IIRC we used some special parameter for latex which forbids such > security flaws - can you check whether your example really works? The example I made was for knitr/Sweave and that works. You are right that \write18 is disabled by default. The latex (pdflatex) -> pdf (pdflatex) must be changed to pdflatex -shell-escape $$i and then it works. This is good. > knitr/sweave stuff went in without anyone knowing it... IMHO we should either > disable this by default or ask for the first time. > > If we have working mechanism how to notify the user, we can include gnuplot > support as well. As annoying as an extra dialog would be, I think we should have one in this case. I think that if people know that the knitr or Sweave module is enabled in a document then the burden is on them to realize that there could potentially be malicious code inside. By "ask for the first time" do you mean ask for the first time that each document is open or ask for the first time that the module is used anywhere? I'm not sure what most people would prefer. I would prefer that on every new document I open, if it has the Sweave/knitr module enabled, I am notified (with an option of turning such notifications off permanently). Scott
Re: knitr and Sweave security
Scott Kostyshak wrote: > You are right > that \write18 is disabled by default. Fine, I'm happy to hear this. > I would prefer that on every > new document I open, if it has the Sweave/knitr module enabled, I am > notified (with an option of turning such notifications off > permanently). Yes. And would be nice nice if we have some general solution, so its easy to re-use it in other cases. Pavel
Re: knitr and Sweave security
On Mon, Oct 22, 2012 at 3:54 PM, Pavel Sandawrote: > Scott Kostyshak wrote: >> You are right >> that \write18 is disabled by default. > > Fine, I'm happy to hear this. > >> I would prefer that on every >> new document I open, if it has the Sweave/knitr module enabled, I am >> notified (with an option of turning such notifications off >> permanently). > > Yes. And would be nice nice if we have some general solution, > so its easy to re-use it in other cases. That would be nice. I could look into this but not for a while. I don't think adding a warning to branch would be possible anyway because of the string freeze. So now the question is what to do for 2.0.5? Scott
Re: knitr and Sweave security
Scott Kostyshak wrote: > > Yes. And would be nice nice if we have some general solution, > > so its easy to re-use it in other cases. > > That would be nice. I could look into this but not for a while. I > don't think adding a warning to branch would be possible anyway > because of the string freeze. So now the question is what to do for > 2.0.5? Thats call for Richard. Does the problem arise with vanilla LyX or do I need install specfic packages for knitr/sweave? (sorry never used this stuff...) Pavel
Re: knitr and Sweave security
On Mon, Oct 22, 2012 at 5:31 PM, Pavel Sandawrote: > Scott Kostyshak wrote: >> > Yes. And would be nice nice if we have some general solution, >> > so its easy to re-use it in other cases. >> >> That would be nice. I could look into this but not for a while. I >> don't think adding a warning to branch would be possible anyway >> because of the string freeze. So now the question is what to do for >> 2.0.5? > > Thats call for Richard. > Does the problem arise with vanilla LyX or do I need install specfic > packages for knitr/sweave? (sorry never used this stuff...) To make a patch I don't think you would need to have R and knitr/Sweave installed. The patch would have to do with warning that a module is enabled, not with what that module actually does. But if you want to confirm that there is a problem (that you can run shell commands from within a knitr/Sweave chunk), then you need to have R installed. Sweave comes with R and knitr can be installed with a simple install.packages('knitr') within R. Let me know if you want instructions on this. Scott
Re: knitr and Sweave security
Scott Kostyshak wrote: > But if you want to confirm that there is a problem (that you can run > shell commands from within a knitr/Sweave chunk), then you need to > have R installed. Sweave comes with R and knitr can be installed with > a simple install.packages('knitr') within R. Let me know if you want > instructions on this. I mean if I'm average user who have installed lyx without any specific packages (or maybe R for completely different purposes) and someone send me specially crafted .lyx file with harmful code will it work out of the box when loading and typesetting or do I need to setup some specific stuff WRT knitr before? Pavel
Re: knitr and Sweave security
On Mon, Oct 22, 2012 at 7:41 PM, Pavel Sandawrote: > Scott Kostyshak wrote: >> But if you want to confirm that there is a problem (that you can run >> shell commands from within a knitr/Sweave chunk), then you need to >> have R installed. Sweave comes with R and knitr can be installed with >> a simple install.packages('knitr') within R. Let me know if you want >> instructions on this. > > I mean if I'm average user who have installed lyx without any > specific packages (or maybe R for completely different purposes) > and someone send me specially crafted .lyx file with harmful code > will it work out of the box when loading and typesetting or > do I need to setup some specific stuff WRT knitr before? knitr (and thus knitr through LyX) will not work out of the box with R. The user would have to install the package. I think that Sweave is a different story because it comes with R so I think that the user would not have to do anything else in order to be on the bad end of a harmful .lyx file. Scott
Re: knitr and Sweave security
I learned \write18 from a quick search: http://stackoverflow.com/questions/3252957/how-to-execute-shell-script-from-latex Security problems exist in most software packages. In this case (knitr/Sweave), a pure technical solution does not seem to be possible... Sometimes I do want to execute system() commands. Regards, Yihui -- Yihui Xie xieyi...@gmail.com Phone: 515-294-2465 Web: http://yihui.name Department of Statistics, Iowa State University 2215 Snedecor Hall, Ames, IA On Sun, Oct 21, 2012 at 1:54 AM, Liviu Andronic landronim...@gmail.com wrote: On Sun, Oct 21, 2012 at 6:55 AM, Yihui Xie x...@yihui.name wrote: The blacklist-based solution can stop nothing as you showed, so I think we cannot do much except writing it in the documentation. What about an MS Excel style 'Do not execute scripts' option or dialogue? Basically we could introduce two modes when Sweave/knitr module is loaded: - Run scripts, all works as it does now. - Do not run scripts, where the scripty modules are being disabled (or similar) and some flag is being displayed somewhere, perhaps in the status bar (or the WM title bar). If scripts are detected then a dialogue pops up with a warning and asks the user how to proceed. This should provide a minimum of security. What do you think of this? Regards Liviu PS While we're on the subject of security, is it not possible to simply use LaTeX to write malicious code?
Re: knitr and Sweave security
On Sun, Oct 21, 2012 at 3:08 AM, Yihui Xie x...@yihui.name wrote: I learned \write18 from a quick search: http://stackoverflow.com/questions/3252957/how-to-execute-shell-script-from-latex I didn't know about that. Then yes, if LyX allows security problems like that from LaTeX I should not be worrying about Sweave and knitr. Here's another useful discussion http://www.texdev.net/2009/10/06/what-does-write18-mean/ And since then there are now options to enable/disable write18. See, for example http://docs.miktex.org/manual/pdftex.html --disable-write18 Disable the \write18{command} construct. But I guess this is the job of the user and depends on the LaTeX distribution installed so it's not LyX's jurisdiction. Security problems exist in most software packages. In this case (knitr/Sweave), a pure technical solution does not seem to be possible... Sometimes I do want to execute system() commands. Same here. Best, Scott Regards, Yihui -- Yihui Xie xieyi...@gmail.com Phone: 515-294-2465 Web: http://yihui.name Department of Statistics, Iowa State University 2215 Snedecor Hall, Ames, IA On Sun, Oct 21, 2012 at 1:54 AM, Liviu Andronic landronim...@gmail.com wrote: On Sun, Oct 21, 2012 at 6:55 AM, Yihui Xie x...@yihui.name wrote: The blacklist-based solution can stop nothing as you showed, so I think we cannot do much except writing it in the documentation. What about an MS Excel style 'Do not execute scripts' option or dialogue? Basically we could introduce two modes when Sweave/knitr module is loaded: - Run scripts, all works as it does now. - Do not run scripts, where the scripty modules are being disabled (or similar) and some flag is being displayed somewhere, perhaps in the status bar (or the WM title bar). If scripts are detected then a dialogue pops up with a warning and asks the user how to proceed. This should provide a minimum of security. What do you think of this? Regards Liviu PS While we're on the subject of security, is it not possible to simply use LaTeX to write malicious code?
Re: knitr and Sweave security
I learned \write18 from a quick search: http://stackoverflow.com/questions/3252957/how-to-execute-shell-script-from-latex Security problems exist in most software packages. In this case (knitr/Sweave), a pure technical solution does not seem to be possible... Sometimes I do want to execute system() commands. Regards, Yihui -- Yihui XiePhone: 515-294-2465 Web: http://yihui.name Department of Statistics, Iowa State University 2215 Snedecor Hall, Ames, IA On Sun, Oct 21, 2012 at 1:54 AM, Liviu Andronic wrote: > On Sun, Oct 21, 2012 at 6:55 AM, Yihui Xie wrote: >> The blacklist-based solution can stop nothing as you showed, so I >> think we cannot do much except writing it in the documentation. >> > What about an MS Excel style 'Do not execute scripts' option or > dialogue? Basically we could introduce two modes when Sweave/knitr > module is loaded: > - Run scripts, all works as it does now. > - Do not run scripts, where the scripty modules are being disabled (or > similar) and some flag is being displayed somewhere, perhaps in the > status bar (or the WM title bar). > > If scripts are detected then a dialogue pops up with a warning and > asks the user how to proceed. This should provide a minimum of > security. > > What do you think of this? Regards > Liviu > > PS While we're on the subject of security, is it not possible to > simply use LaTeX to write malicious code?
Re: knitr and Sweave security
On Sun, Oct 21, 2012 at 3:08 AM, Yihui Xiewrote: > I learned \write18 from a quick search: > http://stackoverflow.com/questions/3252957/how-to-execute-shell-script-from-latex I didn't know about that. Then yes, if LyX allows security problems like that from LaTeX I should not be worrying about Sweave and knitr. Here's another useful discussion http://www.texdev.net/2009/10/06/what-does-write18-mean/ And since then there are now options to enable/disable write18. See, for example http://docs.miktex.org/manual/pdftex.html --disable-write18 Disable the \write18{command} construct. But I guess this is the job of the user and depends on the LaTeX distribution installed so it's not LyX's jurisdiction. > Security problems exist in most software packages. In this case > (knitr/Sweave), a pure technical solution does not seem to be > possible... Sometimes I do want to execute system() commands. Same here. Best, Scott > Regards, > Yihui > -- > Yihui Xie > Phone: 515-294-2465 Web: http://yihui.name > Department of Statistics, Iowa State University > 2215 Snedecor Hall, Ames, IA > > > On Sun, Oct 21, 2012 at 1:54 AM, Liviu Andronic > wrote: >> On Sun, Oct 21, 2012 at 6:55 AM, Yihui Xie wrote: >>> The blacklist-based solution can stop nothing as you showed, so I >>> think we cannot do much except writing it in the documentation. >>> >> What about an MS Excel style 'Do not execute scripts' option or >> dialogue? Basically we could introduce two modes when Sweave/knitr >> module is loaded: >> - Run scripts, all works as it does now. >> - Do not run scripts, where the scripty modules are being disabled (or >> similar) and some flag is being displayed somewhere, perhaps in the >> status bar (or the WM title bar). >> >> If scripts are detected then a dialogue pops up with a warning and >> asks the user how to proceed. This should provide a minimum of >> security. >> >> What do you think of this? Regards >> Liviu >> >> PS While we're on the subject of security, is it not possible to >> simply use LaTeX to write malicious code?
knitr and Sweave security
I do not see knitr and Sweave security discussed anywhere. The Customization guide has 5 paragraphs on security regarding external templates. For example, someone could post a .lyx file asking for help that contains malicious code. I don't always check the list of modules that a document has and sometimes it might be hard to go through the entire file looking at the chunks of code (which might not stand out since they can be collapsed) before compiling. Using R's system command, one can run arbitrary commands, downloading/uploading or deleting information. In the external template support, measures are taken to restrict the access that the user has to the shell. I do not see any options that Rscript can accept to provide more security. Any thoughts as far as improving security, warning the user, or documentation? Thanks, Scott
Re: knitr and Sweave security
I do not see an obvious approach to solve this issue except documenting the potential security problem in the manual. It exists in all R-related applications, including R packages. I have seen people collecting keywords like system() and file.remove(), but that is apparently far from a perfect solution. Education is probably the only way... Regards, Yihui -- Yihui Xie xieyi...@gmail.com Phone: 515-294-2465 Web: http://yihui.name Department of Statistics, Iowa State University 2215 Snedecor Hall, Ames, IA On Sat, Oct 20, 2012 at 8:51 PM, Scott Kostyshak skost...@lyx.org wrote: I do not see knitr and Sweave security discussed anywhere. The Customization guide has 5 paragraphs on security regarding external templates. For example, someone could post a .lyx file asking for help that contains malicious code. I don't always check the list of modules that a document has and sometimes it might be hard to go through the entire file looking at the chunks of code (which might not stand out since they can be collapsed) before compiling. Using R's system command, one can run arbitrary commands, downloading/uploading or deleting information. In the external template support, measures are taken to restrict the access that the user has to the shell. I do not see any options that Rscript can accept to provide more security. Any thoughts as far as improving security, warning the user, or documentation? Thanks, Scott
Re: knitr and Sweave security
On Sat, Oct 20, 2012 at 10:18 PM, Yihui Xie x...@yihui.name wrote: I do not see an obvious approach to solve this issue except documenting the potential security problem in the manual. It exists in all R-related applications, including R packages. I have seen people collecting keywords like system() and file.remove(), but that is apparently far from a perfect solution. Education is probably the only way... You mean searching the chunk for the word system? I agree that it would be useless: first - sy second - stem do.call(paste(first,second,sep=),list(command=echo I still have access tempfile.txt)) What if knitr overrides the system function before processing the chunk? My guess is that it's not a good idea: there is probably a way around it, there are many other functions that would need to be blacklisted and overridden, and it would probably cause more bugs than security. But I wanted to throw it out there. Thanks, Scott Regards, Yihui -- Yihui Xie xieyi...@gmail.com Phone: 515-294-2465 Web: http://yihui.name Department of Statistics, Iowa State University 2215 Snedecor Hall, Ames, IA On Sat, Oct 20, 2012 at 8:51 PM, Scott Kostyshak skost...@lyx.org wrote: I do not see knitr and Sweave security discussed anywhere. The Customization guide has 5 paragraphs on security regarding external templates. For example, someone could post a .lyx file asking for help that contains malicious code. I don't always check the list of modules that a document has and sometimes it might be hard to go through the entire file looking at the chunks of code (which might not stand out since they can be collapsed) before compiling. Using R's system command, one can run arbitrary commands, downloading/uploading or deleting information. In the external template support, measures are taken to restrict the access that the user has to the shell. I do not see any options that Rscript can accept to provide more security. Any thoughts as far as improving security, warning the user, or documentation? Thanks, Scott
Re: knitr and Sweave security
The blacklist-based solution can stop nothing as you showed, so I think we cannot do much except writing it in the documentation. Regards, Yihui -- Yihui Xie xieyi...@gmail.com Phone: 515-294-2465 Web: http://yihui.name Department of Statistics, Iowa State University 2215 Snedecor Hall, Ames, IA On Sat, Oct 20, 2012 at 9:41 PM, Scott Kostyshak skost...@lyx.org wrote: You mean searching the chunk for the word system? I agree that it would be useless: first - sy second - stem do.call(paste(first,second,sep=),list(command=echo I still have access tempfile.txt)) What if knitr overrides the system function before processing the chunk? My guess is that it's not a good idea: there is probably a way around it, there are many other functions that would need to be blacklisted and overridden, and it would probably cause more bugs than security. But I wanted to throw it out there. Thanks, Scott
knitr and Sweave security
I do not see knitr and Sweave security discussed anywhere. The Customization guide has 5 paragraphs on security regarding external templates. For example, someone could post a .lyx file asking for help that contains malicious code. I don't always check the list of modules that a document has and sometimes it might be hard to go through the entire file looking at the chunks of code (which might not stand out since they can be collapsed) before compiling. Using R's "system" command, one can run arbitrary commands, downloading/uploading or deleting information. In the external template support, measures are taken to restrict the access that the user has to the shell. I do not see any options that Rscript can accept to provide more security. Any thoughts as far as improving security, warning the user, or documentation? Thanks, Scott
Re: knitr and Sweave security
I do not see an obvious approach to solve this issue except documenting the potential security problem in the manual. It exists in all R-related applications, including R packages. I have seen people collecting keywords like system() and file.remove(), but that is apparently far from a perfect solution. Education is probably the only way... Regards, Yihui -- Yihui Xie <xieyi...@gmail.com> Phone: 515-294-2465 Web: http://yihui.name Department of Statistics, Iowa State University 2215 Snedecor Hall, Ames, IA On Sat, Oct 20, 2012 at 8:51 PM, Scott Kostyshak <skost...@lyx.org> wrote: > I do not see knitr and Sweave security discussed anywhere. The > Customization guide has 5 paragraphs on security regarding external > templates. > > For example, someone could post a .lyx file asking for help that > contains malicious code. I don't always check the list of modules that > a document has and sometimes it might be hard to go through the entire > file looking at the chunks of code (which might not stand out since > they can be collapsed) before compiling. Using R's "system" command, > one can run arbitrary commands, downloading/uploading or deleting > information. > > In the external template support, measures are taken to restrict the > access that the user has to the shell. > > I do not see any options that Rscript can accept to provide more security. > > Any thoughts as far as improving security, warning the user, or documentation? > > Thanks, > > Scott
Re: knitr and Sweave security
On Sat, Oct 20, 2012 at 10:18 PM, Yihui Xie <x...@yihui.name> wrote: > I do not see an obvious approach to solve this issue except > documenting the potential security problem in the manual. It exists in > all R-related applications, including R packages. I have seen people > collecting keywords like system() and file.remove(), but that is > apparently far from a perfect solution. Education is probably the only > way... You mean searching the chunk for the word "system"? I agree that it would be useless: first <- "sy" second <- "stem" do.call(paste(first,second,sep=""),list(command="echo I still have access >> tempfile.txt")) What if knitr overrides the "system" function before processing the chunk? My guess is that it's not a good idea: there is probably a way around it, there are many other functions that would need to be blacklisted and overridden, and it would probably cause more bugs than security. But I wanted to throw it out there. Thanks, Scott > > Regards, > Yihui > -- > Yihui Xie <xieyi...@gmail.com> > Phone: 515-294-2465 Web: http://yihui.name > Department of Statistics, Iowa State University > 2215 Snedecor Hall, Ames, IA > > > On Sat, Oct 20, 2012 at 8:51 PM, Scott Kostyshak <skost...@lyx.org> wrote: >> I do not see knitr and Sweave security discussed anywhere. The >> Customization guide has 5 paragraphs on security regarding external >> templates. >> >> For example, someone could post a .lyx file asking for help that >> contains malicious code. I don't always check the list of modules that >> a document has and sometimes it might be hard to go through the entire >> file looking at the chunks of code (which might not stand out since >> they can be collapsed) before compiling. Using R's "system" command, >> one can run arbitrary commands, downloading/uploading or deleting >> information. >> >> In the external template support, measures are taken to restrict the >> access that the user has to the shell. >> >> I do not see any options that Rscript can accept to provide more security. >> >> Any thoughts as far as improving security, warning the user, or >> documentation? >> >> Thanks, >> >> Scott
Re: knitr and Sweave security
The blacklist-based solution can stop nothing as you showed, so I think we cannot do much except writing it in the documentation. Regards, Yihui -- Yihui XiePhone: 515-294-2465 Web: http://yihui.name Department of Statistics, Iowa State University 2215 Snedecor Hall, Ames, IA On Sat, Oct 20, 2012 at 9:41 PM, Scott Kostyshak wrote: > > You mean searching the chunk for the word "system"? I agree that it > would be useless: > first <- "sy" > second <- "stem" > do.call(paste(first,second,sep=""),list(command="echo I still have > access >> tempfile.txt")) > > What if knitr overrides the "system" function before processing the chunk? > My guess is that it's not a good idea: there is probably a way around > it, there are many other functions that would need to be blacklisted > and overridden, and it would probably cause more bugs than security. > But I wanted to throw it out there. > > Thanks, > > Scott