Re: [Rd] tcltk freezing using MS Windows for R-2.14+
Le mercredi 19 décembre 2012 à 16:27 +1100, Keith a écrit : Andreas, thanks so much for this clue. I have found that if I reduced the time in seconds from 0.1 to 0.01 to 0.001 to 0.0001 I only had problems with freezing on the 0.0001 time. I tested on Win7(64 bit) on an Intel core i7 870 at 2.93GHz (16GB ram)(8 cores) and a WinXP (32bit) Pentium 4 3.01GHz (2GB ram) using R-2.15.2(2012-10-26) on both. I had previously found that the tkgrab.set command seemed to be the one actually freezing so I placed the sleep command just before that with the same result as it being just after the tktoplevel command. I am now going to try it in my packages affylmGUI and limmaGUI, probably with a sleep time of 0.1 to be on the safe side, many thanks, Have you filed a bug in the R bug tracking system, as Duncan suggested you back in November? I couldn't find it. This is always useful to keep track of issues. I'm interested because I experienced freezes with my R Commander plug-in on a specific Windows 7 configuration, and I wonder whether it might indeed be related. So consider this as a me too. ;-) Regards __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] tcltk freezing using MS Windows for R-2.14+
That's great!
I will also fix oneChannelGUI.
Thanks a lot!
Raffaele
Prof. Raffaele A. Calogero
Bioinformatics and Genomics Unit
MBC Centro di Biotecnologie Molecolari
Via Nizza 52, Torino 10126
Tel. ++39 0116706457
Fax++39 0112366457
Mobile ++39 827080
email: raffaele.calog...@unito.it
raffaele.calog...@gmail.com
www: http://www.bioinformatica.unito.it
On Dec 19, 2012, at 6:27 AM, Keith ke...@wehi.edu.au wrote:
Andreas,
thanks so much for this clue.
I have found that if I reduced the time in seconds from 0.1 to 0.01 to 0.001
to 0.0001 I only had problems with freezing on the 0.0001 time.
I tested on Win7(64 bit) on an Intel core i7 870 at 2.93GHz (16GB ram)(8
cores)
and a WinXP (32bit) Pentium 4 3.01GHz (2GB ram) using R-2.15.2(2012-10-26) on
both.
I had previously found that the tkgrab.set command seemed to be the one
actually freezing
so I placed the sleep command just before that with the same result as it
being just after the tktoplevel command.
I am now going to try it in my packages affylmGUI and limmaGUI, probably with
a sleep time of 0.1 to be on the safe side,
many thanks,
Keith Satterley
On 18/12/2012 9:38 PM, Moeltner, Andreas wrote:
R Version 2.15.0/Windows XP
Maybe this will help to identify the problem (I have similar problems with
other tcltk-windows, too.)
Inserting some time delay after tktoplevel helps (on my PC):
test2GUI - function(){
require(tcltk)
MainWindow - tktoplevel()
Sys.sleep(0.1)
topMenu - tkmenu(MainWindow)
tkconfigure(MainWindow,menu=topMenu)
tkgrab.set(MainWindow)
tkfocus(MainWindow)
}
Cheers
Andreas
Andreas Möltner
__
The information in this email is confidential and inte...{{dropped:6}}
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Scanning a R script for potentially insidious commands
Hey all, We are building a R connector for our web application. The user can upload a script so it can be executed on the server. Is there a way to scan the script for insidious commands (writing on the disk for example) and purge them out? I guess a simple search is not enough so is there a way to analyse the pseudo code? Best, Etienne __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Scanning a R script for potentially insidious commands
On Dec 18, 2012, at 12:48 PM, Etienne Sévin e.se...@epiconcept.fr wrote: Hey all, We are building a R connector for our web application. The user can upload a script so it can be executed on the server. Is there a way to scan the script for insidious commands (writing on the disk for example) and purge them out? Completely, not that I know of: but grepping for system() and eval() should catch a majority of red flags. Michael I guess a simple search is not enough so is there a way to analyse the pseudo code? Best, Etienne __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Scanning a R script for potentially insidious commands
The safest way to prevent attacks using an R connector, is managing the permissions for the application on your own server. We do that with the RStudio Server application we have running. You have to take into account that R allows for many interactions with the system. Also file(), dir(), unlink() and all sys. functions have the potential to screen and possibly alter your system. Not only system() and eval() pose a security problem... How to do this exactly, depends very much on both the server and OS settings and the specific R connector you use/build. But don't count on R alone to provide safety. Cheers Joris On Wed, Dec 19, 2012 at 12:28 PM, Michael Weylandt michael.weyla...@gmail.com wrote: On Dec 18, 2012, at 12:48 PM, Etienne Sévin e.se...@epiconcept.fr wrote: Hey all, We are building a R connector for our web application. The user can upload a script so it can be executed on the server. Is there a way to scan the script for insidious commands (writing on the disk for example) and purge them out? Completely, not that I know of: but grepping for system() and eval() should catch a majority of red flags. Michael I guess a simple search is not enough so is there a way to analyse the pseudo code? Best, Etienne __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel -- Joris Meys Statistical consultant Ghent University Faculty of Bioscience Engineering Department of Mathematical Modelling, Statistics and Bio-Informatics tel : +32 9 264 59 87 joris.m...@ugent.be --- Disclaimer : http://helpdesk.ugent.be/e-maildisclaimer.php [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Scanning a R script for potentially insidious commands
On Wed, Dec 19, 2012 at 12:39:21PM +0100, Joris Meys wrote: The safest way to prevent attacks using an R connector, is managing the permissions for the application on your own server. We do that with the RStudio Server application we have running. You have to take into account that R allows for many interactions with the system. Also file(), dir(), unlink() and all sys. functions have the potential to screen and possibly alter your system. Not only system() and eval() pose a security problem... just out of curiosity, how do you disable these functions? Is there a way to blacklist functions as such in R, regardless of what name is used to call them? Simple string pattern matching (as I understand Michael's grepping suggestion below) can be circumvented by using the get function, as in s - paste(letters[i], collapse = ); f - get(s); f(insidiouscommand); where i contains suitable indices to produce system. So the system function needs disabling as such, as there are innumerable ways to code up its invocation. How to do this exactly, depends very much on both the server and OS settings and the specific R connector you use/build. But don't count on R alone to provide safety. Personally, I'd suggest to consider long and hard whether executing user submitted R code is really necessary, and if that's the case, my inclination would be to run that on a virtual machine and sandbox that as much as you can. Best regards, Jan Cheers Joris On Wed, Dec 19, 2012 at 12:28 PM, Michael Weylandt michael.weyla...@gmail.com wrote: On Dec 18, 2012, at 12:48 PM, Etienne S?vin e.se...@epiconcept.fr wrote: Hey all, We are building a R connector for our web application. The user can upload a script so it can be executed on the server. Is there a way to scan the script for insidious commands (writing on the disk for example) and purge them out? Completely, not that I know of: but grepping for system() and eval() should catch a majority of red flags. Michael I guess a simple search is not enough so is there a way to analyse the pseudo code? Best, Etienne __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel -- Joris Meys Statistical consultant Ghent University Faculty of Bioscience Engineering Department of Mathematical Modelling, Statistics and Bio-Informatics tel : +32 9 264 59 87 joris.m...@ugent.be --- Disclaimer : http://helpdesk.ugent.be/e-maildisclaimer.php [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel -- +- Jan T. Kim ---+ | email: jtt...@gmail.com| | WWW: http://www.jtkim.dreamhosters.com/ | *-= hierarchical systems are for files, not for humans =-* __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Scanning a R script for potentially insidious commands
On Wed, Dec 19, 2012 at 1:02 PM, Jan T Kim jtt...@googlemail.com wrote: On Wed, Dec 19, 2012 at 12:39:21PM +0100, Joris Meys wrote: The safest way to prevent attacks using an R connector, is managing the permissions for the application on your own server. We do that with the RStudio Server application we have running. You have to take into account that R allows for many interactions with the system. Also file(), dir(), unlink() and all sys. functions have the potential to screen and possibly alter your system. Not only system() and eval() pose a security problem... just out of curiosity, how do you disable these functions? You got me wrong: We don't disable these functions, we just don't give the R instance that's executing the file any permissions on the system. So trying to run any function that wants to access the system only results in error messages. I believe we did that by creating a specific user account and linked that to the R application behind the interface. But sandboxing (as you mentioned) is just as good. -- Joris Meys Statistical consultant Ghent University Faculty of Bioscience Engineering Department of Mathematical Modelling, Statistics and Bio-Informatics tel : +32 9 264 59 87 joris.m...@ugent.be --- Disclaimer : http://helpdesk.ugent.be/e-maildisclaimer.php [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] read.csv reads more rows than indicated by wc -l
G See gsee000 at gmail.com writes: When I have a csv file that is more than 6 lines long, not including the header, and one of the fields is blank for the last few lines, and there is an extra comma on of the lines with the blank field, read.csv() makes creates an extra line. I attached an example file; I'll also paste the contents here: A,apple A,orange A,orange A,orange A,orange A,,, A,, - wc -l reports that this file has 7 lines R system(wc -l test.csv) 7 test.csv But, read.csv reads 8. R read.csv(test.csv, header=FALSE, stringsAsFactors=FALSE) V1 V2 1 A apple 2 A orange 3 A orange 4 A orange 5 A orange 6 A 7 8 A If I increase the number of commas at the end of the line, it increases the number of rows. This R command to read a 7 line csv: read.csv(header=FALSE, text=A,apple A,orange A,orange A,orange A,orange A, A,,) will produce this: V1 V2 1 A apple 2 A orange 3 A orange 4 A orange 5 A orange 6 A 7 8 9 A But if the file has fewer than 7 lines, it doesn't increase the number of rows. This R command to read a 6 line csv: read.csv(header=FALSE, text=A,apple A,orange A,orange A,orange A, A,,) will produce this: V1 V2 V3 V4 V5 V6 1 A apple NA NA NA NA 2 A orange NA NA NA NA 3 A orange NA NA NA NA 4 A orange NA NA NA NA 5 ANA NA NA NA 6 ANA NA NA NA Is this intended behavior? Thanks, Garrett See [snip] I don't know if it's exactly *intended* or not, but I think it's more or less as [IMPLICITLY] documented. From ?read.table, The number of data columns is determined by looking at the first five lines of input (or the whole file if it has less than five lines), or from the length of ‘col.names’ if it is specified and is longer. This could conceivably be wrong if ‘fill’ or ‘blank.lines.skip’ are true, so specify ‘col.names’ if necessary (as in the ‘Examples’). txt - A,apple A,orange A,orange A,orange A,orange A, A,, read.csv(header=FALSE, text=txt ) What is happening here is that (1) read.table is determining from the first five lines that there are two columns; (2) when it gets to line six, it reads each set of two fields as a separate row If you try read.csv(header=FALSE, text=txt, fill=FALSE,blank.lines.skip=FALSE) you at least get an error. But it gets worse: txt2 - A,apple A,orange A,orange A,orange A,orange A,b,c,d,e,f A,g read.csv(header=FALSE, text=txt2, fill=FALSE,blank.lines.skip=FALSE) produces bad results even though fill=FALSE and blank.lines.skip=FALSE ... Even specifying col.names explicitly doesn't help: read.csv(header=FALSE, text=txt2, col.names=paste0(V,1:2)) At least count.fields() does detect a problem ... count.fields(textConnection(txt2),sep=,) Somewhere on my wish/TO DO list is for someone to rewrite read.table for better robustness *and* efficiency ... __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Scanning a R script for potentially insidious commands
On Dec 19, 2012, at 1:09 PM, Gabriel Becker wrote:
Simon,
I don't really have a horse in this race (as I said I didn't write sandboxR),
but it seems like if you control library (to prevent untrusted packages,
specifically including things like Rcpp and Rffi), and dyn.load the executing
arbitrary compiled code issue can be curtailed. If I'm wrong please let me
know, I'm always looking to learn.
I assume in your example was some C code you whipped up and then loaded
using one of the methods above? Or a .Call to an existing internal R function?
No, it's pure R code, I just didn't want to put the exploit on the list ...
Cheers,
S
~G
On Wed, Dec 19, 2012 at 9:12 AM, Simon Urbanek simon.urba...@r-project.org
wrote:
On Dec 19, 2012, at 11:21 AM, Gabriel Becker wrote:
See also: https://github.com/Rapporter/sandboxR
sandboxR (not written by me) is a proof of concept for security inside R
(as opposed to security outside R as discussed above) via evaluating all R
commands in a specialized security environment (R environment that is)
which contains safe replacements for blacklisted functions.
It is a good example of false security. For the reasons mentioned before this
doesn't work and can be circumvented:
sandbox(('tail /etc/group'))
_developer:*:204:
_locationd:*:205:
_carddav:*:206:
_detachedsig:*:207:
_trustevaluationagent:*:208:
_odchpass:*:209:
_timezone:*:210:
_lda:*:211:
_cvms:*:212:
_usbmuxd:*:213:
[1] 0
The problem is that you can try to plug holes (and sandboxR is trying hard to
plug a lot of them), but there will always be new ones. It's simply the wrong
approach IMHO.
Cheers,
Simon
HTH,
~G
On Wed, Dec 19, 2012 at 5:33 AM, Dirk Eddelbuettel e...@debian.org wrote:
Jeroen has a package devoted to the sandboxing approach in conjunction with
the system-level AppArmor facility: RAppArmor. See
http://cran.r-project.org/web/packages/RAppArmor/index.html
and more details at
https://github.com/jeroenooms/RAppArmor#readme
Dirk
--
Dirk Eddelbuettel | e...@debian.org | http://dirk.eddelbuettel.com
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
--
Gabriel Becker
Graduate Student
Statistics Department
University of California, Davis
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
--
Gabriel Becker
Graduate Student
Statistics Department
University of California, Davis
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Scanning a R script for potentially insidious commands
On Dec 19, 2012, at 1:10 PM, Simon Urbanek wrote:
On Dec 19, 2012, at 1:09 PM, Gabriel Becker wrote:
Simon,
I don't really have a horse in this race (as I said I didn't write
sandboxR), but it seems like if you control library (to prevent untrusted
packages, specifically including things like Rcpp and Rffi), and dyn.load
the executing arbitrary compiled code issue can be curtailed. If I'm wrong
please let me know, I'm always looking to learn.
I assume in your example was some C code you whipped up and then loaded
using one of the methods above? Or a .Call to an existing internal R
function?
No, it's pure R code, I just didn't want to put the exploit on the list ...
I just found another exploit that is harder to catch than the fist one. Both
work by giving you unrestricted access directly to any function in any
namespace or environment. The first one consists of 15 chars + the function
name, the second takes 33 characters + function name (both work on base R, no
extra packages needed). They use two entirely separate aspects of R to do it. I
don't want to make this an exploit contest, I'm just trying to make the point
that you cannot try to secure R by any kind of filtering or pre-processing,
because the language is too flexible to make you feel secure. I would strongly
discourage anyone from providing an open service that relies on filtering.
There is a fairly high probability that the will be a way around it. That's why
all realistic approaches work on the back-end.
Cheers,
Simon
~G
On Wed, Dec 19, 2012 at 9:12 AM, Simon Urbanek simon.urba...@r-project.org
wrote:
On Dec 19, 2012, at 11:21 AM, Gabriel Becker wrote:
See also: https://github.com/Rapporter/sandboxR
sandboxR (not written by me) is a proof of concept for security inside R
(as opposed to security outside R as discussed above) via evaluating all R
commands in a specialized security environment (R environment that is)
which contains safe replacements for blacklisted functions.
It is a good example of false security. For the reasons mentioned before
this doesn't work and can be circumvented:
sandbox(('tail /etc/group'))
_developer:*:204:
_locationd:*:205:
_carddav:*:206:
_detachedsig:*:207:
_trustevaluationagent:*:208:
_odchpass:*:209:
_timezone:*:210:
_lda:*:211:
_cvms:*:212:
_usbmuxd:*:213:
[1] 0
The problem is that you can try to plug holes (and sandboxR is trying hard
to plug a lot of them), but there will always be new ones. It's simply the
wrong approach IMHO.
Cheers,
Simon
HTH,
~G
On Wed, Dec 19, 2012 at 5:33 AM, Dirk Eddelbuettel e...@debian.org wrote:
Jeroen has a package devoted to the sandboxing approach in conjunction with
the system-level AppArmor facility: RAppArmor. See
http://cran.r-project.org/web/packages/RAppArmor/index.html
and more details at
https://github.com/jeroenooms/RAppArmor#readme
Dirk
--
Dirk Eddelbuettel | e...@debian.org | http://dirk.eddelbuettel.com
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
--
Gabriel Becker
Graduate Student
Statistics Department
University of California, Davis
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
--
Gabriel Becker
Graduate Student
Statistics Department
University of California, Davis
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
