We have been thinking a bit about this, and privacy and security on
Mer should in our opinion follow a few basic principles (I'll only
relate to technical matters, and not get into e.g., ethical and legal
areas):
Openness
========
Developers should be able to take full responsibility of their own
devices. This includes the ability to replace any component of the
privacy and security system, as well as of Mer itself, while potentially
accepting drawbacks, related to those components, such the loss of
access to third-party services. This will enable developers to
experiment, and make the extension of the system in ways that have not
yet been foreseen possible.
Hardware Independence
=====================
While the privacy and security mechanisms should be able to take
advantage of underlying hardware security mechanisms, for example for
secure storage of cryptographic keys, electronic, one-time-write fuses,
or hard-ware-implemented cryptographic algorithms, such as ARM
Trustzone, or Intel TXT, it should not be dependent on such. I.e. the
system should function also without, even though it may have drawbacks.
Service Provider Independence
=============================
While the integration of services from 3rd-parties makes the system
ultimately (more) useful, e.g. providing network connectivity, mobile
payment functionality, etc., privacy and security must not depend on a
specific provider, but should instead provide abstract interfaces that
can be implemented to work with specific service instances.
Developer Support
=================
Developers should be able to focus on the implementation of the intended
business functionality of their applications, and should not be hindered
by security measures unless absolutely necessary. The approach should
take this into account, and the development process should provide tools
to make security measures as transparent to developers as possible,
e.g., by providing automated tools.
Extensibility & Flexibility
===========================
The security mechanism should support adding new credentials and rules
when needed. It should impose as little overhead as possible, both at
development time and run time. Applications that need no access to
protected services or resources should have zero security-related
overhead. When protections are needed, it should be possible to add them
by means of configuring the security mechanism, without requiring source
code changes in applications.
The access control system should be extensible, for example to be able
to use environmental data such as location, time and external network
visibility as input (e.g., the requirement to enter a security lock code
or a PIN code to perform operations can be relaxed in safe locations
like home or workplace).
Essentials
==========
Being based on Linux, a Unix derivative, Mer should use basic Linux
security mechanisms. Additions should be kept to the absolute minimum,
required to implement the use-cases described below, and be limited to
upstream components.
Resource Consumption
====================
Mer is targeted for mobile devices with limited resources, such as
power, storage, or processing. Any privacy and security system should
not require unduly resources, or otherwise impair system performance
excessively.
I would also suggest that we initially limit ourselves to a few use-cases:
1. Malware Resistance
=====================
The system shall be able to securely store the data of the user and
prevent unauthorized access to third parties, such as malware, or
unauthorized remote access. The system shall also be able to protect
communication with other devices. It shall be possible to specify
repositories from which it is possible to install applications.
Access to critical functionality listed below must be limited to
specific applications and must be visually indicated to the user:
- phone-calls
- messaging
- data-connections
2. Mobile Payments
==================
The system shall provide security mechanisms that enable the user to
make financial transactions with third-party services, such as content,
or "In-App" purchases. This may include a sufficiently secure execution
environment for applications, originating from such service providers
3. Mitigation of Offline-Attacks
================================
If the system is not running, data access shall not be possible. In
order to access data on the device, the system must be properly started
and be fully operational.
Further use-cases should be documented, so they can be taken into
account, and implemented later-on.
Based on these principles, and the three use-cases, I would suggest an
approach that is based on
* Discretionary Access Control, i.e., traditional, file-based ownership
and DAC bits, and the verification of group assignments during startup,
while limiting the modification of groups to specific applications, such
as the installer.
* systemd, which is already used by Mer, as common app-launcher, since
it provides all necessary interfaces that can be used to enforce system
security. Specifically, systemd is able to sufficiently evaluate the
context, in which an application should be started, taking into account
issues such as the application- (supplementary group-) id,
environment-variables, the process-tree, the location of binaries and
libraries in the file-system, including mount-points, device-ids, links,
etc.
Binaries that are executed by other binaries should only be able to
inherit their parents context and access rights.
* (partial) file-system encryption system, such as dm-crypt / LUKS,
Crypto-FS, or Enc-FS. The selection of keys should be left to the user /
developer, and be based on hardware, as well as user-provided data.
Ciao,
Michael P.
On 12/12/2012 01:30 PM, Denis Zalevskiy wrote:
> Johan Paul <[email protected]> writes:
>
>> From an app developer's PoV the security system shouldn't be any more
>> difficult than what Android, iOS or Windows Phone provide; in the end some
>> configuration file deployed along side the app where the developer
>> announces what privileges (s)he needs. It should be up to the user to allow
>> or disallow this.
>>
>> Aeges was horrible from the developer's PoV and it also got in the way of
>> the user.
>>
>
> aegis also suffers from bad design and implementation solutions (issues
> with scripting, overall complexity, security holes, NIH parts), bad
> reputation of solutions based on it (e.g. unreliable, slow and dangerous
> dpkg-wrapper) and absence of reliable maintainers.
>
> Brief and readable review of linux kernel security support can be found
> here https://lwn.net/Articles/517384/.
>
> Basically for cryptography Mer can use QCA, it allows to use
> misc. backends.
>
> There are multiply MAC solutions, some useful links and reviews:
>
> http://en.wikipedia.org/wiki/Linux_Security_Modules
> http://tomoyo.sourceforge.jp/wiki-e/?WhatIs#comparison
>
> SELinux is ordinary considered as very advanced and relatively complex
> solution while it is actively maintained and used in e.g. RedHat/Fedora
>
> AppArmor is used by Canonical in Ubuntu, maintained by 'em, relatively simple
>
> Tomoyo ressembles AppArmor (same path-based rules)
>
> Nor AppArmor, nor Tomoyo do not need fs xattrs
>
> MeeGo used SMACK for it I do not know is anybody maintaining it. Also,
> SMACK requires userland programs modification (still ?)
>
> Tomoyo has successor: http://caitsith.sourceforge.jp/,
> rationale http://i-love.sakura.ne.jp/tomoyo/CaitSith-en.pdf
>
> here one can find how chackra linux project going to choose MAC
> solutions: http://chakra-project.org/bbs/viewtopic.php?id=5185
>
> Comparision (y.2009) between selinux, grsecurity, apparmor in a good
> style (features, pros&cons):
> http://www.cyberciti.biz/tips/selinux-vs-apparmor-vs-grsecurity.html
>
> apparmor vs selinux comparison:
> http://elinux.org/images/3/39/SecureOS_nakamura.pdf
>
> - denis
>
>
>>
>> --
>> Johan
>>
>>
>>
>> On Tue, Dec 11, 2012 at 11:32 PM, Hillel Lubman <[email protected]> wrote:
>>
>>> The problem with Aegis was inability to actually fully control it even
>>> when user had super privileges (sudo). This took away control from the user
>>> to those who were able to sign the binaries. While in theory something like
>>> Aegis can be good (i.e. granular security for various aspects), in the end,
>>> user should be able to take control over it or override it when needed
>>> (given that user escalated access rights with something like sudo and etc.).
>>>
>>> Hillel.
>>>
>>>
>>>
>>> On Tue, Dec 11, 2012 at 4:24 PM, Jussi Sainio <[email protected]> wrote:
>>>
>>>> On 11.12.2012, at 15.51, David Greaves wrote:
>>>>
>>>>> It is about time we started to discuss security and privacy in the Mer
>>>> context.
>>>>>
>>>>> Mer is aimed at device vendors and there will be different concepts and
>>>>> implementations of security technologies in the layers above (and
>>>> below) Mer.
>>>>>
>>>>> Given the initial set of builds on Mer includes Nemo, Plasma Active and
>>>> now
>>>>> Sailfish I think it makes sense to include issues around "apps" as well
>>>> as
>>>>> things like network access or data encryption.
>>>>>
>>>>> Rather than re-invent their wheels I'll ask if we have any thoughts or
>>>>> requirements from our downstreams already?
>>>>
>>>> Great! I think this is a very important issue. It pays to look around for
>>>> existing solutions and gather the best things from various worlds, and then
>>>> some. Here are some thoughts I discussed about on #jollamobile today,
>>>> further elaborated:
>>>>
>>>>
>>>> Apps, User point of view:
>>>>
>>>> If a random app is downloaded from a random source, it must not be let to
>>>> fetch contacts or photos directly. The user must be aware of this and asked
>>>> beforehand. Then, it's the fine art of choosing a usable level what should
>>>> be asked and how often. I think the level on iOS is about right for most
>>>> users, "This app wants to use your photos/contacts/calendar/location
>>>> [Allow] [Don't allow]". (Methinks there could be even an [Advanced...]
>>>> button.) Also, it was discussed on the IRC channel that the Android
>>>> solution "Allow all/none at install time" is a very inadequate level.
>>>>
>>>> As suggested on the IRC channel, "the trick is not to stand in the way of
>>>> the user, but to stand in the way of the data octopuses". If the user
>>>> trusts an app for good, they must be able to give (and remove) permanent
>>>> permissions for it. Therefore, there must be a 'registry' which takes into
>>>> account what right have already been given to a specific app. Then you can
>>>> do basic "always allow" or "ask me every time" kind of stuff.
>>>>
>>>> While the Android "Allow all/none" solution is "rubbish", Android
>>>> documents do provide some insightful aspects (and also technical solutions)
>>>> that have to be taken into account [1].
>>>>
>>>>
>>>> Apps, Technical point of view:
>>>>
>>>> Regarding the filesystem, I think that one clean solution would put all
>>>> private data under a specific unix group/ACL privilege. When an app wants
>>>> to use something from a private data directory (such as calendar, photos,
>>>> contacts), it must ask for increased ACL privileges to read that
>>>> directory/file. This solution would still allow nice and clean filesystem
>>>> access for the user (all privileges in a terminal, for example), but when
>>>> an app is launched, by default, some of the permissions are dropped before
>>>> exec()ing the binary, and then they are later granted by the user or by the
>>>> registry via a library.
>>>>
>>>> It was suggested on the channel that Unix credentials are not enough. I
>>>> agree, that not everything is a file on Unix anymore, so a credential
>>>> system has to give rights other aspects to the system as well, such as TCP
>>>> sockets and "make a call over GSM". These have to be thought out, what is
>>>> the best practice to achieve this without making developer's (and user's)
>>>> life too annoying.
>>>>
>>>> It was also suggested on the channel that Nokia/MeeGo Aegis should be
>>>> fairly close solution. In my opinion, Aegis design seems to be fairly
>>>> complex. I'm not an expert on Aegis, so it might have its inner beauty that
>>>> I don't comprehend. I'm not sure if Aegis is open source, at least I
>>>> couldn't find the source code quickly. Unlike in the stock Harmattan Aegis
>>>> configuration, user access to true, full root privileges should not be
>>>> restricted. But at least the documentation gives some pointers, what was
>>>> taken into account in MeeGo. [2]
>>>>
>>>>
>>>> Data encryption:
>>>>
>>>> I think most data should be encrypted, inaccessible after a boot-up,
>>>> encrypted using a device pass code (if used). As default, a lock screen
>>>> should ask this same pass code, but it does not necessarily have to drop
>>>> the encryption key from memory, to allow programs to use their data while
>>>> running in background.
>>>>
>>>> If multi-user is to be supported, then the user's pass codes should be
>>>> able to unlock the device.
>>>>
>>>>
>>>> Refs:
>>>>
>>>> [1] http://source.android.com/tech/security/
>>>> [2]
>>>> http://harmattan-dev.nokia.com/docs/library/html/guide/html/Developer_Library_Developing_for_Harmattan_Harmattan_security.html
>>>>
>>>> Cheers,
>>>> --jussi
>>>>
>>>>
>>>
>
>
