[LINK] RFI: Sandboxing
Roger Clarke
Roger.Clarke at xamax.com.au
Thu Jul 23 10:49:27 AEST 2015
At 9:46 +0930 23/7/15, Glen Turner wrote:
>Roger Clarke wrote:
>> 'really tight sandboxing', is an absolute must
>
>Security isn't that simple.
Very helpful, thanks Glen.
My assumption was that libraries would be stored once, managed at operating system level, and not be pre-linked into applications.
(So I guess the ridiculous sizes of applications software these days in part reflect the inclusion of masses of library-routines, some needed, most not).
Yes, run-time linking involves a downside: an application can be de-stabilised by fixes imposed on elements within libraries.
But I naively assumed that by now version-management had found its way into libraries and library-calls, such that an application could rely on being able to get access to the version of a routine that it depended on.
(As you can tell, I haven't been a developer for a very long time).
________________________
>Consider an operating system with each application in its own sandbox. Now
>let's say a linker library has a bug. We need to update that library in
>every single sandbox. In the "application shipped as a sandbox" model
>(phones, Docker) then you're relying on application authors to update
>their shipped applications, but they have little motivation to do so (they
>aren't going to see additional revenue, customers lack sufficient market
>information when purchasing the application to know how diligent the
>author is with security updates). In the non-sandboxed model an update
>from the operating system's manufacturer suffices to update all
>applications (OS authors have an expectation of future sales, and their
>performance at issuing security updates is widely reported).
>
>This shortcoming of sandboxes explains the attraction of alternative
>security mechanisms which seek to limit unauthorised access to the
>operating system (SELinux, etc). The issue there also becomes one of
>management: who is responsible for the authoring of the type enforcement
>rules (neither the application author nor the operating systems'
>manufacturer feels the cost should fall upon them)?
>
>Neither of these might give you the security you want. Sandboxes and type
>enforcement usually degenerate to protecting the operating system from
>misuse. That often doesn't do much to prevent manipulation of your data pr
>misuse of your systems resources. Sandboxed applications typically ask for
>far too much access to your data (just look at the Facebook app's landgrab
>over your phone's data) and type enforcement schemes often don't apply to
>your data at all.
>
>There's no magic bullet here, or this would be a solved problem with the
>one obviously right answer already deployed.
>
>-glen
>
>--
>Glen Turner <http://www.gdt.id.au/~gdt/>
--
Roger Clarke http://www.rogerclarke.com/
Xamax Consultancy Pty Ltd 78 Sidaway St, Chapman ACT 2611 AUSTRALIA
Tel: +61 2 6288 6916 http://about.me/roger.clarke
mailto:Roger.Clarke at xamax.com.au http://www.xamax.com.au/
Visiting Professor in the Faculty of Law University of N.S.W.
Visiting Professor in Computer Science Australian National University
More information about the Link
mailing list