Re: [Rd] hasNA() / anyNA()?
I don't know of one.
Ideally, instead of a specifc function anyNA() function, any() could be
perhaps be extended to any(x, FUN) where FUN returns a logical for an
element of x, and implemented to find the 1st instance as you suggest.
Mike
On 8/13/07, Henrik Bengtsson <[EMAIL PROTECTED]> wrote:
>
> Hi,
>
> is there a hasNA() / an anyNA() function in R? Of course,
>
> hasNA <- function(x) {
> any(is.na(x));
> }
>
> would do, but that would scan all elements in 'x' and then do the
> test. I'm looking for a more efficient implementation that returns
> TRUE at the first NA, e.g.
>
> hasNA <- function(x) {
> for (kk in seq(along=x)) {
> if (is.na(x[kk]))
> return(TRUE);
> }
> FALSE;
> }
>
> Cheers
>
> Henrik
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Advice on parsing / overriding function calls
Hi,
I am trying to tighten file I/O security on a process that passes a
user-supplied script to R CMD Batch. Broadly speaking, I'd like to restrict
I/O to a designated path on the file system. Right now, I'm trying to
address this in the R environment by forcing the script to use modified
versions of scan, read.table, sys.load.image, etc.
I can run a replace string on the user-supplied script so that, for example,
"scan(" is replaced by "safe.scan("
e.g.
> SafePath <- function(file)
{fp<-strsplit(file,"/");paste("safepath",fp[[1]][length(fp[[1]])],sep="/")}
> SafePath("/etc/passwd")
[1] "safepath/passwd"
> Safe.scan <- function(file, ...) scan(SafePath(file),...)
> Safe.scan("/etc/passwd",what="",sep="\n")
Error in file(file, "r") : unable to open connection
In addition: Warning message:
cannot open file 'safepath/passwd', reason 'No such file or directory'
I'd appreciate any critique of this approach. Is there something more
effective or elegant?
Regards,
Mike
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Advice on parsing / overriding function calls
Thanks for your note Hadley,
I would like to defend against a broad range of malicious activity, but the
focus of this module is to restrict file I/O to a specific area on the file
system. I agree that's it's impossible to prevent, but I'm trying to
increase the difficulty level.
The user is inhibited from installing or loading packages, calling eval, or
any file I/O functions directly. Their script is checked to against a
relatively long list of banned commands. I'm intending to run this check after
swapping calls to I/O functions to my safer versions. I think it would be
easy for the script to remove or modify my replacement functions, but not so
easy to modify them to something harmful.
I really do appreciate the critique, but I'm especially looking for advice
to improve on this.
Regards,
Mike
On 8/16/07, hadley wickham <[EMAIL PROTECTED]> wrote:
>
> What are you trying to defend against? A serious attacker could still
> use rm/assign/get/eval/... to circumvent your replaced functions. I
> think it would be very difficult (if not impossible) to prevent this
> from happening), especially if the user can load packages.
>
> Hadley
>
> On 8/16/07, Michael Cassin <[EMAIL PROTECTED]> wrote:
> > Hi,
> >
> > I am trying to tighten file I/O security on a process that passes a
> > user-supplied script to R CMD Batch. Broadly speaking, I'd like to
> restrict
> > I/O to a designated path on the file system. Right now, I'm trying to
> > address this in the R environment by forcing the script to use modified
> > versions of scan, read.table, sys.load.image, etc.
> >
> > I can run a replace string on the user-supplied script so that, for
> example,
> > "scan(" is replaced by "safe.scan("
> >
> > e.g.
> >
> > > SafePath <- function(file)
> >
> {fp<-strsplit(file,"/");paste("safepath",fp[[1]][length(fp[[1]])],sep="/")}
> > > SafePath("/etc/passwd")
> > [1] "safepath/passwd"
> >
> > > Safe.scan <- function(file, ...) scan(SafePath(file),...)
> > > Safe.scan("/etc/passwd",what="",sep="\n")
> > Error in file(file, "r") : unable to open connection
> > In addition: Warning message:
> > cannot open file 'safepath/passwd', reason 'No such file or directory'
> >
> > I'd appreciate any critique of this approach. Is there something more
> > effective or elegant?
> >
> > Regards,
> > Mike
> >
> > [[alternative HTML version deleted]]
> >
> > __
> > R-devel@r-project.org mailing list
> > https://stat.ethz.ch/mailman/listinfo/r-devel
> >
>
>
> --
> http://had.co.nz/
>
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Advice on parsing / overriding function calls
Thanks everyone for these comments, they're great. I see the exposure
points and your collective comments have given me a lot to think about.
Eventually, I will need a "sandbox" solution. I think I'll be needing help,
and if there are any freelancers interested in discussing offline, please
contact me. Hopefully that doesn't violate posting guidelines ;)
Thanks again, all.
Best regards, Mike
On 8/16/07, Prof Brian Ripley <[EMAIL PROTECTED]> wrote:
>
> On Thu, 16 Aug 2007, Simon Urbanek wrote:
>
> > Thinking along these lines, we actually have a mechanism for
> > replacing the system call (it's used by the Mac GUI to allow root
> > calls) and one could think of expanding this to all critical
> > operations. Clearly, there are issues (speed for example), but it
> > would be nice to have a 'fortified' version of R that allows turing
> > on restrictions. I don't think it's easy, but given the rising demand
> > (at least in my perception), it would be interesting to see how far
> > we can get.
> >
> > Re filtering strings in commands - I don't think this will work,
> > because you can compute on the language, so you can construct
> > arbitrary calls without using the names in verbatim, so it is
> > possible to circumvent such filters fairly easily.
>
> Exactly. All I would need is access to a file() connection, and I could
> easily do that in such a way that 'file' never appeared in the script.
> And I've thought of half a dozen backdoors that have not been mentioned in
> this thread.
>
> I am not sure there is really much point in trying to fortify R, when
> that's the OS's job and it may well be better to run R in a suitable
> sandbox. Certainly I think that is the solution for web services.
>
> One area where it may be necessary is embedded applications. Certainly if
> R is embedded into the same process (which is how R as an shlib or DLL is
> usually used) then you may want the main application to have privileges
> you do not give to the embedded R. But using a separate process (e.g. via
> Rserve) may be more secure.
>
> >
> > Cheers,
> > Simon
> >
> > On Aug 16, 2007, at 9:23 AM, Hin-Tak Leung wrote:
> >
> >> Well, I think there are some serious use e.g. offering a web server
> >> for script uploaded then downloading the Rout result back...
> >>
> >> The issue is more about whether he wants to limit *all* file system
> >> access or just limiting to certain areas. For the former,
> >> I would set up a chroot jail and run R from within; for the latter,
> >> I would probably do something with LD_LIBRARY_PRELOAD to override
> >> all the file system accessing functions in libc directly, really.
> >> That would fix the problem with system(rm) and some such, I think,
> >> because if your entire R process and any sub-process R launches has no
> >> access to the genuine libc fwrite/fread/etc functions you cannot do
> >> any demage, right?
> >> Both are tricky and take time to do (the chroot jail a bit easier,
> >> actually...), but quite do-able.
> >>
> >> It depends on (1) how paranoid you are, (2) how much trouble you
> >> want to
> >> have for yourself to achieve those restrictions...
> >>
> >> hadley wickham wrote:
> >>> What are you trying to defend against? A serious attacker could
> >>> still
> >>> use rm/assign/get/eval/... to circumvent your replaced functions. I
> >>> think it would be very difficult (if not impossible) to prevent this
> >>> from happening), especially if the user can load packages.
> >>>
> >>> Hadley
> >>>
> >>> On 8/16/07, Michael Cassin <[EMAIL PROTECTED]> wrote:
> >>>> Hi,
> >>>>
> >>>> I am trying to tighten file I/O security on a process that passes a
> >>>> user-supplied script to R CMD Batch. Broadly speaking, I'd like
> >>>> to restrict
> >>>> I/O to a designated path on the file system. Right now, I'm
> >>>> trying to
> >>>> address this in the R environment by forcing the script to use
> >>>> modified
> >>>> versions of scan, read.table, sys.load.image, etc.
> >>>>
> >>>> I can run a replace string on the user-supplied script so that,
> >>>> for example,
> >>>> "scan(" is replaced by "safe.scan("
> >>>>
> >>>> e.g.
> >>>>
> >>>&g
