Security/Tizen 2.X User-space access control
This page explains what is User-space access-control and the reason why we provide this feature in Tizen 2.3. If you are a platform developer who wish to find an access check mechanism on your daemon process, please refer to this detailed description.
Tizen uses Smack to provide strong access control at the kernel space which is a related to subject(process) and object(resource). Any processes are not allowed to access an object without proper Smack rule which is a very simple and effective.
However the kernel-space Smack has a limit on IPC. For example, there is a contact application which wants to read contact database file and contact-service daemon is managing contact database directly. When the application calls a contact reading API, the contact-service daemon will return contact data to the application. In this situation, the subject process tries to read an object(contact data in this case) is always the contact-service daemon that reads contact database. Eventually the requested Smack rule is a read permission from the contact-service daemon to the contact database file at the kernel side. The Kernel-space Smack does not know which process is the real consumer of the resource.
User-space access control by the socket label
If you use Unix domain socket for your IPC channel, you can simply apply access control by adding a Smack label on the socket, then the only application which has corresponding Smack rule to connect contact-service socket is allowed to call the API. (Of course, the Smack rules should be described in a contact.read privilege.)
Suppose you provide contact writing APIs as well. Generally, writing is more sensitive then reading a database, therefore you should provide access control for contact writing APIs as well. In this case, you can create one more socket covering write API channel because you cannot achieve 2 different access control with a single socket in contact-service daemon.
As a result, if you want to enforce access control by socket labeling, then you should create sockets as many as number of the access control granularity. See simple access control example below through socket labeling.
Basically, Smack labels of a socket(Smack64IPIN and Smack64IPOUT) are inherited from the creator process, but when you want to use user-space access control by socket label, you have to use different but unique Smack label other than the Smack label of the service daemon process. In this case you should define and request a sub-domain in your Smack manifest. (Link missing for Smack manifest)
There are two methods for socket labeling:
- By systemd: Systemd socket has useful options and you can specifies socket label from options as shown below.
[Socket] ListenStream=/tmp/.security-server-api-password-check.sock SocketMode=0777 SmackLabelIPIn=security-server::api-password-check SmackLabelIPOut=@ Service=security-server.service [Unit] Wants=security-server.target Before=security-server.target [Install] WantedBy=sockets.target
- By a libc function: fsetxattr() sets an extended attribute for a file descriptor. This requires CAP_MAC_ADMIN capability.
rval = fsetxattr(sock, "security.Smack64IPIN", "security-server::api-password-check", 35, 0); rval = fsetxattr(sock, "security.Smack64IPOUT", "@", 1, 0);
User-space access control by a dedicated access check daemon
This mechanism is also based on Smack. Service daemon typically allows any client to connect the open socket and decides whether to accept the received request or not through access-check daemon's decision. Access-check daemon use libsmack APIs with client credential, object label and access permission which are provided by service daemon..
There are two access-check daemons available: