Security/Multi user policy

From Tizen Wiki
Jump to: navigation, search


This document is still in draft mode. Collaborate to the discussion to improve it.

This page is inspired by the document Multi User Security Policy (proposal) transmitted by Bumjin in this mail.

Basic Principle

  • each user has its own User UID and is in the group of users;
  • system resources has predefined UID;
  • at least one user has administration rights;
  • the admin rights are:
    • install and uninstall applications;
    • create, delete user accounts;
    • manage users and applications privileges and rights;
    • update/upgrade the system;
    • erase the device (in case of property transfer).

See the discussion.

Ownership of files

According to the three domain model:

  • most files of the floor domain belongs to the user root;
  • most files of the System domain belongs to the system users;
  • most files of the User domain belongs to users.

See the discussion.

Home directories of users

  • each user has its own home directory;
  • a user home directory can't be accessed by other users;
  • the rights of the home directories should be:
    • ownership: user: the user, group: users;
    • DAC, user: rwx, group: ---, other: ---;
    • MAC, security.SMACK64=User, security.SMACK64TRANSMUTE=TRUE.

Note: the package pwdutils is applying the rules.

By default, no user can see the data of other users.

See the discussion.

Applications

The applications are either native or web runtime.

  • each application has its own package ID PKGID;
  • each application has its own Smack context:
    • user applications have the Smack context User::App::PKGID;
    • system applications have the Smack context System::App::PKGID (proposal, to be validated);
  • each application is installed by an installer;
  • each application is launched by a launcher;
  • each application runs with its own Smack context;
  • each application runs with the user id of the user that launched the application;
  • the installed files are Smack labelled with the application Smack context;

Note on Smack contexts: the CIPSO labels are limited to 23 characters thus the PKGID should have at most 12 characters for user applications and 10 for system applications.

The security of applications is summarized on tizen.

See the discussion.

categories of applications

The applications are of 3 categories:

Public
These privileges are open to all Tizen application developers.
Partner
The partner level privileges can only be used by developers registered as partners on the Tizen store.
The developer must be fully identified and permitted by the partner policy of the Tizen Store to use both public and partner level privileges.
Platform
The platform level privileges are used in security-sensitive system APIs for managing the Tizen platform.

The applications must be signed as documented here. The applications signed with the same author signature can use trusted connection with API MessagePort. The version 2 of Tizen widgets was also defining sharing areas of data on the file system for applications of the same author (see WebApps and Smack). The status of these sharing areas isn't currently defined for Tizen 3.

See the discussion.

Management of applications

The applications are of 2 types:

Read only applications
These applications are provided by the device, they can't be uninstalled
These read only applications are installed under path TZ_SYS_RO_APPS (/usr/apps/PKGID).
Removable applications
These applications are installed by the device users and can be removed.
These removable applications are installed under path TZ_SYS_RW_APPS (/opt/apps/PKGID).

See also multi user architecture and multi user metadata.

See the discussion.

Applications user data

The data of an application PKGID specific to a user USER are stored in the directory /home/USER/apps/PKGID the is tagged with the Smack context of the application. This forbids other applications to access its data.

See the discussion.

Service daemons

The services daemon will run with an appropriate uid and gid.

  • The system services should not run as root but must run with the predefined uid/gid.
  • Some user oriented service can be launched by users and will then receive their uid and gid

If a service daemon needs to store user specific configuration data, these data must be stored in the config sub-directory of the user home directory. See TZ_USER_CONFIG of multi user metadata.

See the discussion.

Media and memories policy

There are many kinds of media:

  • almost permanent memories like almost resident SD-cards;
  • plugable memories, like USB memories and SD-cards;
  • plugable read-only memories like CD and DVD.

For almost permanent memories, it make sense to create a directory per user of the system. At least, this directory could be created lazily, not at user creation. But it also make sense if the storage is permanent to create the user directories at user creation and to remove it at user destruction. That would implies that the storage is marked as such.

For almost permanent memories, the mounting point is to be defined.

The plugable memories are automatically mounted at a mounting point in a sub-directory of /mnt.

The ownership of the plugged memory is computed by the system to be accurate:

  • for IVI, it can be the user of the seat having plugged the device;
  • for other it can be the current user;
  • a dialog can be prompted to choose.

It is possible to mount the memory in a shared area.

The removable memories are generally FAT. As such, they don't have linux compatible security data. They will be mounted with smackfsdefault='*',smackfsroot='*' (see that mail).

See the discussion.

Sharing data between users or applications

The main rule is to not share but there are also many cases where sharing data is the main part. The cases of sharing are:

  • between applications of a same user, use case:
    • download a file with the browser, open it with an other application, delete it with the file manager;
    • taking a picture with the camera and send it by mail and delete it in the galery;
  • between users, use case:
    • Alice wants to share its favorite movie with Bob;
  • some data are shared to any user, use case:
    • the multimedia library of the car.

See the discussion.

Device plug

Bluetooth and USB devices can be plugged and unplugged.

The ownership of the device must be guessed by an agent. Some device have identifier that can be used to know the usual user of it. For example, pairing a bluetooth phone in the car.

See the discussion.

Management of user privileges

The users having admin rights will be able to modify the rights of other users:

  • restrict or augment the privileges
  • manage the devices and applications it can use
  • manage the amount of storage it can use

See the discussion.

Annex: User IDs policy

See the file /etc/login.defs of the project platform/upstream/pwdutils.

See the file /usr/sbin/useradd.local of the same package.

See also the presentation of containers that expect standard UID to be below 10000.

Annex: System predefined Ids

The following table is copied from Security:Analysing security privileges of tizen services#System Users Assignement

Domain User(UID) Group(GID)
System sysuser(200) sysuser(200)
Applications Framework appfw(202) appfw(202)
Base base(203) base(203)
Security security(204) security(204)
Multimedia multimedia(205) multimedia(205)
Graphics & UI Framework display(206) display(206)
Networks & Connectivity connectivity(207) connectivity(207)
Telephony telephony(208) telephony(208)
Messaging messaging(209) messaging(209)
Social & Content social(210) social(210)
Location location(211) location(211)
Automotive automotive(212) automotive(212)
Platform Development Not Assigned Not Assigned
SDK Not Assigned Not Assigned
Application Not Assigned Not Assigned
Test APIs Not Assigned Not Assigned
Device Owner devowner(1000) devowner(1000)
Developer developer(9999) developer(9999)

(For domains, refer to "https://wiki.tizen.org/wiki/Tizen_Platform_Architecture_Overview#Tizen_Domains")

Annex: How are admin users set

There are several options to record that a user has admin rights. These options are not exclusives.

  • use a group admin;
  • record the fact in vconf/buxton database.