Editing
Paper
(section)
From Linix VServer
Jump to navigation
Jump to search
Warning:
You are not logged in. Your IP address will be publicly visible if you make any edits. If you
log in
or
create an account
, your edits will be attributed to your username, along with other benefits.
Anti-spam check. Do
not
fill this in!
== Existing Infrastructure == Recent Linux Kernels already provide many security features that are utilized by Linux-VServer to do its work. Especially features such as the Linux Capability System, Resource Limits, File Attributes and the Change Root Environment. The following sections will give a short overview about each of these. === Linux Capability System === In computer science, a capability is a token used by a process to prove that it is allowed to perform an operation on an object. The Linux Capability System is based on "POSIX Capabilities", a somewhat different concept, designed to split up the all powerful root privilege into a set of distinct privileges. ==== POSIX Capabilities ==== A process has three sets of bitmaps called the inheritable(I), permitted(P), and effective(E) capabilities. Each capability is implemented as a bit in each of these bitmaps that is either set or unset. When a process tries to do a privileged operation, the operating system will check the appropriate bit in the effective set of the process (instead of checking whether the effective uid of the process is 0 as is normally done). For example, when a process tries to set the clock, the Linux kernel will check that the process has the CAP_SYS_TIME bit (which is currently bit 25) set in its effective set. The permitted set of the process indicates the capabilities the process can use. The process can have capabilities set in the permitted set that are not in the effective set. This indicates that the process has temporarily disabled this capability. A process is allowed to set a bit in its effective set only if it is available in the permitted set. The distinction between effective and permitted exists so that processes can "bracket" operations that need privilege. The inheritable capabilities are the capabilities of the current process that should be inherited by a program executed by the current process. The permitted set of a process is masked against the inheritable set during exec(). Nothing special happens during fork() or clone(). Child processes and threads are given an exact copy of the capabilities of the parent process. The implementation in Linux stopped at this point, whereas POSIX Capabilities[U5] requires the addition of capability sets to files too, to replace the SUID flag (at least for executables). The pending Linux 2.6.24 kernel supports file POSIX capabilities. (See Serge Hallyn's [http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=b53767719b6cd8789392ea3e7e2eb7b8906898f0 git commit] of Wed, 17 Oct 2007.) One userspace tool capable of changing file capabilities is the 2.X version of Andrew Morgan's [http://kernel.org/pub/linux/libs/security/linux-privs/ libcap] library and programs. ==== Capability Overview ==== The list of POSIX Capabilities used with Linux is long, and the 32 available bits are almost used up. While the detailed list of all capabilities can be found in /usr/include/linux/capability.h on most Linux systems, an overview of important capabilities is given here. {| class="wikitablenowrap" ! [0] CAP_CHOWN | change file ownership and group. |- ! [5] CAP_KILL | send a signal to a process with a different real or effective user ID |- ! [6] CAP_SETGID | permit setgid(2), setgroups(2), and forged gids on socket credentials passing |- ! [7] CAP_SETUID | permit set*uid(2), and forged uids on socket credentials passing |- ! [8] CAP_SETPCAP | transfer/remove any capability in permitted set to/from any pid |- ! [9] CAP_LINUX_IMMUTABLE | allow modification of S_IMMUTABLE and S_APPEND file attributes |- ! [11] CAP_NET_BROADCAST | permit broadcasting and listening to multicast |- ! [12] CAP_NET_ADMIN | permit interface configuration, IP firewall, masquerading, accounting, socket debugging, routing tables, bind to any address, enter promiscuous mode, multicasting, ... |- ! [13] CAP_NET_RAW | permit usage of RAW and PACKET sockets |- ! [16] CAP_SYS_MODULE | insert and remove kernel modules |- ! [18] CAP_SYS_CHROOT | permit chroot(2) |- ! [19] CAP_SYS_PTRACE | permit ptrace() of any process |- ! [21] CAP_SYS_ADMIN | this list would be too long, it basically allows to do everything else, not mentioned in another capability. |- ! [22] CAP_SYS_BOOT | permit reboot(2) |- ! [23] CAP_SYS_NICE | allow raising priority and setting priority on other processes, modify scheduling |- ! [24] CAP_SYS_RESOURCE | override resource limits, quota, reserved space on fs, ... |- ! [27] CAP_MKNOD | permit the privileged aspects of mknod(2) |} === Resource Limits === Resources for each process can be limited by specifying a Resource Limit. Similar to the Linux Capabilities, there are two different limits, a Soft Limit and a Hard Limit. The soft limit is the value that the kernel enforces for the corresponding resource. The hard limit acts as a ceiling for the soft limit: an unprivileged process may only set its soft limit to a value in the range from zero up to the hard limit, and (irreversibly) lower its hard limit. A privileged process may make arbitrary changes to either limit value, as long as the soft limit stays below the hard limit. ==== Limit-able Resource Overview ==== The list of all defined resource limits can be found in /usr/include/asm/resource.h on most Linux systems, an overview of relevant resource limits is given here. {| class="wikitablenowrap" |- ! [0] RLIMIT_CPU | CPU time in seconds. process is sent a SIGXCPU signal after reaching the soft limit, and SIGKILL on hard limit. |- ! [4] RLIMIT_CORE | maximum size of core files generated |- ! [5] RLIMIT_RSS | number of pages the process's resident set can consume (the number of virtual pages resident in RAM) |- ! [6] RLIMIT_NPROC | The maximum number of processes that can be created for the real user ID of the calling process. |- ! [7] RLIMIT_NOFILE | Specifies a value one greater than the maximum file descriptor number that can be opened by this process. |- ! [8] RLIMIT_MEMLOCK | The maximum number of virtual memory pages that may be locked into RAM using mlock() and mlockall(). |- ! [9] RLIMIT_AS | The maximum number of virtual memory pages available to the process (address space limit). \ |} === File Attributes === Originally, this feature was only available with ext2, but now all major filesystems implement a basic set of File Attributes that permit certain properties to be changed. Here again is a short overview of the possible attributes, and what they mean. {| class="wikitablenowrap" ! ! Macro Name ! Meaning |- ! s ! SECRM | When a file with this attribute set is deleted, its blocks are zeroed and written back to the disk. |- ! u ! UNRM | When a file with this attribute set is deleted, its contents are saved. |- ! c ! COMPR | Files marked with this attribute are automatically compressed on write and uncompressed on read. (not implemented yet) |- ! i ! IMMUTABLE | A file with this attribute cannot be modified: it cannot be deleted or renamed, no link can be created to this file and no data can be written to the file. |- ! a ! APPEND | Files with this attribute set can only be opened in append mode for writing. |- ! d ! NODUMP | If this flag is set, the file is not candidate for backup with the dump utility. |- ! S ! SYNC | Updates to the file contents are done synchronously. |- ! A ! NOATIME | Prevents updating the atime record on files when they are accessed or modified. |- ! t ! NOTAIL | A file with the t attribute will not have a partial block fragment at the end of the file merged with other files. |- ! D ! DIRSYNC | Changes to a directory having this attribute set will be done synchronously. |} The first column in the above table denotes command line options one might supply to ''lsattr'' respectively ''chattr''. The below screedump gives a notion about what we are talking: <pre> max@pc1:~$ cd /tmp/ max@pc1:/tmp$ touch my_file max@pc1:/tmp$ lsattr my_file ------------------ my_file max@pc1:/tmp$ chattr +a my_file chattr: Operation not permitted while setting flags on my_file max@pc1:/tmp$ su Password: pc1:/tmp# chattr +a my_file && lsattr my_file -----a------------ my_file pc1:/tmp# exit exit max@pc1:/tmp$ </pre> As you might have noticed, one needs to gain root permissions in the upper showcase (the underlying file system was ext3). For more information just issue ''man 1 chattr'' in your command line interface. Information regarding file attributes can be found in the kernel source code. Every file system uses a subset of all known attributes (which are used depends on the file system). One thing can be said for sure -- the file attributes listed in the kernel source code are defined -- those are not listed are not defined and in turn can not be used for a particular file system (e.g. ext3 (Extended File System version 3)). However, many of those file attributes defined and understood by the kernel have no effect. Most file systems define those flags in a specific (specific for a particular file system) header file found within the kernel source tree. They also define a so called '''User Modifiable Mask''' (those are the flags the user can change with the ''ioctls''). Those flags have partially different meaning depending on the node type (i.e. dir, inode, fifo, pipe, device) and it is not trivial to say if a filesystem makes use of any user modifiable flag -- things like immutable are easy to verify (from user space) but how to verify e.g. NOTAIL from user space? Usually only source code review will show if it is implemented and used. For example, if that didn't change, the COMPR is defined, and well understood by ext2/3 but there is no implementation there, i.e. nothing is compressed. === The chroot(1) Command === chroot allows you to run a command with a different directory acting as the root directory. This means that all filesystem lookups are done with '/' referring to the substitute root directory and not to the original one. While the Linux chroot implementation isn't very secure, it increases the isolation of processes with regards to the filesystem, and, if used properly, can create a filesystem "jail" for a single process or a restricted user, daemon or service.
Summary:
Please note that all contributions to Linix VServer may be edited, altered, or removed by other contributors. If you do not want your writing to be edited mercilessly, then do not submit it here.
You are also promising us that you wrote this yourself, or copied it from a public domain or similar free resource (see
Linix VServer:Copyrights
for details).
Do not submit copyrighted work without permission!
Cancel
Editing help
(opens in new window)
Navigation menu
Page actions
Page
Discussion
Read
Edit
History
Page actions
Page
Discussion
More
Tools
Personal tools
Not logged in
Talk
Contributions
Create account
Log in
About
Overview
Paper
News
Developers
Donations
Search
Getting Started
Downloads
FAQs
Documentation
Support
Participate
How to participate
Report a Bug
Communicate
Teams/Projects
Hall of Fame
Resources
Archives
Recent Wiki Changes
Pastebin
Related Projects
VServer Hosting
Happy VServer Users
Tools
What links here
Related changes
Special pages
Page information