Stories
Slash Boxes
Comments

SoylentNews is people

posted by n1 on Friday August 22 2014, @05:31PM   Printer-friendly
from the suggestions-are-being-monitored-for-quality-assurance-purposes dept.

PC World reports:

The U.S. National Institute of Standards and Technology (NIST) is developing a guide for testing third-party apps to ensure that they are secure and don’t introduce any vulnerabilities.

The government agency has prepared a draft of its recommendations, “Technical Considerations for Vetting 3rd Party Mobile Applications,” and is seeking industry feedback by Sept. 18. The aim is to help enterprises make full use of commercial mobile programs.

Would you like to contribute to the NIST effort?

This discussion has been archived. No new comments can be posted.
Display Options Threshold/Breakthrough Mark All as Read Mark All as Unread
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
  • (Score: 4, Insightful) by Ethanol-fueled on Friday August 22 2014, @06:45PM

    by Ethanol-fueled (2792) on Friday August 22 2014, @06:45PM (#84435) Homepage

    How about not requiring access to the camera, voice recorder, contact list, internet, SMS, browsing history, all galleries and other stored media, accelerometers, and screen contents just to run a goddamn fart app?

    • (Score: 0) by Anonymous Coward on Friday August 22 2014, @06:50PM

      by Anonymous Coward on Friday August 22 2014, @06:50PM (#84438)

      Yep, access to sensors and "pii" are included in the things they propose to check for -- their .pdf says a lot of good things (but doesn't mention any of the three letter agencies).

    • (Score: 3, Insightful) by LoRdTAW on Friday August 22 2014, @08:53PM

      by LoRdTAW (3755) on Friday August 22 2014, @08:53PM (#84479) Journal

      How else will advertisers be able to data mine our personal lives in order to monazite our data into targeted ads and sellable statistical data? Wont someone please think of the advertisers!

  • (Score: 2) by MrGuy on Friday August 22 2014, @07:07PM

    by MrGuy (1007) on Friday August 22 2014, @07:07PM (#84444)

    ...the only way to truly have secure, reliable mobile apps (or apps in general) would be to require AT LEAST the following. This list is necessary, but not sufficient (it still would allow an app that was granted access to the contacts list and the network to "phone home" with the contact list). But without a framework like this, I don't believe security is possible.

    * Every application runs in a local sandbox, with a fixed amount of memory, processing, etc. Attempts to exceed these limits crashes the app and the sandbox.
    * Applications have no direct access (and no ability to establish direct access) to anything outside the sandbox - wireless, touchscreen, microphone
    * Applications cannot have direct access to read or store information on the device outside their sandbox (except via the API - below).
    * To the extent that any application needs access to an external resource (persistent storage, microphone, display screen, etc.), this can ONLY be done through calls to specific API functions exposed by the OS. There can be additional OS API calls to extend the parameters of the "default" app sandbox if required (though the OS is also allowed to say "no.")
    * Applications cannot choose directly where in hardware they write files to or read files from - they can only be referenced by identifiers. Also, all files are tagged with the creating application - no application can read or write an application-space file it did not write (i.e. apps cannot communicate) unless explicitly delegated in the manifest (and therefore communicated to the user).
    * Every application exposes a "manifest" of the resources expects to access via the API (which its actions will be validated against).

    The OS would have responsibilities including:
    * Creating and managing application sandboxes, and approving resource requests.
    * When installing an application, scan its published manifest of API calls it expects to make, and present that information to the user.
    * Having highly secure, well-structured API calls that are well tested to not leak information, and which are checked for proper permissions before running.
    * Knowing which API calls require user approval (e.g. to access the contact list), and perform those checks.
    * Validate that no application is ever allowed to access a resource via the API that is not in the manifest (e.g. a photo-editing app requesting access to the microphone, or a game app attempts to "phone home" without advertising it needs network access).
    * Make it easy to browse the list of active applications (with active containers) - no "hidden" apps.
    * Log, analyze, and message on persistent access to resources by applications that are running but not in the foreground. Message users occasionally to advise on such usage (e.g. "application in the background has been requesting GPS coordinates and sending network messages for the last 30 minutes....")
    * Ensure application sandboxes are destroyed and their contents erased when an application exits. All that persists is the application code, and files written explicitly via the API.

    Basically, isolate the applications from being able to access anything they can use to potentially do mischief by hiding all the external resources behind an API. Then test the heck out of that API.

    I'm sure these rules would prevent certain useful applications (for example, system monitoring, antivirus, etc.) But absent a strong "isolated by default" sandboxing, I'm not sure how you can ever be sure an application is "safe" to run.

    • (Score: 2) by AnonTechie on Friday August 22 2014, @07:28PM

      by AnonTechie (2275) on Friday August 22 2014, @07:28PM (#84450) Journal

      These are good suggestions.

      --
      Albert Einstein - "Only two things are infinite, the universe and human stupidity, and I'm not sure about the former."
    • (Score: 2) by tibman on Friday August 22 2014, @07:44PM

      by tibman (134) Subscriber Badge on Friday August 22 2014, @07:44PM (#84453)

      Great ideas : )

      --
      SN won't survive on lurkers alone. Write comments.
    • (Score: 2) by c0lo on Friday August 22 2014, @10:26PM

      by c0lo (156) Subscriber Badge on Friday August 22 2014, @10:26PM (#84506) Journal

      * Every application runs in a local sandbox, with a fixed amount of memory, processing, etc. Attempts to exceed these limits crashes the app and the sandbox.

      Unfortunately, this will result in a phone/tablet nobody will use today - I suspect this resulted from the amount of resources the phone/tablet has (highly limited RAM/CPU/storage and mainly battery time, as more processing/storage grunt will necessarily needs more energy). Maybe after some years, time required for the battery technology to evolve

      I attempted to learn programming Android a while ago (gave up for the lack of time, thus I might be wrong): the very philosophy of an Android app is the app is actually something that provides services to other application, which will consume those services by registering callbacks - even the GUI of an application is written in this style, I suspect that the Android stack calls into your services and draws itself the GUI as indicated (as opposed to your app owning the GUI).
      E.g. you don't have a library to call and render the Google maps, all you do you ask the "Google map service" (running or started as a "process" on top of the Android stack) to do its job in an area of the screen you indicate and call you back with the results when the user does something.

      --
      https://www.youtube.com/watch?v=aoFiw2jMy-0 https://soylentnews.org/~MichaelDavidCrawford
    • (Score: 3, Insightful) by kaszz on Saturday August 23 2014, @01:28AM

      by kaszz (4211) on Saturday August 23 2014, @01:28AM (#84558) Journal

      Great ideas.

      But the operating system needs to be able to by user selection to deny, fake or allow access to individual resources. That way even applications that demand "give me microphone access or I will refuse to install" will loose their ability to make that demand.

      Oh, and give the user the ability to KILL any application he chooses too. Including bundled malware!

  • (Score: 3, Insightful) by tibman on Friday August 22 2014, @07:40PM

    by tibman (134) Subscriber Badge on Friday August 22 2014, @07:40PM (#84452)

    Read the entire document. The biggest hole is they do not talk about how to block automatic updates or unapproved software installs. If the whole point is to vet an app before it reaches the device then you must control the update and install mechanism. It could be permissive and just blacklist known bad applications.. at a minimum.

    Added 5 comments to their excel sheet and sent it in : )

    --
    SN won't survive on lurkers alone. Write comments.
  • (Score: 2) by kaszz on Saturday August 23 2014, @01:31AM

    by kaszz (4211) on Saturday August 23 2014, @01:31AM (#84559) Journal

    Oh that NIST that runs the NSA [epic.org] errands.. I think their trust capital is blown.