Security/User and group ID assignment policy
- 1 Introduction
- 2 Current status
- 3 Proposed UID/GID assignment scheme
- 4 Privilege-managed resources and group ids
- 5 New users and groups
- 6 Howto use GID protected resources
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
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
|1-199||Basic system users|
|200-1999||Platform system daemons|
|2000-2199||Vendor-specific basic system users|
|2200-4999||Vendor-specific system daemons|
|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
|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)|
|Network & Connectivity||550-599||2550-2599|
|Social & Content||700-749||2700-2749|
|Reserved for new platform domains||1050-1999||3050-3999|
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)|
|Network & Connectivity||10700-10799||15700-15799|
|Social & Content||11000-11099||16000-16099|
|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: https://wiki.tizen.org/w/index.php?title=Security/Tizen_3.0_security_porting_guide
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:
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: https://review.tizen.org/gerrit/#/c/49121/ 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.