From Tizen Wiki
(Redirected from Security/Smack)
Jump to: navigation, search


Smack Tips

This page is intended to be a collection of hints, suggestions and recommendations regarding Smack (the Simplified Mandatory Access Control Kernel) and its use in Tizen.

Smack Labels on Files

Every file has a Smack label. Some files also have Smack execution attributes, but most do not. You can see the Smack labels on files two ways.

# ls -Z /opt/home
User app     _ developer
# chsmack /usr/bin/ls
/usr/bin/ls access="_"

The ls command will show you the access label. The chsmack command will show you all of the Smack attributes on a file.

Process Smack Labels

The id command will show your process Smack label. The Smack label is called the context by id for historical reasons. The ps command will show the Smack labels of processes if you use the -Z option.

# id
uid=0(root) gid=0(root) groups=0(root),29(audio),6505(pulse-access),6506(pulse-rt) context=User
# id -Z
# ps -Z
LABEL                             PID TTY          TIME CMD
User                            12193 pts/0    00:00:00 bash
User                            12201 pts/0    00:00:00 ps

Changing Your Smack Label

All processes run with a Smack label, just as all processes run with a user ID. A privileged process can change its Smack label by writing the new label into a special file in the proc filesystem.

# id -Z
# echo ThunderBall > /proc/self/attr/current
# id -Z

Installation With RPM

The version of rpm used with Tizen understands Smack. Each package includes a manifest file that describes the Smack Domain and labels used by the programs in the package. If there is no manifest file in the package all of the files will be installed with the Smack label of the rpm process.

You probably want files from a package without a manifest installed with the floor ("_") label. Set the Smack label your shell to "_" using the procedure above before you run rpm and you will get the best result regardless of whether the rpm has a manifest file or not.

The exception to this rule is if you want to install a package in a relative root. You might do this to examine a source RPM in your home directory. In this case leave the Smack label on your process alone, and if there is no manifest the files will get installed with your label.

Installation With zypper

The version of zypper used with Tizen does not understand Smack. This is an issue because zypper is a network interface for RPM. Typically you want to run zypper with the floor ("_") label, but the floor domain does not have access to the network. In Tizen 3 the network label is (as of this writing) "System". The floor domain is allowed to write to the System domain, but not the other way around. This means that packets coming off the network can't be delivered to zypper. Here is how to temporarily allow the packets to be delivered so that zypper can write files properly and also talk on the network:

# id -Z
# echo _ > /proc/self/attr/current
# id -Z
# echo System _ w > /sys/fs/smackfs/load2
# zypper your options
# echo System _ l > /sys/fs/smackfs/load2

When the debugger does not work

If you are having trouble with Smack while doing debugging, chances are good that you are encountering the effects of the SMACK64EXEC attribute on a program file. A program marked with the SMACK64EXEC attribute will always run with the Smack label defined by that attribute. It is entirely possible that a process with the new attribute will have a completely different set of access rights than the program that invoked it. If the program was started from a debugger (gdb) it is unlikely that the debugger will be able to look at the process image, resulting in a failed debugging session. You can avoid this problem by taking two simple steps.

# chsmack programname
programname access="_" exec="ThunderBall"

There are basically two ways to continue.

The command below will change the Smack label of the user shell to "ThunderBall". All of the processes started from this shell will inherent this label unless they have an explict SMACK64EXEC label attribute. NOTE: echo is the bash builtin command, not the one from coreutils.

# echo ThunderBall > /proc/self/attr/current
# gdb programname

Another approach is to set the SMACK64EXEC label attribute of gdb to match the one on the program. Always do this on a copy of gdb to avoid confusion later.

# cp /usr/bin/gdb /tmp/gdb-ThunderBall
# chsmack -e "ThunderBall" /tmp/gdb-ThunderBall
# /tmp/gdb-ThunderBall programname

Then enjoy your debugging.

Smack FAQ

This isn't really a list of frequently asked questions. It's more a list of questions that seem inportant to answer. All of them have been asked in some forum or another, so they do qualify as "asked", if not necessarily frequently. They are broken into the most important categories.

Smack Proper

How to get current process label?

From a shell:

# cat /proc/self/attr/current
# id -Z
# id

From a program linked with libsmack:

ssize_t rsize;
char *smackp;

rsize = smack_new_label_from_self(&smackp);

Why does "echo label > /proc/self/attr/current" change the current process label instead of the label of the echo command?

If we use the external echo command (/bin/echo) from coreutils, the fork() occurs before the redirection in the shell, so the process that opens /proc/self/attr/current is the one that exec()s /bin/echo, not the one that remains the shell. Fortunately, all modern shells have a built-in echo command that executes without spawning a new process.

Can we list all the SMACK related utilities?

Realize that this is like asking about all of the user related utilities. The ones that are most obviously important are:

  • ls -Z to show the Smack labels on files.
  • chsmack to show and sett all of the Smack attributes on files.
  • cp --preserve=xattr to create a new file with the same content and Smack attributes as an existing file.
  • rpm installs packages.
  • id and id -Z to show the current process Smack label.
  • ps -Z show information about processes, including their Smack labels.

Why keep the old interface such as /load, /access?

The Linux kernel community believes that backward compatability is very important. Because older user space code uses these interfaces they must remain. New code should use the access2, cipso2 and load2 interfaces.

How does Smack perform access control on the network?

Smack uses the Common Internet Protocol Security Option (CIPSO - pronounced sip-sew) to attach a Smack label to each packet. An access check is made when the packet is delivered to a socket. The sender must have write access to the receiver for the packet to be delivered.

How does one debug a failing socket connect/send?

Usually a connect or send will fail because the sending process does not have write access to the remote socket. A connect may fail because the remote process does not have write access to the originator. Connect requires a hand-shake, so writing has to be possible both ways. Look at the Smack access rules in /sys/fs/smackfs/load2 to see what accesses are allowed. Network monitoring tools, for example wireshark or tcpdump, can also be very helpful.

UDS sockets have local filesystem representations. The lsof utility will help identify the other processes using a UDS socket.

What is the performing priority when traditional uid/gid machinism co-exist with Smack?

Traditional access checks are made first, then Smack checks. The traditional check and the Smack check must both pass for access to be permitted. Network access does not traditionally have access checks, so the Smack check is the first and only check.

Smack in Tizen

What is a Domain?

Domain is one of three computer security terms that have been used in so many different ways that it is hard to tell what it means. (The others are capability and privilege.)

In Tizen a domain is defined as a set of processes running with the same Smack label, the objects with that Smack label and the objects with any other Smack labels defined to be controlled by that domain. The System domain includes all the processes running with the System label, all files labeled System, System::Run, System::Shared and System::Log. Note that the names of these labels are conventional, not enforced.

If a package is set to be "_", is it possible to make certain files writable?

More generally, how do programs share files?

Programs shared files by putting them in locations that allow them appropriate access. If two programs run in the same domain they can share in their private directories. If two programs need write access to the same files they should be in the same domain. If a program running in the System domain wants to let a program running in the User domain read a file, that file should be placed in a directory labeled System::Shared.

How should developer decide the right domain for a package?

Almost all packages should be installed in the floor domain. See the description of the three domain model for the details.

Are three domains enough for tizen 3.0?

Yes. Well, no, actually. The three domain model emphasises the distinctions between static infrastructure, system services and user resources. These are by far the most important divisions in the processing that occurs on the system. Within each of these domains it will be convinient and prudent to introduce additional peer domains, with a subset of the access available to the domain it is removed from.

What is the process for requesting a new domain?

A description of the process is here.

What is mapping relationship between packages and the domains?

In Tizen 2 each package was assumed to represent a domain. In Tizen 3 there is no implicit relationship between a package and the domain or domains related to its contents. In certain cases all the files in a package may be specified to be placed in a domain. In other cases individual files may be placed in specific domains.

Can the Smack attribute of a file or directory from another package be changed at install time?

It is possible, but don't do it.

The Smack label a service launches with can be set by systemd. A binary can have the SMACK64EXEC attrbute set. What happens if the two labels are different?

The process with run with the value specified by the SMACK64EXEC value. The preferred configuration is to have systemd launch the service with the correct Smack label. Setting the SMACK64EXEC attribute should be avoided where possible.

What about vconf databases?

The standard place for vconf databases is a shared, transmuting directory that is set up to allow the required access.

When are the Smack access rules loaded?

Smack rules are loaded by systemd early in the start-up process.

What is the minimum domain and ruleset for Tizen?

The basic rule set is found in /etc/smack/accesses.d/default-access-domains.

How to check if SMACK is enabled?

Execute the following command to determine whether SMACK is enabled:

grep smackfs /proc/filesystems

If the output is empty SMACK is disabled.

How to disable SMACK?

There are two options to disable SMACK:

  • Add the following configuration to the kernel command line
  • Alternatively, disable SMACK and security for kernel's configurations and rebuild it.