Re: knitr and Sweave security (private round 2)

[Pavel Sanda]

... 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)

[Richard Heck]

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)

[Jean-Marc Lasgouttes]

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)

[Richard Heck]

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)

[Scott Kostyshak]

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)

[Pavel Sanda]

... 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)

[Richard Heck]

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 
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)

[Jean-Marc Lasgouttes]

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)

[Richard Heck]

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)

[Scott Kostyshak]

On Fri, Dec 21, 2012 at 10:23 AM, Richard Heck  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

[Pavel Sanda]

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

[Pavel Sanda]

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

[Jean-Marc Lasgouttes]

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

[Jean-Marc Lasgouttes]

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

[Pavel Sanda]

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

[Scott Kostyshak]

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

[Pavel Sanda]

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

[Scott Kostyshak]

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

[Pavel Sanda]

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

[Scott Kostyshak]

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

[Pavel Sanda]

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

[Scott Kostyshak]

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

[Jean-Marc Lasgouttes]

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

[Jean-Marc Lasgouttes]

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

[Pavel Sanda]

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

[Scott Kostyshak]

On Mon, Oct 22, 2012 at 12:24 PM, Pavel Sanda  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

[Pavel Sanda]

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

[Scott Kostyshak]

On Mon, Oct 22, 2012 at 3:54 PM, Pavel Sanda  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

[Pavel Sanda]

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

[Scott Kostyshak]

On Mon, Oct 22, 2012 at 5:31 PM, Pavel Sanda  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

[Pavel Sanda]

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

[Scott Kostyshak]

On Mon, Oct 22, 2012 at 7:41 PM, Pavel Sanda  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

[Yihui Xie]

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

[Scott Kostyshak]

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

[Yihui Xie]

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 
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?

Re: knitr and Sweave security

[Scott Kostyshak]

On Sun, Oct 21, 2012 at 3:08 AM, Yihui Xie  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 
> 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

[Scott Kostyshak]

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

[Yihui Xie]

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

[Scott Kostyshak]

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

[Yihui Xie]

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

[Scott Kostyshak]

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

[Yihui Xie]

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

[Scott Kostyshak]

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

[Yihui Xie]

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 
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  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