Security/User and group ID assignment policy

From Tizen Wiki
Jump to: navigation, search


It has been decided that in Tizen 3.0 user and group IDs should be statically assigned. The only identifiers that are allowed to be assigned dynamically correspond to regular users. Significant advantage of static uid/gid assignment is its resistance to update related problems.

Here are basic rules when working with statically assigned identifiers:

  • Identifiers should be unique and their id assignment should be constant
  • In general, uid/gid values should not be reused as it might inadvertently give access to some sensitive resources to unauthorized parties. Exceptions might include:
    • Identifiers have never been used in products and they are already obsoleted
    • Identifiers are obsoleted and not actively used for a long time so there is no risk that image that is going to be updated already uses given ids
  • They should follow predefined scheme as proposed in following section
  • There is a central location for managing UID/GID mapping: platform/upstream/setup
  • New Jira ticket should be created in order to request a new UID or GID. More information can be found in following sections

Current status

There are several things that make current status not conform to what has been proposed:

  • often there are no clear patterns uid/gids follow and if they do they are different to what has been proposed
  • certain users or groups are not used but are defined in the setup project (e.g. vconf_hib, db_alarm. There are probably many more examples)
  • in case of several packages uids/gids are assigned dynamically (e.g. buxton)

Proposed UID/GID assignment scheme

UID assignment scheme

UID range Type
1-199 Basic system users
200-1999 Platform system daemons
2000-2199 Vendor-specific basic system users
2200-4999 Vendor-specific system daemons
5000-9999 Regular users
10000- Reserved for future use

You should avoid adding new users to Basic system users. Usually Platform system daemons or Vendor-specific system daemons is a better place. Possible reasons why you would like to use basic range include:

  • this is the basic system user that does not correspond to a specific daemon. For example: bin or sys
  • user corresponds to a daemon taken from upstream and there and no clear benefit of moving it elsewhere is identified

Please remember that in Tizen packages are organized into domains. User and group identifiers should use ranges assigned for a given domain. Domain assignment scheme is described later in this section.

GID assignment scheme

GID range Type Notes
1-199 Basic system groups
200-2000 Platform system daemons primary groups Should be same as corresponding UID
2000-2199 Vendor-specific basic system groups
2200-4999 Vendor-specific system daemons primary groups Should be same as corresponding UID
5000-9999 Regular users primary groups Should be same as corresponding UID
10000-14999 Platform supplementary groups Might correspond to a privilege
15000-19999 Vendor-specific supplementary groups Might correspond to a privilege
20000- Reserved for future use

First range - Basic system groups should be avoided in general. It should be used for:

  • primary groups that correspond to basic system users
  • basic system supplementary groups

Domain assignment scheme

Tizen packages are classified into domains which define the logical part of the system given package belongs to. One of implications on such classification is that user and group identifiers should be domain-based. Services, if possible, should run as a separate (non-root) user with unique UID/GID value that is based on their domain. Any private data they use should be assigned to the same UID/GID and be given appropriate permissions. Service UIDs/GIDs should follow scheme in the below table:

Domain UID/GID range (platform) UID/GID range (vendor-specific)
System 200-249 2200-2249
Web F/W 250-299 2250-2299
App F/W 300-349 2300-2349
Base 350-399 2350-2399
Security 400-449 2400-2449
Multimedia 450-499 2450-2499
GUI 500-549 2500-2549
Network & Connectivity 550-599 2550-2599
Telephony 600-649 2600-2649
Messaging 650-699 2650-2699
Social & Content 700-749 2700-2749
Location 750-799 2750-2799
Automotive 800-849 2800-2849
Platform Development 850-899 2850-2899
SDK 900-949 2900-2949
Application 950-999 2950-2999
Test APIs 1000-1049 3000-3049
Reserved for new platform domains 1050-1999 3050-3999
Vendor-specific domains N/A 4000-4999

Similarly, supplementary group IDs should be based on the domain they belong to. They should be used for data shared between different system services. In particular first GID in every domain (10000, 10100, 10200 and so on) refers to the group which is associated with data shared among all services in the given domain. Supplementary groups can also be used to allow applications access resources directly. More information can be found in the next section.

Group ID assignment scheme is defined in the below table:

Domain Supplementary Group ID range (platform) Supplementary Group ID range (vendor-specific)
System 10000-10099 15000-15099
Web F/W 10100-10199 15100-15199
App F/W 10200-10299 15200-15299
Base 10300-10399 15300-15399
Security 10400-10499 15400-15499
Multimedia 10500-10599 15500-15599
GUI 10600-10699 15600-15699
Network & Connectivity 10700-10799 15700-15799
Telephony 10800-10899 15800-15899
Messaging 10900-10999 15900-15999
Social & Content 11000-11099 16000-16099
Location 11100-11199 16100-16199
Automotive 11200-11299 16200-16299
Platform Development 11300-11399 16300-16399
SDK 11400-11499 16400-16499
Application 11500-11599 16500-16599
Test APIs 11600-11699 16600-16699
Reserved for future use 11700-14999 16700-19999

Privilege-managed resources and group ids

Some sensitive resources like databases might be accessible directly by applications. In such case resource should be assigned to a supplementary group associated with the privilege. Application launcher (via security manager) will add proper supplementary groups based on privileges given application has. More information can be found in the "Securing access to resources" section in this article:

There is an assignment between privileges and groups. However, as this mechanism is supplementary to Cynara privilege check - the mapping is introduced in Security Manager configuration on request (more information in next points). The mapping is defined in the following table:

Privilege Domain Group Name Group ID Social & Content priv_account_read 11001 Social & Content priv_account_write 11002 App F/W priv_alarm_get 10201 App F/W priv_alarm_set 10202 App F/W priv_apphistory_read 10208 App F/W priv_appmanager_kill 10203 App F/W priv_appmanager_kill_bgapp 10209 App F/W priv_appmanager_launch 10204 Network & Connectivity priv_bluetooth 10701 Network & Connectivity priv_bluetooth_admin 10702 Web F/W priv_bookmark_admin 10101 Social & Content priv_calendar_read 11003 Social & Content priv_calendar_write 11004 Telephony priv_call 10801 Telephony priv_callhistory_read 10802 Telephony priv_callhistory_write 10803 Multimedia priv_camera 10501 Social & Content priv_contact_read 11005 Social & Content priv_contact_write 11006 Social & Content priv_content_write 11007 App F/W priv_datasharing 10207 GUI priv_display 10601 Network & Connectivity priv_download 10703 Messaging priv_email 10901 Messaging priv_email_admin 10902 System priv_externalstorage 10001 System priv_externalstorage_appdata 10002 System priv_haptic 10003 Social & Content priv_healthinfo 11008 GUI priv_ime 10606 System priv_imemanager 10006 App F/W priv_inputgenerator 10210 Network & Connectivity priv_internet 10704 GUI priv_keygrab 10607 Security priv_keymanager 10401 System priv_led 10004 Location priv_location 11101 Location priv_location_enable 11102 Location priv_mapservice 11103 Multimedia priv_mediacontroller_client 10504 Multimedia priv_mediacontroller_server 10505 Multimedia priv_mediahistory_read 10506 Multimedia priv_mediastorage 10502 Messaging priv_message_read 10903 Messaging priv_message_write 10904 GUI priv_minicontrol_provider 10608 Network & Connectivity priv_network_get 10705 Network & Connectivity priv_network_profile 10706 Network & Connectivity priv_network_set 10707 Network & Connectivity priv_nfc 10708 Network & Connectivity priv_nfc_admin 10709 Network & Connectivity priv_nfc_cardemulation 10710 GUI priv_notification 10602 App F/W priv_packagemanager_admin 10205 App F/W priv_packagemanager_clearcache 10211 App F/W priv_packagemanager_info 10206 System priv_power 10005 Messaging priv_push 10905 System priv_reboot 10009 Multimedia priv_recorder 10503 GUI priv_screenshot 10603 System priv_secureelement 10010 GUI priv_shortcut 10604 System priv_systemmonitor 10011 System priv_systemsettings_admin 10007 Telephony priv_telephony 10804 Telephony priv_telephony_admin 10805 Network & Connectivity priv_tethering_admin 10711 System priv_volume_set 10008 Web F/W priv_web_history_admin 10102 Web F/W priv_widget_viewer 10103 Network & Connectivity priv_wifidirect 10712 GUI priv_window_priority_set 10605

New users and groups

When a package needs a new user or group, it must use predefined uids/gids. This can achieved by using commands like useradd and groupadd with fixed uid/gid in RPM post scripts. Optional groups should also be put in platform/upstream/setup project to avoid conflicts with other packages ( so please make sure to keep consistency between uid/gid values in the given package and entries in platform/upstream/setup).

Every time when new user or group is required a patch (commit/change) to platform/upstream/setup shall be submitted.

Howto use GID protected resources

Every time when group protection is needed for some resources as other means for protection (Cynara) is not acceptable for some reason:

  • Choose the right privilege to protect your resource.
  • Check in the file (belonging to platform/core/security/security-manager) whether there exist a mapping between the group name and the privilege
    • If there is no such mapping prepare a patch to platform/core/security/security-manager and add Tomasz Swierczek, Rafal Krypa, Radoslaw Bartosiak, Aleksander Mistewicz, Oskar Switalski, Kim Kidong). The patch: might serve as an example.
  • Configure the resource by assigning it to the group mapped to the privilege (or many groups if access shall be allowed to possessors of different privileges).

Configuration when the resource shall be assigned to one group/privilege

Configure proper group ownership for the resource. The Smack label must be set to "*" - accessible to everyone. This is because access is to be controlled only by DAC mechanisms, not Smack.

~# chgrp <groupName> <resourcePath>
~# chmod g+rw <resourcePath> ("rw" in case of privilege needing RW access rights, "r" in case of privilege needing RO access)
~# chmod o= <resourcePath> (give no access by default, only members of <groupName> should be allowed)
~# chsmack access="*" <resourcePath>

Configuration when the resource shall be assigned to multiple groups/privileges

In some cases there is more than one privilege governing access to a resource. Common example would be separate privileges for RO and RW access. This can be achieved with mechanism called access control lists - ACL. It's a UNIX standard that enables access configuration for multiple users or groups. Example for RO and RW privileges on a single resource:

~# chgrp <groupNameRW> <resourcePath>
~# chmod g+rw <resourcePath>
~# chmod o= <resourcePath>
~# setfacl -m group:<groupNameRO>:r <resourcePath>
~# chsmack access="*" <resourcePath>

If you want to examine ACLs configured for a file, use getfacl tool. ACLs are not displayed by ls.

Configuration when the resource is located in user's home directory

Resources under TZ_USER_HOME are special, because they cannot be directly configured during RPM package installation. With a multi-user feature, users may be created and removed during life time of the system. To enable group ID policy for such resources, they must be configured in /etc/skel directory. All files and directories under /etc/skel will be copied to user's home directory when a user is created. During that copy, file permissions are preserved.