command line options

Moderators: Klaus, FourthWorld, heatherlaine, kevinmiller, LCMark

mwieder
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 2641
Joined: Mon Jan 22, 2007 7:36 am
Location: Berkeley, CA, US
Contact:

Re: command line options

Post by mwieder » Sat Nov 09, 2013 1:06 am

I just caught the prweb announcement about the rollout to China. I think I want to re-emphasize the bit about needing the -files secureMode command line option for standalones. We've had a decade to be pretty lax about security and malware implications, and I think it's time to put some serious thought into it.

monte
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 1558
Joined: Fri Jan 13, 2012 1:47 am
Contact:

Re: command line options

Post by monte » Sat Nov 09, 2013 9:51 pm

I'm not really sure why we would worry about what a LC app can do compared to other apps. It seems to me it's really up to the OS to sandbox an app like this.

However as I said on the dev list what about a callback to the object that set the secureMode whenever some stack tries to do something like this? It could even have an option to allow the code to execute if you wanted to allow access to specific directories.

Code: Select all

on secureModeAccess pStack,pAccesType,pPath
  put specialFolderPath("support")&"/MyApp/log.txt" into tLog
  switch pAccesType
      case "file"
         if pPath is tLog then return "allow"
        -- allow writing files to the desktop
         get specialFolderPath("desktop")
         if char 1 to the number of chars of it of pPath is it then return "allow"
         break
     case "process"
         
         break
      case "registry"
          
         break
   end switch
    -- if we get here then log
    if tLog is not among the lines of the openFiles then
        open file tLog for text append
    end if
    write the internet date & tab & pAccesType & tab & pPath & cr after tLog
end secureModeAccess
LiveCode User Group on Facebook : http://FaceBook.com/groups/LiveCodeUsers/

LCMark
Livecode Staff Member
Livecode Staff Member
Posts: 961
Joined: Thu Apr 11, 2013 11:27 am

Re: command line options

Post by LCMark » Sun Nov 10, 2013 1:02 pm

I just caught the prweb announcement about the rollout to China. I think I want to re-emphasize the bit about needing the -files secureMode command line option for standalones. We've had a decade to be pretty lax about security and malware implications, and I think it's time to put some serious thought into it.
I'm not really sure why we would worry about what a LC app can do compared to other apps. It seems to me it's really up to the OS to sandbox an app like this.
I think I have to agree with @monte here (I've not had a chance to read the thread on the dev-list). I don't think '-files' offers any real protection because you have to know about it, you have to know the executable was built using LiveCode, and applications have to be designed to work with it. Given that you can do 'nasty' things with a simple perl / bash / ruby / <insert your favourite programming language which is run from the shell and can take a script as a parameter here> script, I'm not sure that LIveCode should be considered any differently. (Perhaps it should be linux/mac/windows that supplies a 'sandbox' shell command which runs the following command in a protected space - thus not relying on the veracity of any such implementation in a specific application).
However as I said on the dev list what about a callback to the object that set the secureMode whenever some stack tries to do something like this? It could even have an option to allow the code to execute if you wanted to allow access to specific directories.
I think in the first instance we perhaps need secureHosts / secureFolders - I do like the message idea though, although it does mean potentially need thinking about whether we need a new class of 'message that is always sent regardless of whether lockMessages is in force, and regardless of whether you are in a non-dispatching wait or not'... (The other issue with sending messages is that script can execute wait - and things that call wait internally - which can cause problems due to the jumps needed between system and script threads on some platforms).

mwieder
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 2641
Joined: Mon Jan 22, 2007 7:36 am
Location: Berkeley, CA, US
Contact:

Re: command line options

Post by mwieder » Sun Nov 10, 2013 7:28 pm

@runrevmark: regarding perl/ bash / ruby etc, I'm not concerned with scripts per se, but with standalone apps. And that goes for the callback message approach as well - I'm not thinking of something that can be scripted into an application, but rather forensics that can be applied to a standalone application.

The point about needing to know an application was built with LiveCode is well taken, but I don't get the "applications have to be designed to work with it" part. What I'm suggesting is an analog of secureMode that can be invoked from a commandline argument to a standalone application and that will prevent and log attempts to do file/network actions. Some of the objections you raise might well be placed as "why do we even have secureMode at all?"

LCMark
Livecode Staff Member
Livecode Staff Member
Posts: 961
Joined: Thu Apr 11, 2013 11:27 am

Re: command line options

Post by LCMark » Mon Nov 11, 2013 11:29 am

regarding perl/ bash / ruby etc, I'm not concerned with scripts per se, but with standalone apps. And that goes for the callback message approach as well - I'm not thinking of something that can be scripted into an application, but rather forensics that can be applied to a standalone application.
Okay - but in what cases might you want to do that? It seems an exceptionally restrictive use-case wanting to be able to introspect on LiveCode standalone's which you know nothing about / have no control over... Even then, there are system tools that give you a great deal more information than that - e.g. strace on Linux - and are untainted by 'whatever the engine wants you to see' (or should that be - 'whatever the person who compiled the engine wants you to see'). After all, in the open-source world, a malicious app built using LiveCode could easily be built from a community version of the source with the secureMode removed, making any such 'forensic' feature useless in the case where you might want it to be useful. (I'm sure if someone's intent is malicious, then they aren't going to care too much about the GPL).
Some of the objections you raise might well be placed as "why do we even have secureMode at all?"
That certainly wasn't the intention behind my musings. The 'secureMode' feature is useful for certain situations (where an application needs to run untrusted code in stacks - although using any sandboxing abilities the OS provides would be substantially better). The thread was about eliminating command-line argument processing from the engine so that LiveCode apps have full control over them, thus I was questioning which ones actually provide any real value.

I can see value in -files in the no embedded stack case. Indeed, if we make the command-line as follows:

Code: Select all

unbuilt-standalone.exe [ -ui ] [ -files ] ( -stack <stackfile> | <stackfile> | -- )
Then anything after the third parameter would be up for grabs by the invoked stackfile (here -- would mean 'read from stdin'). This makes the command-line pristine (from the point of view of the launched stackfile) and provides a simple 'player' mode for untrusted stacks.

In the case of a built standalone I still struggle to see the value in '-files'. In the use-cases of secureMode I've seen (and indeed produced) it has always been a case of a master / slave situation. A master application has need to run untrusted stacks for various reasons, the master application launches a built standalone which establishes an environment (and potentially a line of communication with the master) and then locks down to secureMode; after the lock down the user stack is launched. (The LiveCode player was like this, as was the web-plugin... Also I've seen systems that allow extensions using LiveCode stacks run like this, and the built standalone that launches the user add-on provides an API environment to communicate with the host application). This is what I meant by 'apps need to be designed to work with it'.

Of course, the have-your-cake-and-eat-it solution is to have flags set at standalone build time for both -ui and -files... i.e. Always run in -ui mode / Never run in -ui mode / Use -ui command line argument; Always run in -files mode / Never run in -files mode / Use -files command line argument. In the always / never case the argument would not be processed, in the other cases it would (indeed, the app could even choose what the argument should be called).

mwieder
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 2641
Joined: Mon Jan 22, 2007 7:36 am
Location: Berkeley, CA, US
Contact:

Re: command line options

Post by mwieder » Mon Nov 11, 2013 6:14 pm

After all, in the open-source world, a malicious app built using LiveCode could easily be built from a community version of the source with the secureMode removed, making any such 'forensic' feature useless in the case where you might want it to be useful.
Ouch. OK - that's a pretty convincing argument.

mwieder
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 2641
Joined: Mon Jan 22, 2007 7:36 am
Location: Berkeley, CA, US
Contact:

Re: command line options

Post by mwieder » Mon Nov 11, 2013 6:41 pm

I built the feature-cmdlinestack branch and I see this when launched from the command line:

[23331] image rep cache hit for file /Users/ianmacphail/workspace/livecode/github/runrev-livecode/ide-svn/Toolset/resources/community/ideSkin/logo.png

I'm not sure why a cache hit is being registered for a file on Ian's machine.

LCMark
Livecode Staff Member
Livecode Staff Member
Posts: 961
Joined: Thu Apr 11, 2013 11:27 am

Re: command line options

Post by LCMark » Mon Nov 11, 2013 7:32 pm

@mwieder: That just means that an image somewhere in the ide has that as its filename property (before its set to the appropriate community / commercial image based on license type). The 'cache-hit' in this case means 'there is an imagerep with that filename in the cache', rather than 'there is an image file with that filename in the cache'. The rep's cache on filename, with the actual data being loaded and resolved upon demand. The message is generated from the various MCLog statements in the image-rep code, which only get compiled in when built for 'debug' mode.

mwieder
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 2641
Joined: Mon Jan 22, 2007 7:36 am
Location: Berkeley, CA, US
Contact:

Re: command line options

Post by mwieder » Mon Nov 11, 2013 7:55 pm

OK - thanks. That makes sense. I didn't really think I was accessing Ian's machine.
And loading a stack from the command line seems to be working fine.

MaxV
Posts: 1442
Joined: Tue May 28, 2013 2:20 pm
Location: Italy
Contact:

Re: command line options

Post by MaxV » Fri Dec 13, 2013 1:07 pm

I'm not a experienced developer, but to build Livecode from source, a command line Livecode is needed to create some .cpp source files.
I'm trying to build Livecode, but the old livecode in prebuilt directory (Revolution.lnx) now creates incorrect .cpp source files, and Livecode 6.5 doesn't work by command line, so how can you build Livecode?
Livecode Wiki: http://livecode.wikia.com
My blog: http://livecodeitalia.blogspot.it
To post code use this: http://tinyurl.com/ogp6d5w

FourthWorld
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 5610
Joined: Sat Apr 08, 2006 7:05 am
Location: Los Angeles
Contact:

Re: command line options

Post by FourthWorld » Fri Dec 13, 2013 2:47 pm

@mwieder: I just added a new tool in the Stacks section of RevNet called "4W SecureRunner", which provides a UI for easily setting the securityPermissions before running a (potentially questionable) stack.

In the IDE see Development->Plugins->GoRevNet

In testing it I've found the IDE sometimes acts odd when the securityPermissions are too restrictive, esp. when you try to quit. You may need to force quit. If you feel I should add a button to quit the IDE I'd consider it (we can probably do that safely with "lockmessages;quit"), and any other suggestions are welcome.

Not the same as the CLI options you're looking for, but hopefully handy.
Richard Gaskin
Community volunteer LiveCode Community Liaison

LiveCode development, training, and consulting services: Fourth World Systems: http://FourthWorld.com
LiveCode User Group on Facebook : http://FaceBook.com/groups/LiveCodeUsers/

Simon
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 3900
Joined: Sat Mar 24, 2007 2:54 am
Location: Palo Alto

Re: command line options

Post by Simon » Sat Dec 14, 2013 3:20 am

Wicked!
Thanks Richard, I've been looking for this.

Simon
I used to be a newbie but then I learned how to spell teh correctly and now I'm a noob!

FourthWorld
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 5610
Joined: Sat Apr 08, 2006 7:05 am
Location: Los Angeles
Contact:

Re: command line options

Post by FourthWorld » Sat Dec 14, 2013 4:59 am

Simon wrote:Wicked!
Thanks Richard, I've been looking for this.
You're welcome, Simon, but truth be told all I did was through some buttons on a card. The real work - and seriously wicked inventiveness - was Mark Waddingham's work.

He took a look at a bug report against secureMode, and what we got out of that was stellar: secureMode is now super-secure, and for less restrictive fine-tuning of security permissions he added a new property: the securityPermissions.

But he didn't even stop there: in order for us to know what options are available (there may concievably be more in the future) he also added a securityCategories function.

He did a bang-up job on this, opening all sorts of doors for client software running stacks over the Internet, more securely than any browser.
Richard Gaskin
Community volunteer LiveCode Community Liaison

LiveCode development, training, and consulting services: Fourth World Systems: http://FourthWorld.com
LiveCode User Group on Facebook : http://FaceBook.com/groups/LiveCodeUsers/

Simon
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 3900
Joined: Sat Mar 24, 2007 2:54 am
Location: Palo Alto

Re: command line options

Post by Simon » Sat Dec 14, 2013 5:14 am

Has there been any movement on your secureFolder?
It's got my vote.

Simon
I used to be a newbie but then I learned how to spell teh correctly and now I'm a noob!

FourthWorld
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 5610
Joined: Sat Apr 08, 2006 7:05 am
Location: Los Angeles
Contact:

Re: command line options

Post by FourthWorld » Sat Dec 14, 2013 7:15 am

Simon wrote:Has there been any movement on your secureFolder?
None yet. There was some discussion about it here a while back, but then other things happened and it got moved behind securePermissions (which is more important anyway, IMO). Hopefully there will be some renewed interest in it. I believe the combination of securePermissions with at least some local cache store is the optimal way forward for many learning solutions.
Richard Gaskin
Community volunteer LiveCode Community Liaison

LiveCode development, training, and consulting services: Fourth World Systems: http://FourthWorld.com
LiveCode User Group on Facebook : http://FaceBook.com/groups/LiveCodeUsers/

Post Reply

Return to “Engine Contributors”