Κεφάλαιο 13 Ασφάλεια

«Sandbox» is a security term. It can mean two things:

• A process which is placed inside a set of virtual walls that are designed to prevent someone who breaks into the process from being able to break into the wider system.

  The process is said to be able to «play» inside the walls. That is, nothing the process does in regards to executing code is supposed to be able to breech the walls so you do not have to do a detailed audit of its code to be able to say certain things about its security.

  The walls might be a userid, for example. This is the definition used in the security(7) and named(8) man pages.

  Take the ntalk service, for example (see /etc/inetd.conf). This service used to run as userid root. Now it runs as userid tty. The tty user is a sandbox designed to make it more difficult for someone who has successfully hacked into the system via ntalk from being able to hack beyond that user id.

• A process which is placed inside a simulation of the machine. This is more hard-core. Basically it means that someone who is able to break into the process may believe that he can break into the wider machine but is, in fact, only breaking into a simulation of that machine and not modifying any real data.

  The most common way to accomplish this is to build a simulated environment in a subdirectory and then run the processes in that directory chroot'd (i.e. / for that process is this directory, not the real / of the system).

  Another common use is to mount an underlying filesystem read-only and then create a filesystem layer on top of it that gives a process a seemingly writeable view into that filesystem. The process may believe it is able to write to those files, but only the process sees the effects - other processes in the system do not, necessarily.

  An attempt is made to make this sort of sandbox so transparent that the user (or hacker) does not realize that he is sitting in it.

UNIX® implements two core sandboxes. One is at the process level, and one is at the userid level.

Every UNIX process is completely firewalled off from every other UNIX process. One process cannot modify the address space of another. This is unlike Windows® where a process can easily overwrite the address space of any other, leading to a crash.

A UNIX process is owned by a particular userid. If the userid is not the root user, it serves to firewall the process off from processes owned by other users. The userid is also used to firewall off on-disk data.

The securelevel is a security mechanism implemented in the kernel. Basically, when the securelevel is positive, the kernel restricts certain tasks; not even the superuser (i.e., root) is allowed to do them. At the time of this writing, the securelevel mechanism is capable of, among other things, limiting the ability to,

• unset certain file flags, such as schg (the system immutable flag),

• write to kernel memory via /dev/mem and /dev/kmem,

• load kernel modules, and

• alter firewall rules.

To check the status of the securelevel on a running system, simply execute the following command:

# sysctl kern.securelevel

The output will contain the name of the sysctl(8) variable (in this case, kern.securelevel) and a number. The latter is the current value of the securelevel. If it is positive (i.e., greater than 0), at least some of the securelevel's protections are enabled.

You cannot lower the securelevel of a running system; being able to do that would defeat its purpose. If you need to do a task that requires that the securelevel be non-positive (e.g., an installworld or changing the date), you will have to change the securelevel setting in /etc/rc.conf (you want to look for the kern_securelevel and kern_securelevel_enable variables) and reboot.

For more information on securelevel and the specific things all the levels do, please consult the init(8) manual page.

BIND uses a random high-numbered port for outgoing queries. If you want to use port 53 for outgoing queries, either to get past a firewall or to make yourself feel better, you can try the following in /etc/namedb/named.conf:

options {
        query-source address * port 53;
};

You can replace the * with a single IP address if you want to tighten things further.

Congratulations, by the way. It is good practice to read your sockstat(1) output and notice odd things!

Recent versions of Sendmail support a mail submission feature that runs over port 587. This is not yet widely supported, but is growing in popularity.

Do not worry. toor is an «alternative» superuser account (toor is root spelt backwards). Previously it was created when the bash(1) shell was installed but now it is created by default. It is intended to be used with a non-standard shell so you do not have to change root's default shell. This is important as shells which are not part of the base distribution (for example a shell installed from ports or packages) are likely to be installed in /usr/local/bin which, by default, resides on a different filesystem. If root's shell is located in /usr/local/bin and /usr (or whatever filesystem contains /usr/local/bin) is not mounted for some reason, root will not be able to log in to fix a problem (although if you reboot into single user mode you will be prompted for the path to a shell).

Some people use toor for day-to-day root tasks with a non-standard shell, leaving root, with a standard shell, for single user mode or emergencies. By default you cannot log in using toor as it does not have a password, so log in as root and set a password for toor if you want to use it.

For security reasons, suidperl is installed without the suid bit by default. The system administrator can enable suid behavior with the following command.

# chmod u+s /usr/bin/suidperl

If you want suidperl to be built suid during upgrades from source, edit /etc/make.conf and add ENABLE_SUIDPERL=true before you run make buildworld.