https://wiki.archlinux.org/api.php?action=feedcontributions&user=Jnguyen&feedformat=atomArchWiki - User contributions [en]2024-03-28T17:53:24ZUser contributionsMediaWiki 1.41.0https://wiki.archlinux.org/index.php?title=TOMOYO_Linux&diff=165954TOMOYO Linux2011-10-15T11:00:43Z<p>Jnguyen: typo</p>
<hr />
<div>[[Category:Security (English)]]<br />
[[Category:Kernel (English)]]<br />
[[Category:Networking (English)]]<br />
{{i18n|TOMOYO Linux}}<br />
[http://tomoyo.sourceforge.jp/ TOMOYO Linux] is Mandatory Access Control (MAC) implementation for Linux. It was launched in March 2003 and is sponsored by [http://www.nttdata.co.jp/en/ NTT Data Corporation]. TOMOYO Linux focuses on the behaviour of a system, allowing each process to declare behaviours and resources needed to achieve its purpose. It can be used as a system analysis tool as well as an access restriction tool.<br />
<br />
The security goal of TOMOYO Linux is to provide "MAC that covers practical requirements for most users and keeps usable for most administrators". TOMOYO Linux is not a tool for just security professionals, but also for average users and administrators.<br />
{{Note|This article does not aim to be an exhaustive guide and should be used as a supplement to the extensive [http://tomoyo.sourceforge.jp/documentation.html user documentation] provided by the project.}}<br />
{{Tip|The [[#TOMOYO Linux 2.x|TOMOYO Linux 2.x]] branch is already in the Arch Linux [community] repository. This branch will eventually come closer to reaching feature parity with the 1.x branch, but for those wanting an easy start the 2.x branch is easy to install. The [[#TOMOYO Linux 1.x|TOMOYO Linux 1.x]] branch is for those wanting the greatest security, while [[#AKARI|AKARI]] is somewhere in between.}}<br />
<br />
==Introduction==<br />
TOMOYO Linux attempts to make the system where everything is prearranged in an easy to understand way:<br />
* Make all access requests that will occur at least once during the lifetime of the kernel known in advance<br />
* Allow the administrator to write a policy that only allows expected and desirable access requests<br />
Unlike AppArmor, TOMOYO Linux is intended to protect the whole system from attackers exploiting vulnerabilities in applications. TOMOYO Linux addresses this threat by recording the behaviour of all applications in the test environment and then forcing all applications to act within these recorded behaviours in the production environment.<br />
<br />
TOMOYO Linux is not for users wanting ready-made policy files supplied by others. It involves creating policy from scratch, aided by the "learning mode" which can automatically generate policy files with necessary and sufficient permissions for a specific system. TOMOYO Linux reports what is happening within the Linux system and can therefore be used as a system analysis tool. It resembles strace and reports what is being executed by each program and what files/networks are accessed.<br />
<br />
This [http://tomoyo.sourceforge.jp/wiki-e/?WhatIs#comparison table] provides a comprehensive comparison of TOMOYO Linux with [[AppArmor]], [[SELinux]] and [http://schaufler-ca.com/ SMACK].<br />
<br />
==Branches of development==<br />
[http://tomoyo.sourceforge.jp/1.8/index.html.en TOMOYO Linux 1.x] is the original branch of development. TOMOYO Linux was first released on 11th November 2005. It was implemented as a patch that can be applied to the Linux kernel and is still in active development. It can coexist with other security modules such as SELinux, SMACK and AppArmor.<br />
<br />
[http://tomoyo.sourceforge.jp/2.3/index.html.en TOMOYO Linux 2.x] is the Linux mainline kernel branch of development. In June 2009, TOMOYO was merged into the Linux kernel version 2.6.30 and it uses standard Linux Security Module (LSM) hooks. However, the LSM hooks must be extended further in order to port the full MAC functionality of TOMOYO Linux into the Linux kernel. Thus, it does not yet provide equal functionality with the 1.x branch of development. This [http://tomoyo.sourceforge.jp/comparison.html.en chart] compares the differences between each branch.<br />
<br />
[http://akari.sourceforge.jp/ AKARI] is based on the TOMOYO Linux 1.x branch and is implemented as a Loadable Kernel Module (LKM). It therefore has the advantage of not requiring the user to patch and recompile the kernel. This [http://akari.sourceforge.jp/comparison.html table] provides a comprehensive comparison of AKARI with the TOMOYO Linux 1.x and 2.x branches.<br />
<br />
==TOMOYO Linux 1.x==<br />
Implementing TOMOYO Linux 1.x using a kernel patched with ccs-patch provides the full functionality obtainable from the TOMOYO Linux project. However, implementation of this branch requires the most hurdles to be overcome, as the kernel must be patched with [http://sourceforge.jp/projects/tomoyo/ ccs-patch] and subsequently recompiled.<br />
<br />
Both ''linux-ccs'' and the userspace tools must be installed. A package for [https://aur.archlinux.org/packages.php?ID=51669 linux-ccs] and a package for [http://aur.archlinux.org/packages.php?ID=42606 ccs-tools] are available on the AUR.<br />
<br />
===Initializing configuration===<br />
The policy must first be initialized:<br />
# /usr/lib/ccs/init_policy<br />
The policy files are saved in the {{Filename|/etc/css/}} directory and can be edited by running:<br />
# ccs-editpolicy<br />
<br />
==AKARI==<br />
===Limitations of AKARI===<br />
AKARI has the advantage of not requiring kernel recompilation. If using the TOMOYO Linux project purely for system analysis, then AKARI is the easiest method of achieving this. If using the TOMOYO Linux project for system restriction, it is a minimal effort way to gain most of the functionality of the TOMOYO Linux 1.x branch. However, there are a few limitations that must be considered:<br />
* It depends on the kernel version and configuration provided by the distribution:<br />
<pre><br />
CONFIG_SECURITY=y [required]<br />
CONFIG_KALLSYMS=y [required]<br />
CONFIG_PROC_FS=y [required]<br />
CONFIG_MODULES=y [required]<br />
CONFIG_SECURITY_PATH=y [optional: for using absolute pathnames]<br />
CONFIG_SECURITY_NETWORK=y [optional: for providing network restriction]<br />
</pre><br />
* The restriction of a few advanced networking operations are limited or unavailable due to the absence of required LSM hooks<br />
* Restricting use of [http://en.wikipedia.org/wiki/Capability-based_security capabilities] is not possible<br />
* Looking up per-task variables is slower as they are managed outside "struct task_struct" in order to keep KABI unchanged. However, this should not be noticeable for the typical end-user as performance decrease by pathname based permission checking is dominant<br />
This [http://akari.sourceforge.jp/comparison.html table] provides a comprehensive comparison of AKARI with the TOMOYO Linux 1.x and 2.x branches.<br />
<br />
{{Note|The Arch Linux kernel from 2.6.36 onwards provides all of the configuration options required for full functionality.}}<br />
<br />
===Installation===<br />
Both AKARI and the userspace tools must be installed. A package for [http://aur.archlinux.org/packages.php?ID=42608 AKARI] and a package for [http://aur.archlinux.org/packages.php?ID=42606 ccs-tools] are available on the AUR.<br />
<br />
The bootloader configuration must be changed in order to activate AKARI:<br />
title Arch Linux<br />
root (hd0,0)<br />
kernel /boot/vmlinuz-linux root=/dev/sda1 ro init=/sbin/ccs-init<br />
initrd /boot/initramfs-linux.img<br />
<br />
===Initializing configuration===<br />
The policy must first be initialized:<br />
# /usr/lib/ccs/init_policy --module_name=akari<br />
The policy files are saved in the {{Filename|/etc/css/}} directory and can be edited by running:<br />
# ccs-editpolicy<br />
<br />
==TOMOYO Linux 2.x==<br />
===Limitations of TOMOYO Linux 2.x===<br />
The implementation of TOMOYO Linux 2.x into the Linux mainline kernel is not yet complete but is still effective for MAC of files. There are a few features that still need to be implemented as compared to the 1.x branch. This [http://tomoyo.sourceforge.jp/comparison.html.en chart] has a comprehensive comparison of the differences between each branch of development.<br />
<br />
===Installation===<br />
TOMOYO Linux 2.x is part of the Linux mainline kernel and, in addition to those previously mentioned, requires the following kernel configuration:<br />
CONFIG_SECURITY_TOMOYO=y<br />
{{note|The Arch Linux kernel from 2.6.36 onwards provides all of the configuration options required for full functionality.}}<br />
<br />
If the kernel supports TOMOYO Linux 2.x, then only the userspace tools need to be installed:<br />
<br />
<pre><br />
pacman -S tomoyo-tools<br />
</pre><br />
<br />
For kernel versions between 2.6.30 and 2.6.35, tomoyo-tools 2.2.x should be installed. A package is available on the [http://aur.archlinux.org/packages.php?ID=42272 AUR]<br />
<br />
===Initializing configuration===<br />
The policy must first be initialized:<br />
# /usr/lib/tomoyo/init_policy<br />
The policy files are saved in the {{Filename|/etc/tomoyo/}} directory and can be edited by running:<br />
# tomoyo-editpolicy<br />
<br />
==Usage==<br />
It is important to consult the relevant documentation in order to use TOMOYO Linux or AKARI effectively:<br />
* [http://tomoyo.sourceforge.jp/documentation.html.en TOMOYO Linux documentation]<br />
* [http://akari.sourceforge.jp/index.html.en AKARI documentation]<br />
Run the policy editor to begin editing. If using TOMOYO Linux 1.x or AKARI, then ''ccs-tools'' should be used:<br />
# /usr/sbin/ccs-editpolicy<br />
If using TOMOYO Linux 2.x, then ''tomoyo-tools'' should be used:<br />
# /usr/sbin/tomoyo-editpolicy<br />
As the system runs, TOMOYO Linux will create domains and add them to the tree. The access analysis/restriction in TOMOYO Linux is applied via domains. Every process belongs to a single domain and the process will transit to a different domain whenever it executes a program. The name of a domain is a concatenated string expression for the process execution history. For example, the name of the domain which the kernel belongs to is "<kernel>"; the name of domain which {{Filename|/sbin/init}} invoked by the kernel belongs to is "<kernel> /sbin/init"; if {{Filename|/sbin/init}} invokes {{Filename|/etc/rc.d/rc}} then the domain it belongs to is "<kernel> /sbin/init /etc/rc.d/rc". You can suppress or initialize domain transitions as needed.<br />
<br />
Profiles can be assigned to each domain. There are four default profiles:<br />
<br />
{| border="1"<br />
| Disabled || Works as if regular kernel.<br />
|-<br />
| Learning || Do not reject an access request if it violates policy. Append the request to policy.<br />
|-<br />
| Permissive || Do not reject an access request if it violates policy. Do not append the request to policy.<br />
|-<br />
| Enforcing || Reject an access request if it violates policy. Do not append the request to policy.<br />
|}<br />
The learning profile can be used to analyse the system or a specific application. Once all of the desired access requests of a domain have been identified, the policy for that domain can be edited as required before selecting the enforcing profile. This can be done for any and all domains from the start of system boot.<br />
<br />
==References==<br />
* [http://tomoyo.sourceforge.jp/ TOMOYO Linux SourceForge page]<br />
* [http://tomoyo.sourceforge.jp/wiki-e/ TOMOYO Linux Wiki]<br />
* [http://akari.sourceforge.jp/index.html.en AKARI SourceForge page]<br />
* [http://akari.sourceforge.jp/index.html.en AKARI documentation]<br />
* [http://tomoyo.sourceforge.jp/1.8/index.html.en TOMOYO Linux 1.8.x documentation]<br />
* [http://tomoyo.sourceforge.jp/2.3/index.html.en TOMOYO Linux 2.3.x documentation]<br />
* [http://lwn.net/Articles/263179/ TOMOYO Linux Security Goal]<br />
* [http://tomoyo.sourceforge.jp/cgi-bin/lxr/source/centos5.5/domain_policy.conf?v=policy-sample Policy sample]<br />
* [http://elinux.org/TomoyoLinux TOMOYO Linux on the Embedded Linux Wiki]<br />
* [http://sourceforge.jp/projects/tomoyo/document/PacSec2007-en-demo.pdf Presentation slides from PacSec 2007]<br />
<br />
==See also==<br />
* [[AppArmor]]<br />
* [[SELinux]]</div>Jnguyenhttps://wiki.archlinux.org/index.php?title=TOMOYO_Linux&diff=163025TOMOYO Linux2011-09-30T09:15:29Z<p>Jnguyen: remove "out of date"</p>
<hr />
<div>[[Category:Security (English)]]<br />
[[Category:Kernel (English)]]<br />
[[Category:Networking (English)]]<br />
{{i18n|TOMOYO Linux}}<br />
[http://tomoyo.sourceforge.jp/ TOMOYO Linux] is Mandatory Access Control (MAC) implementation for Linux. It was launched in March 2003 and is sponsored by [http://www.nttdata.co.jp/en/ NTT Data Corporation]. TOMOYO Linux focuses on the behaviour of a system, allowing each process to declare behaviours and resources needed to achieve its purpose. It can be used as a system analysis tool as well as an access restriction tool.<br />
<br />
The security goal of TOMOYO Linux is to provide "MAC that covers practical requirements for most users and keeps usable for most administrators". TOMOYO Linux is not a tool or security professional but for average users and administrators.<br />
{{Note|This article does not aim to be an exhaustive guide and should be used as a supplement to the extensive [http://tomoyo.sourceforge.jp/documentation.html user documentation] provided by the project.}}<br />
{{Tip|The [[#TOMOYO Linux 2.x|TOMOYO Linux 2.x]] branch is already in the Arch Linux [community] repository. This branch will eventually come closer to reaching feature parity with the 1.x branch, but for those wanting an easy start the 2.x branch is easy to install. The [[#TOMOYO Linux 1.x|TOMOYO Linux 1.x]] branch is for those wanting the greatest security, while [[#AKARI|AKARI]] is somewhere in between.}}<br />
<br />
==Introduction==<br />
TOMOYO Linux attempts to make the system where everything is prearranged in an easy to understand way:<br />
* Make all access requests that will occur at least once during the lifetime of the kernel known in advance<br />
* Allow the administrator to write a policy that only allows expected and desirable access requests<br />
Unlike AppArmor, TOMOYO Linux is intended to protect the whole system from attackers exploiting vulnerabilities in applications. TOMOYO Linux addresses this threat by recording the behaviour of all applications in the test environment and then forcing all applications to act within these recorded behaviours in the production environment.<br />
<br />
TOMOYO Linux is not for users wanting ready-made policy files supplied by others. It involves creating policy from scratch, aided by the "learning mode" which can automatically generate policy files with necessary and sufficient permissions for a specific system. TOMOYO Linux reports what is happening within the Linux system and can therefore be used as a system analysis tool. It resembles strace and reports what is being executed by each program and what files/networks are accessed.<br />
<br />
This [http://tomoyo.sourceforge.jp/wiki-e/?WhatIs#comparison table] provides a comprehensive comparison of TOMOYO Linux with [[AppArmor]], [[SELinux]] and [http://schaufler-ca.com/ SMACK].<br />
<br />
==Branches of development==<br />
[http://tomoyo.sourceforge.jp/1.8/index.html.en TOMOYO Linux 1.x] is the original branch of development. TOMOYO Linux was first released on 11th November 2005. It was implemented as a patch that can be applied to the Linux kernel and is still in active development. It can coexist with other security modules such as SELinux, SMACK and AppArmor.<br />
<br />
[http://tomoyo.sourceforge.jp/2.3/index.html.en TOMOYO Linux 2.x] is the Linux mainline kernel branch of development. In June 2009, TOMOYO was merged into the Linux kernel version 2.6.30 and it uses standard Linux Security Module (LSM) hooks. However, the LSM hooks must be extended further in order to port the full MAC functionality of TOMOYO Linux into the Linux kernel. Thus, it does not yet provide equal functionality with the 1.x branch of development. This [http://tomoyo.sourceforge.jp/comparison.html.en chart] compares the differences between each branch.<br />
<br />
[http://akari.sourceforge.jp/ AKARI] is based on the TOMOYO Linux 1.x branch and is implemented as a Loadable Kernel Module (LKM). It therefore has the advantage of not requiring the user to patch and recompile the kernel. This [http://akari.sourceforge.jp/comparison.html table] provides a comprehensive comparison of AKARI with the TOMOYO Linux 1.x and 2.x branches.<br />
<br />
==TOMOYO Linux 1.x==<br />
Implementing TOMOYO Linux 1.x using a kernel patched with ccs-patch provides the full functionality obtainable from the TOMOYO Linux project. However, implementation of this branch requires the most hurdles to be overcome, as the kernel must be patched with [http://sourceforge.jp/projects/tomoyo/ ccs-patch] and subsequently recompiled.<br />
<br />
Both ''linux-ccs'' and the userspace tools must be installed. A package for [https://aur.archlinux.org/packages.php?ID=51669 linux-ccs] and a package for [http://aur.archlinux.org/packages.php?ID=42606 ccs-tools] are available on the AUR.<br />
<br />
===Initializing configuration===<br />
The policy must first be initialized:<br />
# /usr/lib/ccs/init_policy<br />
The policy files are saved in the {{Filename|/etc/css/}} directory and can be edited by running:<br />
# ccs-editpolicy<br />
<br />
==AKARI==<br />
===Limitations of AKARI===<br />
AKARI has the advantage of not requiring kernel recompilation. If using the TOMOYO Linux project purely for system analysis, then AKARI is the easiest method of achieving this. If using the TOMOYO Linux project for system restriction, it is a minimal effort way to gain most of the functionality of the TOMOYO Linux 1.x branch. However, there are a few limitations that must be considered:<br />
* It depends on the kernel version and configuration provided by the distribution:<br />
<pre><br />
CONFIG_SECURITY=y [required]<br />
CONFIG_KALLSYMS=y [required]<br />
CONFIG_PROC_FS=y [required]<br />
CONFIG_MODULES=y [required]<br />
CONFIG_SECURITY_PATH=y [optional: for using absolute pathnames]<br />
CONFIG_SECURITY_NETWORK=y [optional: for providing network restriction]<br />
</pre><br />
* The restriction of a few advanced networking operations are limited or unavailable due to the absence of required LSM hooks<br />
* Restricting use of [http://en.wikipedia.org/wiki/Capability-based_security capabilities] is not possible<br />
* Looking up per-task variables is slower as they are managed outside "struct task_struct" in order to keep KABI unchanged. However, this should not be noticeable for the typical end-user as performance decrease by pathname based permission checking is dominant<br />
This [http://akari.sourceforge.jp/comparison.html table] provides a comprehensive comparison of AKARI with the TOMOYO Linux 1.x and 2.x branches.<br />
<br />
{{Note|The Arch Linux kernel from 2.6.36 onwards provides all of the configuration options required for full functionality.}}<br />
<br />
===Installation===<br />
Both AKARI and the userspace tools must be installed. A package for [http://aur.archlinux.org/packages.php?ID=42608 AKARI] and a package for [http://aur.archlinux.org/packages.php?ID=42606 ccs-tools] are available on the AUR.<br />
<br />
The bootloader configuration must be changed in order to activate AKARI:<br />
title Arch Linux<br />
root (hd0,0)<br />
kernel /boot/vmlinuz-linux root=/dev/sda1 ro init=/sbin/ccs-init<br />
initrd /boot/initramfs-linux.img<br />
<br />
===Initializing configuration===<br />
The policy must first be initialized:<br />
# /usr/lib/ccs/init_policy --module_name=akari<br />
The policy files are saved in the {{Filename|/etc/css/}} directory and can be edited by running:<br />
# ccs-editpolicy<br />
<br />
==TOMOYO Linux 2.x==<br />
===Limitations of TOMOYO Linux 2.x===<br />
The implementation of TOMOYO Linux 2.x into the Linux mainline kernel is not yet complete but is still effective for MAC of files. There are a few features that still need to be implemented as compared to the 1.x branch. This [http://tomoyo.sourceforge.jp/comparison.html.en chart] has a comprehensive comparison of the differences between each branch of development.<br />
<br />
===Installation===<br />
TOMOYO Linux 2.x is part of the Linux mainline kernel and, in addition to those previously mentioned, requires the following kernel configuration:<br />
CONFIG_SECURITY_TOMOYO=y<br />
{{note|The Arch Linux kernel from 2.6.36 onwards provides all of the configuration options required for full functionality.}}<br />
<br />
If the kernel supports TOMOYO Linux 2.x, then only the userspace tools need to be installed:<br />
<br />
<pre><br />
pacman -S tomoyo-tools<br />
</pre><br />
<br />
For kernel versions between 2.6.30 and 2.6.35, tomoyo-tools 2.2.x should be installed. A package is available on the [http://aur.archlinux.org/packages.php?ID=42272 AUR]<br />
<br />
===Initializing configuration===<br />
The policy must first be initialized:<br />
# /usr/lib/tomoyo/init_policy<br />
The policy files are saved in the {{Filename|/etc/tomoyo/}} directory and can be edited by running:<br />
# tomoyo-editpolicy<br />
<br />
==Usage==<br />
It is important to consult the relevant documentation in order to use TOMOYO Linux or AKARI effectively:<br />
* [http://tomoyo.sourceforge.jp/documentation.html.en TOMOYO Linux documentation]<br />
* [http://akari.sourceforge.jp/index.html.en AKARI documentation]<br />
Run the policy editor to begin editing. If using TOMOYO Linux 1.x or AKARI, then ''ccs-tools'' should be used:<br />
# /usr/sbin/ccs-editpolicy<br />
If using TOMOYO Linux 2.x, then ''tomoyo-tools'' should be used:<br />
# /usr/sbin/tomoyo-editpolicy<br />
As the system runs, TOMOYO Linux will create domains and add them to the tree. The access analysis/restriction in TOMOYO Linux is applied via domains. Every process belongs to a single domain and the process will transit to a different domain whenever it executes a program. The name of a domain is a concatenated string expression for the process execution history. For example, the name of the domain which the kernel belongs to is "<kernel>"; the name of domain which {{Filename|/sbin/init}} invoked by the kernel belongs to is "<kernel> /sbin/init"; if {{Filename|/sbin/init}} invokes {{Filename|/etc/rc.d/rc}} then the domain it belongs to is "<kernel> /sbin/init /etc/rc.d/rc". You can suppress or initialize domain transitions as needed.<br />
<br />
Profiles can be assigned to each domain. There are four default profiles:<br />
<br />
{| border="1"<br />
| Disabled || Works as if regular kernel.<br />
|-<br />
| Learning || Do not reject an access request if it violates policy. Append the request to policy.<br />
|-<br />
| Permissive || Do not reject an access request if it violates policy. Do not append the request to policy.<br />
|-<br />
| Enforcing || Reject an access request if it violates policy. Do not append the request to policy.<br />
|}<br />
The learning profile can be used to analyse the system or a specific application. Once all of the desired access requests of a domain have been identified, the policy for that domain can be edited as required before selecting the enforcing profile. This can be done for any and all domains from the start of system boot.<br />
<br />
==References==<br />
* [http://tomoyo.sourceforge.jp/ TOMOYO Linux SourceForge page]<br />
* [http://tomoyo.sourceforge.jp/wiki-e/ TOMOYO Linux Wiki]<br />
* [http://akari.sourceforge.jp/index.html.en AKARI SourceForge page]<br />
* [http://akari.sourceforge.jp/index.html.en AKARI documentation]<br />
* [http://tomoyo.sourceforge.jp/1.8/index.html.en TOMOYO Linux 1.8.x documentation]<br />
* [http://tomoyo.sourceforge.jp/2.3/index.html.en TOMOYO Linux 2.3.x documentation]<br />
* [http://lwn.net/Articles/263179/ TOMOYO Linux Security Goal]<br />
* [http://tomoyo.sourceforge.jp/cgi-bin/lxr/source/centos5.5/domain_policy.conf?v=policy-sample Policy sample]<br />
* [http://elinux.org/TomoyoLinux TOMOYO Linux on the Embedded Linux Wiki]<br />
* [http://sourceforge.jp/projects/tomoyo/document/PacSec2007-en-demo.pdf Presentation slides from PacSec 2007]<br />
<br />
==See also==<br />
* [[AppArmor]]<br />
* [[SELinux]]</div>Jnguyenhttps://wiki.archlinux.org/index.php?title=TOMOYO_Linux&diff=163024TOMOYO Linux2011-09-30T09:14:08Z<p>Jnguyen: /* TOMOYO Linux 1.x */ kernel26-ccs renamed to linux-ccs</p>
<hr />
<div>[[Category:Security (English)]]<br />
[[Category:Kernel (English)]]<br />
[[Category:Networking (English)]]<br />
{{i18n|TOMOYO Linux}}<br />
{{out of date|reason=kernel26-css doesn't exist}}<br />
[http://tomoyo.sourceforge.jp/ TOMOYO Linux] is Mandatory Access Control (MAC) implementation for Linux. It was launched in March 2003 and is sponsored by [http://www.nttdata.co.jp/en/ NTT Data Corporation]. TOMOYO Linux focuses on the behaviour of a system, allowing each process to declare behaviours and resources needed to achieve its purpose. It can be used as a system analysis tool as well as an access restriction tool.<br />
<br />
The security goal of TOMOYO Linux is to provide "MAC that covers practical requirements for most users and keeps usable for most administrators". TOMOYO Linux is not a tool or security professional but for average users and administrators.<br />
{{Note|This article does not aim to be an exhaustive guide and should be used as a supplement to the extensive [http://tomoyo.sourceforge.jp/documentation.html user documentation] provided by the project.}}<br />
{{Tip|The [[#TOMOYO Linux 2.x|TOMOYO Linux 2.x]] branch is already in the Arch Linux [community] repository. This branch will eventually come closer to reaching feature parity with the 1.x branch, but for those wanting an easy start the 2.x branch is easy to install. The [[#TOMOYO Linux 1.x|TOMOYO Linux 1.x]] branch is for those wanting the greatest security, while [[#AKARI|AKARI]] is somewhere in between.}}<br />
<br />
==Introduction==<br />
TOMOYO Linux attempts to make the system where everything is prearranged in an easy to understand way:<br />
* Make all access requests that will occur at least once during the lifetime of the kernel known in advance<br />
* Allow the administrator to write a policy that only allows expected and desirable access requests<br />
Unlike AppArmor, TOMOYO Linux is intended to protect the whole system from attackers exploiting vulnerabilities in applications. TOMOYO Linux addresses this threat by recording the behaviour of all applications in the test environment and then forcing all applications to act within these recorded behaviours in the production environment.<br />
<br />
TOMOYO Linux is not for users wanting ready-made policy files supplied by others. It involves creating policy from scratch, aided by the "learning mode" which can automatically generate policy files with necessary and sufficient permissions for a specific system. TOMOYO Linux reports what is happening within the Linux system and can therefore be used as a system analysis tool. It resembles strace and reports what is being executed by each program and what files/networks are accessed.<br />
<br />
This [http://tomoyo.sourceforge.jp/wiki-e/?WhatIs#comparison table] provides a comprehensive comparison of TOMOYO Linux with [[AppArmor]], [[SELinux]] and [http://schaufler-ca.com/ SMACK].<br />
<br />
==Branches of development==<br />
[http://tomoyo.sourceforge.jp/1.8/index.html.en TOMOYO Linux 1.x] is the original branch of development. TOMOYO Linux was first released on 11th November 2005. It was implemented as a patch that can be applied to the Linux kernel and is still in active development. It can coexist with other security modules such as SELinux, SMACK and AppArmor.<br />
<br />
[http://tomoyo.sourceforge.jp/2.3/index.html.en TOMOYO Linux 2.x] is the Linux mainline kernel branch of development. In June 2009, TOMOYO was merged into the Linux kernel version 2.6.30 and it uses standard Linux Security Module (LSM) hooks. However, the LSM hooks must be extended further in order to port the full MAC functionality of TOMOYO Linux into the Linux kernel. Thus, it does not yet provide equal functionality with the 1.x branch of development. This [http://tomoyo.sourceforge.jp/comparison.html.en chart] compares the differences between each branch.<br />
<br />
[http://akari.sourceforge.jp/ AKARI] is based on the TOMOYO Linux 1.x branch and is implemented as a Loadable Kernel Module (LKM). It therefore has the advantage of not requiring the user to patch and recompile the kernel. This [http://akari.sourceforge.jp/comparison.html table] provides a comprehensive comparison of AKARI with the TOMOYO Linux 1.x and 2.x branches.<br />
<br />
==TOMOYO Linux 1.x==<br />
Implementing TOMOYO Linux 1.x using a kernel patched with ccs-patch provides the full functionality obtainable from the TOMOYO Linux project. However, implementation of this branch requires the most hurdles to be overcome, as the kernel must be patched with [http://sourceforge.jp/projects/tomoyo/ ccs-patch] and subsequently recompiled.<br />
<br />
Both ''linux-ccs'' and the userspace tools must be installed. A package for [https://aur.archlinux.org/packages.php?ID=51669 linux-ccs] and a package for [http://aur.archlinux.org/packages.php?ID=42606 ccs-tools] are available on the AUR.<br />
<br />
===Initializing configuration===<br />
The policy must first be initialized:<br />
# /usr/lib/ccs/init_policy<br />
The policy files are saved in the {{Filename|/etc/css/}} directory and can be edited by running:<br />
# ccs-editpolicy<br />
<br />
==AKARI==<br />
===Limitations of AKARI===<br />
AKARI has the advantage of not requiring kernel recompilation. If using the TOMOYO Linux project purely for system analysis, then AKARI is the easiest method of achieving this. If using the TOMOYO Linux project for system restriction, it is a minimal effort way to gain most of the functionality of the TOMOYO Linux 1.x branch. However, there are a few limitations that must be considered:<br />
* It depends on the kernel version and configuration provided by the distribution:<br />
<pre><br />
CONFIG_SECURITY=y [required]<br />
CONFIG_KALLSYMS=y [required]<br />
CONFIG_PROC_FS=y [required]<br />
CONFIG_MODULES=y [required]<br />
CONFIG_SECURITY_PATH=y [optional: for using absolute pathnames]<br />
CONFIG_SECURITY_NETWORK=y [optional: for providing network restriction]<br />
</pre><br />
* The restriction of a few advanced networking operations are limited or unavailable due to the absence of required LSM hooks<br />
* Restricting use of [http://en.wikipedia.org/wiki/Capability-based_security capabilities] is not possible<br />
* Looking up per-task variables is slower as they are managed outside "struct task_struct" in order to keep KABI unchanged. However, this should not be noticeable for the typical end-user as performance decrease by pathname based permission checking is dominant<br />
This [http://akari.sourceforge.jp/comparison.html table] provides a comprehensive comparison of AKARI with the TOMOYO Linux 1.x and 2.x branches.<br />
<br />
{{Note|The Arch Linux kernel from 2.6.36 onwards provides all of the configuration options required for full functionality.}}<br />
<br />
===Installation===<br />
Both AKARI and the userspace tools must be installed. A package for [http://aur.archlinux.org/packages.php?ID=42608 AKARI] and a package for [http://aur.archlinux.org/packages.php?ID=42606 ccs-tools] are available on the AUR.<br />
<br />
The bootloader configuration must be changed in order to activate AKARI:<br />
title Arch Linux<br />
root (hd0,0)<br />
kernel /boot/vmlinuz-linux root=/dev/sda1 ro init=/sbin/ccs-init<br />
initrd /boot/initramfs-linux.img<br />
<br />
===Initializing configuration===<br />
The policy must first be initialized:<br />
# /usr/lib/ccs/init_policy --module_name=akari<br />
The policy files are saved in the {{Filename|/etc/css/}} directory and can be edited by running:<br />
# ccs-editpolicy<br />
<br />
==TOMOYO Linux 2.x==<br />
===Limitations of TOMOYO Linux 2.x===<br />
The implementation of TOMOYO Linux 2.x into the Linux mainline kernel is not yet complete but is still effective for MAC of files. There are a few features that still need to be implemented as compared to the 1.x branch. This [http://tomoyo.sourceforge.jp/comparison.html.en chart] has a comprehensive comparison of the differences between each branch of development.<br />
<br />
===Installation===<br />
TOMOYO Linux 2.x is part of the Linux mainline kernel and, in addition to those previously mentioned, requires the following kernel configuration:<br />
CONFIG_SECURITY_TOMOYO=y<br />
{{note|The Arch Linux kernel from 2.6.36 onwards provides all of the configuration options required for full functionality.}}<br />
<br />
If the kernel supports TOMOYO Linux 2.x, then only the userspace tools need to be installed:<br />
<br />
<pre><br />
pacman -S tomoyo-tools<br />
</pre><br />
<br />
For kernel versions between 2.6.30 and 2.6.35, tomoyo-tools 2.2.x should be installed. A package is available on the [http://aur.archlinux.org/packages.php?ID=42272 AUR]<br />
<br />
===Initializing configuration===<br />
The policy must first be initialized:<br />
# /usr/lib/tomoyo/init_policy<br />
The policy files are saved in the {{Filename|/etc/tomoyo/}} directory and can be edited by running:<br />
# tomoyo-editpolicy<br />
<br />
==Usage==<br />
It is important to consult the relevant documentation in order to use TOMOYO Linux or AKARI effectively:<br />
* [http://tomoyo.sourceforge.jp/documentation.html.en TOMOYO Linux documentation]<br />
* [http://akari.sourceforge.jp/index.html.en AKARI documentation]<br />
Run the policy editor to begin editing. If using TOMOYO Linux 1.x or AKARI, then ''ccs-tools'' should be used:<br />
# /usr/sbin/ccs-editpolicy<br />
If using TOMOYO Linux 2.x, then ''tomoyo-tools'' should be used:<br />
# /usr/sbin/tomoyo-editpolicy<br />
As the system runs, TOMOYO Linux will create domains and add them to the tree. The access analysis/restriction in TOMOYO Linux is applied via domains. Every process belongs to a single domain and the process will transit to a different domain whenever it executes a program. The name of a domain is a concatenated string expression for the process execution history. For example, the name of the domain which the kernel belongs to is "<kernel>"; the name of domain which {{Filename|/sbin/init}} invoked by the kernel belongs to is "<kernel> /sbin/init"; if {{Filename|/sbin/init}} invokes {{Filename|/etc/rc.d/rc}} then the domain it belongs to is "<kernel> /sbin/init /etc/rc.d/rc". You can suppress or initialize domain transitions as needed.<br />
<br />
Profiles can be assigned to each domain. There are four default profiles:<br />
<br />
{| border="1"<br />
| Disabled || Works as if regular kernel.<br />
|-<br />
| Learning || Do not reject an access request if it violates policy. Append the request to policy.<br />
|-<br />
| Permissive || Do not reject an access request if it violates policy. Do not append the request to policy.<br />
|-<br />
| Enforcing || Reject an access request if it violates policy. Do not append the request to policy.<br />
|}<br />
The learning profile can be used to analyse the system or a specific application. Once all of the desired access requests of a domain have been identified, the policy for that domain can be edited as required before selecting the enforcing profile. This can be done for any and all domains from the start of system boot.<br />
<br />
==References==<br />
* [http://tomoyo.sourceforge.jp/ TOMOYO Linux SourceForge page]<br />
* [http://tomoyo.sourceforge.jp/wiki-e/ TOMOYO Linux Wiki]<br />
* [http://akari.sourceforge.jp/index.html.en AKARI SourceForge page]<br />
* [http://akari.sourceforge.jp/index.html.en AKARI documentation]<br />
* [http://tomoyo.sourceforge.jp/1.8/index.html.en TOMOYO Linux 1.8.x documentation]<br />
* [http://tomoyo.sourceforge.jp/2.3/index.html.en TOMOYO Linux 2.3.x documentation]<br />
* [http://lwn.net/Articles/263179/ TOMOYO Linux Security Goal]<br />
* [http://tomoyo.sourceforge.jp/cgi-bin/lxr/source/centos5.5/domain_policy.conf?v=policy-sample Policy sample]<br />
* [http://elinux.org/TomoyoLinux TOMOYO Linux on the Embedded Linux Wiki]<br />
* [http://sourceforge.jp/projects/tomoyo/document/PacSec2007-en-demo.pdf Presentation slides from PacSec 2007]<br />
<br />
==See also==<br />
* [[AppArmor]]<br />
* [[SELinux]]</div>Jnguyenhttps://wiki.archlinux.org/index.php?title=TOMOYO_Linux&diff=163023TOMOYO Linux2011-09-30T09:11:57Z<p>Jnguyen: /* Limitations of TOMOYO Linux 2.x */</p>
<hr />
<div>[[Category:Security (English)]]<br />
[[Category:Kernel (English)]]<br />
[[Category:Networking (English)]]<br />
{{i18n|TOMOYO Linux}}<br />
{{out of date|reason=kernel26-css doesn't exist}}<br />
[http://tomoyo.sourceforge.jp/ TOMOYO Linux] is Mandatory Access Control (MAC) implementation for Linux. It was launched in March 2003 and is sponsored by [http://www.nttdata.co.jp/en/ NTT Data Corporation]. TOMOYO Linux focuses on the behaviour of a system, allowing each process to declare behaviours and resources needed to achieve its purpose. It can be used as a system analysis tool as well as an access restriction tool.<br />
<br />
The security goal of TOMOYO Linux is to provide "MAC that covers practical requirements for most users and keeps usable for most administrators". TOMOYO Linux is not a tool or security professional but for average users and administrators.<br />
{{Note|This article does not aim to be an exhaustive guide and should be used as a supplement to the extensive [http://tomoyo.sourceforge.jp/documentation.html user documentation] provided by the project.}}<br />
{{Tip|The [[#TOMOYO Linux 2.x|TOMOYO Linux 2.x]] branch is already in the Arch Linux [community] repository. This branch will eventually come closer to reaching feature parity with the 1.x branch, but for those wanting an easy start the 2.x branch is easy to install. The [[#TOMOYO Linux 1.x|TOMOYO Linux 1.x]] branch is for those wanting the greatest security, while [[#AKARI|AKARI]] is somewhere in between.}}<br />
<br />
==Introduction==<br />
TOMOYO Linux attempts to make the system where everything is prearranged in an easy to understand way:<br />
* Make all access requests that will occur at least once during the lifetime of the kernel known in advance<br />
* Allow the administrator to write a policy that only allows expected and desirable access requests<br />
Unlike AppArmor, TOMOYO Linux is intended to protect the whole system from attackers exploiting vulnerabilities in applications. TOMOYO Linux addresses this threat by recording the behaviour of all applications in the test environment and then forcing all applications to act within these recorded behaviours in the production environment.<br />
<br />
TOMOYO Linux is not for users wanting ready-made policy files supplied by others. It involves creating policy from scratch, aided by the "learning mode" which can automatically generate policy files with necessary and sufficient permissions for a specific system. TOMOYO Linux reports what is happening within the Linux system and can therefore be used as a system analysis tool. It resembles strace and reports what is being executed by each program and what files/networks are accessed.<br />
<br />
This [http://tomoyo.sourceforge.jp/wiki-e/?WhatIs#comparison table] provides a comprehensive comparison of TOMOYO Linux with [[AppArmor]], [[SELinux]] and [http://schaufler-ca.com/ SMACK].<br />
<br />
==Branches of development==<br />
[http://tomoyo.sourceforge.jp/1.8/index.html.en TOMOYO Linux 1.x] is the original branch of development. TOMOYO Linux was first released on 11th November 2005. It was implemented as a patch that can be applied to the Linux kernel and is still in active development. It can coexist with other security modules such as SELinux, SMACK and AppArmor.<br />
<br />
[http://tomoyo.sourceforge.jp/2.3/index.html.en TOMOYO Linux 2.x] is the Linux mainline kernel branch of development. In June 2009, TOMOYO was merged into the Linux kernel version 2.6.30 and it uses standard Linux Security Module (LSM) hooks. However, the LSM hooks must be extended further in order to port the full MAC functionality of TOMOYO Linux into the Linux kernel. Thus, it does not yet provide equal functionality with the 1.x branch of development. This [http://tomoyo.sourceforge.jp/comparison.html.en chart] compares the differences between each branch.<br />
<br />
[http://akari.sourceforge.jp/ AKARI] is based on the TOMOYO Linux 1.x branch and is implemented as a Loadable Kernel Module (LKM). It therefore has the advantage of not requiring the user to patch and recompile the kernel. This [http://akari.sourceforge.jp/comparison.html table] provides a comprehensive comparison of AKARI with the TOMOYO Linux 1.x and 2.x branches.<br />
<br />
==TOMOYO Linux 1.x==<br />
Implementing TOMOYO Linux 1.x using a kernel patched with ccs-patch provides the full functionality obtainable from the TOMOYO Linux project. However, implementation of this branch requires the most hurdles to be overcome, as the kernel must be patched with [http://sourceforge.jp/projects/tomoyo/ ccs-patch] and subsequently recompiled.<br />
<br />
Both ''kernel26-ccs'' and the userspace tools must be installed. A package for [http://aur.archlinux.org/packages.php?ID=44131 kernel-ccs] and a package for [http://aur.archlinux.org/packages.php?ID=42606 ccs-tools] are available on the AUR.<br />
<br />
===Initializing configuration===<br />
The policy must first be initialized:<br />
# /usr/lib/ccs/init_policy<br />
The policy files are saved in the {{Filename|/etc/css/}} directory and can be edited by running:<br />
# ccs-editpolicy<br />
<br />
==AKARI==<br />
===Limitations of AKARI===<br />
AKARI has the advantage of not requiring kernel recompilation. If using the TOMOYO Linux project purely for system analysis, then AKARI is the easiest method of achieving this. If using the TOMOYO Linux project for system restriction, it is a minimal effort way to gain most of the functionality of the TOMOYO Linux 1.x branch. However, there are a few limitations that must be considered:<br />
* It depends on the kernel version and configuration provided by the distribution:<br />
<pre><br />
CONFIG_SECURITY=y [required]<br />
CONFIG_KALLSYMS=y [required]<br />
CONFIG_PROC_FS=y [required]<br />
CONFIG_MODULES=y [required]<br />
CONFIG_SECURITY_PATH=y [optional: for using absolute pathnames]<br />
CONFIG_SECURITY_NETWORK=y [optional: for providing network restriction]<br />
</pre><br />
* The restriction of a few advanced networking operations are limited or unavailable due to the absence of required LSM hooks<br />
* Restricting use of [http://en.wikipedia.org/wiki/Capability-based_security capabilities] is not possible<br />
* Looking up per-task variables is slower as they are managed outside "struct task_struct" in order to keep KABI unchanged. However, this should not be noticeable for the typical end-user as performance decrease by pathname based permission checking is dominant<br />
This [http://akari.sourceforge.jp/comparison.html table] provides a comprehensive comparison of AKARI with the TOMOYO Linux 1.x and 2.x branches.<br />
<br />
{{Note|The Arch Linux kernel from 2.6.36 onwards provides all of the configuration options required for full functionality.}}<br />
<br />
===Installation===<br />
Both AKARI and the userspace tools must be installed. A package for [http://aur.archlinux.org/packages.php?ID=42608 AKARI] and a package for [http://aur.archlinux.org/packages.php?ID=42606 ccs-tools] are available on the AUR.<br />
<br />
The bootloader configuration must be changed in order to activate AKARI:<br />
title Arch Linux<br />
root (hd0,0)<br />
kernel /boot/vmlinuz-linux root=/dev/sda1 ro init=/sbin/ccs-init<br />
initrd /boot/initramfs-linux.img<br />
<br />
===Initializing configuration===<br />
The policy must first be initialized:<br />
# /usr/lib/ccs/init_policy --module_name=akari<br />
The policy files are saved in the {{Filename|/etc/css/}} directory and can be edited by running:<br />
# ccs-editpolicy<br />
<br />
==TOMOYO Linux 2.x==<br />
===Limitations of TOMOYO Linux 2.x===<br />
The implementation of TOMOYO Linux 2.x into the Linux mainline kernel is not yet complete but is still effective for MAC of files. There are a few features that still need to be implemented as compared to the 1.x branch. This [http://tomoyo.sourceforge.jp/comparison.html.en chart] has a comprehensive comparison of the differences between each branch of development.<br />
<br />
===Installation===<br />
TOMOYO Linux 2.x is part of the Linux mainline kernel and, in addition to those previously mentioned, requires the following kernel configuration:<br />
CONFIG_SECURITY_TOMOYO=y<br />
{{note|The Arch Linux kernel from 2.6.36 onwards provides all of the configuration options required for full functionality.}}<br />
<br />
If the kernel supports TOMOYO Linux 2.x, then only the userspace tools need to be installed:<br />
<br />
<pre><br />
pacman -S tomoyo-tools<br />
</pre><br />
<br />
For kernel versions between 2.6.30 and 2.6.35, tomoyo-tools 2.2.x should be installed. A package is available on the [http://aur.archlinux.org/packages.php?ID=42272 AUR]<br />
<br />
===Initializing configuration===<br />
The policy must first be initialized:<br />
# /usr/lib/tomoyo/init_policy<br />
The policy files are saved in the {{Filename|/etc/tomoyo/}} directory and can be edited by running:<br />
# tomoyo-editpolicy<br />
<br />
==Usage==<br />
It is important to consult the relevant documentation in order to use TOMOYO Linux or AKARI effectively:<br />
* [http://tomoyo.sourceforge.jp/documentation.html.en TOMOYO Linux documentation]<br />
* [http://akari.sourceforge.jp/index.html.en AKARI documentation]<br />
Run the policy editor to begin editing. If using TOMOYO Linux 1.x or AKARI, then ''ccs-tools'' should be used:<br />
# /usr/sbin/ccs-editpolicy<br />
If using TOMOYO Linux 2.x, then ''tomoyo-tools'' should be used:<br />
# /usr/sbin/tomoyo-editpolicy<br />
As the system runs, TOMOYO Linux will create domains and add them to the tree. The access analysis/restriction in TOMOYO Linux is applied via domains. Every process belongs to a single domain and the process will transit to a different domain whenever it executes a program. The name of a domain is a concatenated string expression for the process execution history. For example, the name of the domain which the kernel belongs to is "<kernel>"; the name of domain which {{Filename|/sbin/init}} invoked by the kernel belongs to is "<kernel> /sbin/init"; if {{Filename|/sbin/init}} invokes {{Filename|/etc/rc.d/rc}} then the domain it belongs to is "<kernel> /sbin/init /etc/rc.d/rc". You can suppress or initialize domain transitions as needed.<br />
<br />
Profiles can be assigned to each domain. There are four default profiles:<br />
<br />
{| border="1"<br />
| Disabled || Works as if regular kernel.<br />
|-<br />
| Learning || Do not reject an access request if it violates policy. Append the request to policy.<br />
|-<br />
| Permissive || Do not reject an access request if it violates policy. Do not append the request to policy.<br />
|-<br />
| Enforcing || Reject an access request if it violates policy. Do not append the request to policy.<br />
|}<br />
The learning profile can be used to analyse the system or a specific application. Once all of the desired access requests of a domain have been identified, the policy for that domain can be edited as required before selecting the enforcing profile. This can be done for any and all domains from the start of system boot.<br />
<br />
==References==<br />
* [http://tomoyo.sourceforge.jp/ TOMOYO Linux SourceForge page]<br />
* [http://tomoyo.sourceforge.jp/wiki-e/ TOMOYO Linux Wiki]<br />
* [http://akari.sourceforge.jp/index.html.en AKARI SourceForge page]<br />
* [http://akari.sourceforge.jp/index.html.en AKARI documentation]<br />
* [http://tomoyo.sourceforge.jp/1.8/index.html.en TOMOYO Linux 1.8.x documentation]<br />
* [http://tomoyo.sourceforge.jp/2.3/index.html.en TOMOYO Linux 2.3.x documentation]<br />
* [http://lwn.net/Articles/263179/ TOMOYO Linux Security Goal]<br />
* [http://tomoyo.sourceforge.jp/cgi-bin/lxr/source/centos5.5/domain_policy.conf?v=policy-sample Policy sample]<br />
* [http://elinux.org/TomoyoLinux TOMOYO Linux on the Embedded Linux Wiki]<br />
* [http://sourceforge.jp/projects/tomoyo/document/PacSec2007-en-demo.pdf Presentation slides from PacSec 2007]<br />
<br />
==See also==<br />
* [[AppArmor]]<br />
* [[SELinux]]</div>Jnguyenhttps://wiki.archlinux.org/index.php?title=TOMOYO_Linux&diff=153047TOMOYO Linux2011-08-23T09:32:27Z<p>Jnguyen: remove old information about repository</p>
<hr />
<div>[[Category:Security (English)]]<br />
[[Category:Kernel (English)]]<br />
[[Category:Networking (English)]]<br />
{{i18n|TOMOYO Linux}}<br />
[http://tomoyo.sourceforge.jp/ TOMOYO Linux] is Mandatory Access Control (MAC) implementation for Linux. It was launched in March 2003 and is sponsored by [http://www.nttdata.co.jp/en/ NTT Data Corporation]. TOMOYO Linux focuses on the behaviour of a system, allowing each process to declare behaviours and resources needed to achieve its purpose. It can be used as a system analysis tool as well as an access restriction tool.<br />
<br />
The security goal of TOMOYO Linux is to provide "MAC that covers practical requirements for most users and keeps usable for most administrators". TOMOYO Linux is not a tool or security professional but for average users and administrators.<br />
{{Note|This article does not aim to be an exhaustive guide and should be used as a supplement to the extensive [http://tomoyo.sourceforge.jp/documentation.html user documentation] provided by the project.}}<br />
{{Tip|The [[#TOMOYO Linux 2.x|TOMOYO Linux 2.x]] branch is already in the Arch Linux [community] repository. This branch will eventually come closer to reaching feature parity with the 1.x branch, but for those wanting an easy start the 2.x branch is easy to install. The [[#TOMOYO Linux 1.x|TOMOYO Linux 1.x]] branch is for those wanting the greatest security, while [[#AKARI|AKARI]] is somewhere in between.}}<br />
<br />
==Introduction==<br />
TOMOYO Linux attempts to make the system where everything is prearranged in an easy to understand way:<br />
* Make all access requests that will occur at least once during the lifetime of the kernel known in advance<br />
* Allow the administrator to write a policy that only allows expected and desirable access requests<br />
Unlike AppArmor, TOMOYO Linux is intended to protect the whole system from attackers exploiting vulnerabilities in applications. TOMOYO Linux addresses this threat by recording the behaviour of all applications in the test environment and then forcing all applications to act within these recorded behaviours in the production environment.<br />
<br />
TOMOYO Linux is not for users wanting ready-made policy files supplied by others. It involves creating policy from scratch, aided by the "learning mode" which can automatically generate policy files with necessary and sufficient permissions for a specific system. TOMOYO Linux reports what is happening within the Linux system and can therefore be used as a system analysis tool. It resembles strace and reports what is being executed by each program and what files/networks are accessed.<br />
<br />
This [http://tomoyo.sourceforge.jp/wiki-e/?WhatIs#comparison table] provides a comprehensive comparison of TOMOYO Linux with [[AppArmor]], [[SELinux]] and [http://schaufler-ca.com/ SMACK].<br />
<br />
==Branches of development==<br />
[http://tomoyo.sourceforge.jp/1.8/index.html.en TOMOYO Linux 1.x] is the original branch of development. TOMOYO Linux was first released on 11th November 2005. It was implemented as a patch that can be applied to the Linux kernel and is still in active development. It can coexist with other security modules such as SELinux, SMACK and AppArmor.<br />
<br />
[http://tomoyo.sourceforge.jp/2.3/index.html.en TOMOYO Linux 2.x] is the Linux mainline kernel branch of development. In June 2009, TOMOYO was merged into the Linux kernel version 2.6.30 and it uses standard Linux Security Module (LSM) hooks. However, the LSM hooks must be extended further in order to port the full MAC functionality of TOMOYO Linux into the Linux kernel. Thus, it does not yet provide equal functionality with the 1.x branch of development. This [http://tomoyo.sourceforge.jp/comparison.html.en chart] compares the differences between each branch.<br />
<br />
[http://akari.sourceforge.jp/ AKARI] is based on the TOMOYO Linux 1.x branch and is implemented as a Loadable Kernel Module (LKM). It therefore has the advantage of not requiring the user to patch and recompile the kernel. This [http://akari.sourceforge.jp/comparison.html table] provides a comprehensive comparison of AKARI with the TOMOYO Linux 1.x and 2.x branches.<br />
<br />
==TOMOYO Linux 1.x==<br />
Implementing TOMOYO Linux 1.x using a kernel patched with ccs-patch provides the full functionality obtainable from the TOMOYO Linux project. However, implementation of this branch requires the most hurdles to be overcome, as the kernel must be patched with [http://sourceforge.jp/projects/tomoyo/ ccs-patch] and subsequently recompiled.<br />
<br />
Both ''kernel26-ccs'' and the userspace tools must be installed. A package for [http://aur.archlinux.org/packages.php?ID=44131 kernel-ccs] and a package for [http://aur.archlinux.org/packages.php?ID=42606 ccs-tools] are available on the AUR.<br />
<br />
===Initializing configuration===<br />
The policy must first be initialized:<br />
# /usr/lib/ccs/init_policy<br />
The policy files are saved in the {{Filename|/etc/css/}} directory and can be edited by running:<br />
# ccs-editpolicy<br />
<br />
==AKARI==<br />
===Limitations of AKARI===<br />
AKARI has the advantage of not requiring kernel recompilation. If using the TOMOYO Linux project purely for system analysis, then AKARI is the easiest method of achieving this. If using the TOMOYO Linux project for system restriction, it is a minimal effort way to gain most of the functionality of the TOMOYO Linux 1.x branch. However, there are a few limitations that must be considered:<br />
* It depends on the kernel version and configuration provided by the distribution:<br />
<pre><br />
CONFIG_SECURITY=y [required]<br />
CONFIG_KALLSYMS=y [required]<br />
CONFIG_PROC_FS=y [required]<br />
CONFIG_MODULES=y [required]<br />
CONFIG_SECURITY_PATH=y [optional: for using absolute pathnames]<br />
CONFIG_SECURITY_NETWORK=y [optional: for providing network restriction]<br />
</pre><br />
* The restriction of a few advanced networking operations are limited or unavailable due to the absence of required LSM hooks<br />
* Restricting use of [http://en.wikipedia.org/wiki/Capability-based_security capabilities] is not possible<br />
* Looking up per-task variables is slower as they are managed outside "struct task_struct" in order to keep KABI unchanged. However, this should not be noticeable for the typical end-user as performance decrease by pathname based permission checking is dominant<br />
This [http://akari.sourceforge.jp/comparison.html table] provides a comprehensive comparison of AKARI with the TOMOYO Linux 1.x and 2.x branches.<br />
<br />
{{Note|The Arch Linux kernel from 2.6.36 onwards provides all of the configuration options required for full functionality.}}<br />
<br />
===Installation===<br />
Both AKARI and the userspace tools must be installed. A package for [http://aur.archlinux.org/packages.php?ID=42608 AKARI] and a package for [http://aur.archlinux.org/packages.php?ID=42606 ccs-tools] are available on the AUR.<br />
<br />
The bootloader configuration must be changed in order to activate AKARI:<br />
title Arch Linux<br />
root (hd0,0)<br />
kernel /boot/vmlinuz26 root=/dev/sda1 ro init=/sbin/ccs-init<br />
initrd /boot/kernel26.img<br />
<br />
===Initializing configuration===<br />
The policy must first be initialized:<br />
# /usr/lib/ccs/init_policy --module_name=akari<br />
The policy files are saved in the {{Filename|/etc/css/}} directory and can be edited by running:<br />
# ccs-editpolicy<br />
<br />
==TOMOYO Linux 2.x==<br />
===Limitations of TOMOYO Linux 2.x===<br />
The implementation of TOMOYO Linux 2.x into the Linux mainline kernel is not yet complete but is still effective for MAC of files. It does not yet support the restriction of:<br />
* file attribute and namespace manipulation<br />
* capabilities<br />
* network<br />
* signal<br />
* environment variables<br />
* local port reservation<br />
This [http://tomoyo.sourceforge.jp/comparison.html.en chart] has a more comprehensive comparison of the differences between each branch of development.<br />
<br />
===Installation===<br />
TOMOYO Linux 2.x is part of the Linux mainline kernel and, in addition to those previously mentioned, requires the following kernel configuration:<br />
CONFIG_SECURITY_TOMOYO=y<br />
{{note|The Arch Linux kernel from 2.6.36 onwards provides all of the configuration options required for full functionality.}}<br />
<br />
If the kernel supports TOMOYO Linux 2.x, then only the userspace tools need to be installed:<br />
<br />
<pre><br />
pacman -S tomoyo-tools<br />
</pre><br />
<br />
For kernel versions between 2.6.30 and 2.6.35, tomoyo-tools 2.2.x should be installed. A package is available on the [http://aur.archlinux.org/packages.php?ID=42272 AUR]<br />
<br />
===Initializing configuration===<br />
The policy must first be initialized:<br />
# /usr/lib/tomoyo/init_policy<br />
The policy files are saved in the {{Filename|/etc/tomoyo/}} directory and can be edited by running:<br />
# tomoyo-editpolicy<br />
<br />
==Usage==<br />
It is important to consult the relevant documentation in order to use TOMOYO Linux or AKARI effectively:<br />
* [http://tomoyo.sourceforge.jp/documentation.html.en TOMOYO Linux documentation]<br />
* [http://akari.sourceforge.jp/index.html.en AKARI documentation]<br />
Run the policy editor to begin editing. If using TOMOYO Linux 1.x or AKARI, then ''ccs-tools'' should be used:<br />
# /usr/sbin/ccs-editpolicy<br />
If using TOMOYO Linux 2.x, then ''tomoyo-tools'' should be used:<br />
# /usr/sbin/tomoyo-editpolicy<br />
As the system runs, TOMOYO Linux will create domains and add them to the tree. The access analysis/restriction in TOMOYO Linux is applied via domains. Every process belongs to a single domain and the process will transit to a different domain whenever it executes a program. The name of a domain is a concatenated string expression for the process execution history. For example, the name of the domain which the kernel belongs to is "<kernel>"; the name of domain which {{Filename|/sbin/init}} invoked by the kernel belongs to is "<kernel> /sbin/init"; if {{Filename|/sbin/init}} invokes {{Filename|/etc/rc.d/rc}} then the domain it belongs to is "<kernel> /sbin/init /etc/rc.d/rc". You can suppress or initialize domain transitions as needed.<br />
<br />
Profiles can be assigned to each domain. There are four default profiles:<br />
<br />
{| border="1"<br />
| Disabled || Works as if regular kernel.<br />
|-<br />
| Learning || Do not reject an access request if it violates policy. Append the request to policy.<br />
|-<br />
| Permissive || Do not reject an access request if it violates policy. Do not append the request to policy.<br />
|-<br />
| Enforcing || Reject an access request if it violates policy. Do not append the request to policy.<br />
|}<br />
The learning profile can be used to analyse the system or a specific application. Once all of the desired access requests of a domain have been identified, the policy for that domain can be edited as required before selecting the enforcing profile. This can be done for any and all domains from the start of system boot.<br />
<br />
==References==<br />
* [http://tomoyo.sourceforge.jp/ TOMOYO Linux SourceForge page]<br />
* [http://tomoyo.sourceforge.jp/wiki-e/ TOMOYO Linux Wiki]<br />
* [http://akari.sourceforge.jp/index.html.en AKARI SourceForge page]<br />
* [http://akari.sourceforge.jp/index.html.en AKARI documentation]<br />
* [http://tomoyo.sourceforge.jp/1.8/index.html.en TOMOYO Linux 1.8.x documentation]<br />
* [http://tomoyo.sourceforge.jp/2.3/index.html.en TOMOYO Linux 2.3.x documentation]<br />
* [http://lwn.net/Articles/263179/ TOMOYO Linux Security Goal]<br />
* [http://tomoyo.sourceforge.jp/cgi-bin/lxr/source/centos5.5/domain_policy.conf?v=policy-sample Policy sample]<br />
* [http://elinux.org/TomoyoLinux TOMOYO Linux on the Embedded Linux Wiki]<br />
* [http://sourceforge.jp/projects/tomoyo/document/PacSec2007-en-demo.pdf Presentation slides from PacSec 2007]<br />
<br />
==See also==<br />
* [[AppArmor]]<br />
* [[SELinux]]</div>Jnguyenhttps://wiki.archlinux.org/index.php?title=TOMOYO_Linux&diff=153046TOMOYO Linux2011-08-23T09:29:53Z<p>Jnguyen: remove old information about repository</p>
<hr />
<div>[[Category:Security (English)]]<br />
[[Category:Kernel (English)]]<br />
[[Category:Networking (English)]]<br />
{{i18n|TOMOYO Linux}}<br />
[http://tomoyo.sourceforge.jp/ TOMOYO Linux] is Mandatory Access Control (MAC) implementation for Linux. It was launched in March 2003 and is sponsored by [http://www.nttdata.co.jp/en/ NTT Data Corporation]. TOMOYO Linux focuses on the behaviour of a system, allowing each process to declare behaviours and resources needed to achieve its purpose. It can be used as a system analysis tool as well as an access restriction tool.<br />
<br />
The security goal of TOMOYO Linux is to provide "MAC that covers practical requirements for most users and keeps usable for most administrators". TOMOYO Linux is not a tool or security professional but for average users and administrators.<br />
{{Note|This article does not aim to be an exhaustive guide and should be used as a supplement to the extensive [http://tomoyo.sourceforge.jp/documentation.html user documentation] provided by the project.}}<br />
{{Tip|The [[#TOMOYO Linux 2.x|TOMOYO Linux 2.x]] branch is already in the Arch Linux [community] repository. This branch will eventually come closer to reaching feature parity with the 1.x branch, but for those wanting an easy start the 2.x branch is easy to install. The [[#TOMOYO Linux 1.x|TOMOYO Linux 1.x]] branch is for those wanting the greatest security, while [[#AKARI|AKARI]] is somewhere in between.}}<br />
<br />
==Introduction==<br />
TOMOYO Linux attempts to make the system where everything is prearranged in an easy to understand way:<br />
* Make all access requests that will occur at least once during the lifetime of the kernel known in advance<br />
* Allow the administrator to write a policy that only allows expected and desirable access requests<br />
Unlike AppArmor, TOMOYO Linux is intended to protect the whole system from attackers exploiting vulnerabilities in applications. TOMOYO Linux addresses this threat by recording the behaviour of all applications in the test environment and then forcing all applications to act within these recorded behaviours in the production environment.<br />
<br />
TOMOYO Linux is not for users wanting ready-made policy files supplied by others. It involves creating policy from scratch, aided by the "learning mode" which can automatically generate policy files with necessary and sufficient permissions for a specific system. TOMOYO Linux reports what is happening within the Linux system and can therefore be used as a system analysis tool. It resembles strace and reports what is being executed by each program and what files/networks are accessed.<br />
<br />
This [http://tomoyo.sourceforge.jp/wiki-e/?WhatIs#comparison table] provides a comprehensive comparison of TOMOYO Linux with [[AppArmor]], [[SELinux]] and [http://schaufler-ca.com/ SMACK].<br />
<br />
==Branches of development==<br />
[http://tomoyo.sourceforge.jp/1.8/index.html.en TOMOYO Linux 1.x] is the original branch of development. TOMOYO Linux was first released on 11th November 2005. It was implemented as a patch that can be applied to the Linux kernel and is still in active development. It can coexist with other security modules such as SELinux, SMACK and AppArmor.<br />
<br />
[http://tomoyo.sourceforge.jp/2.3/index.html.en TOMOYO Linux 2.x] is the Linux mainline kernel branch of development. In June 2009, TOMOYO was merged into the Linux kernel version 2.6.30 and it uses standard Linux Security Module (LSM) hooks. However, the LSM hooks must be extended further in order to port the full MAC functionality of TOMOYO Linux into the Linux kernel. Thus, it does not yet provide equal functionality with the 1.x branch of development. This [http://tomoyo.sourceforge.jp/comparison.html.en chart] compares the differences between each branch.<br />
<br />
[http://akari.sourceforge.jp/ AKARI] is based on the TOMOYO Linux 1.x branch and is implemented as a Loadable Kernel Module (LKM). It therefore has the advantage of not requiring the user to patch and recompile the kernel. This [http://akari.sourceforge.jp/comparison.html table] provides a comprehensive comparison of AKARI with the TOMOYO Linux 1.x and 2.x branches.<br />
<br />
==TOMOYO Linux 1.x==<br />
Implementing TOMOYO Linux 1.x using a kernel patched with ccs-patch provides the full functionality obtainable from the TOMOYO Linux project. However, implementation of this branch requires the most hurdles to be overcome, as the kernel must be patched with [http://sourceforge.jp/projects/tomoyo/ ccs-patch] and subsequently recompiled.<br />
<br />
Both ''kernel26-ccs'' and the userspace tools must be installed. A package for [http://aur.archlinux.org/packages.php?ID=44131 kernel-ccs] and a package for [http://aur.archlinux.org/packages.php?ID=42606 ccs-tools] are available on the AUR.<br />
<br />
Binary packages are available in the [[#TOMOYO Linux Repository|[tomoyo] repository]].<br />
<br />
===Initializing configuration===<br />
The policy must first be initialized:<br />
# /usr/lib/ccs/init_policy<br />
The policy files are saved in the {{Filename|/etc/css/}} directory and can be edited by running:<br />
# ccs-editpolicy<br />
<br />
==AKARI==<br />
===Limitations of AKARI===<br />
AKARI has the advantage of not requiring kernel recompilation. If using the TOMOYO Linux project purely for system analysis, then AKARI is the easiest method of achieving this. If using the TOMOYO Linux project for system restriction, it is a minimal effort way to gain most of the functionality of the TOMOYO Linux 1.x branch. However, there are a few limitations that must be considered:<br />
* It depends on the kernel version and configuration provided by the distribution:<br />
<pre><br />
CONFIG_SECURITY=y [required]<br />
CONFIG_KALLSYMS=y [required]<br />
CONFIG_PROC_FS=y [required]<br />
CONFIG_MODULES=y [required]<br />
CONFIG_SECURITY_PATH=y [optional: for using absolute pathnames]<br />
CONFIG_SECURITY_NETWORK=y [optional: for providing network restriction]<br />
</pre><br />
* The restriction of a few advanced networking operations are limited or unavailable due to the absence of required LSM hooks<br />
* Restricting use of [http://en.wikipedia.org/wiki/Capability-based_security capabilities] is not possible<br />
* Looking up per-task variables is slower as they are managed outside "struct task_struct" in order to keep KABI unchanged. However, this should not be noticeable for the typical end-user as performance decrease by pathname based permission checking is dominant<br />
This [http://akari.sourceforge.jp/comparison.html table] provides a comprehensive comparison of AKARI with the TOMOYO Linux 1.x and 2.x branches.<br />
<br />
{{Note|The Arch Linux kernel from 2.6.36 onwards provides all of the configuration options required for full functionality.}}<br />
<br />
===Installation===<br />
Both AKARI and the userspace tools must be installed. A package for [http://aur.archlinux.org/packages.php?ID=42608 AKARI] and a package for [http://aur.archlinux.org/packages.php?ID=42606 ccs-tools] are available on the AUR.<br />
<br />
The bootloader configuration must be changed in order to activate AKARI:<br />
title Arch Linux<br />
root (hd0,0)<br />
kernel /boot/vmlinuz26 root=/dev/sda1 ro init=/sbin/ccs-init<br />
initrd /boot/kernel26.img<br />
<br />
Binary packages are available in the [[#TOMOYO Linux Repository|[tomoyo] repository]].<br />
<br />
===Initializing configuration===<br />
The policy must first be initialized:<br />
# /usr/lib/ccs/init_policy --module_name=akari<br />
The policy files are saved in the {{Filename|/etc/css/}} directory and can be edited by running:<br />
# ccs-editpolicy<br />
<br />
==TOMOYO Linux 2.x==<br />
===Limitations of TOMOYO Linux 2.x===<br />
The implementation of TOMOYO Linux 2.x into the Linux mainline kernel is not yet complete but is still effective for MAC of files. It does not yet support the restriction of:<br />
* file attribute and namespace manipulation<br />
* capabilities<br />
* network<br />
* signal<br />
* environment variables<br />
* local port reservation<br />
This [http://tomoyo.sourceforge.jp/comparison.html.en chart] has a more comprehensive comparison of the differences between each branch of development.<br />
<br />
===Installation===<br />
TOMOYO Linux 2.x is part of the Linux mainline kernel and, in addition to those previously mentioned, requires the following kernel configuration:<br />
CONFIG_SECURITY_TOMOYO=y<br />
{{note|The Arch Linux kernel from 2.6.36 onwards provides all of the configuration options required for full functionality.}}<br />
<br />
If the kernel supports TOMOYO Linux 2.x, then only the userspace tools need to be installed:<br />
<br />
<pre><br />
pacman -S tomoyo-tools<br />
</pre><br />
<br />
For kernel versions between 2.6.30 and 2.6.35, tomoyo-tools 2.2.x should be installed. A package is available on the [http://aur.archlinux.org/packages.php?ID=42272 AUR]<br />
<br />
===Initializing configuration===<br />
The policy must first be initialized:<br />
# /usr/lib/tomoyo/init_policy<br />
The policy files are saved in the {{Filename|/etc/tomoyo/}} directory and can be edited by running:<br />
# tomoyo-editpolicy<br />
<br />
==Usage==<br />
It is important to consult the relevant documentation in order to use TOMOYO Linux or AKARI effectively:<br />
* [http://tomoyo.sourceforge.jp/documentation.html.en TOMOYO Linux documentation]<br />
* [http://akari.sourceforge.jp/index.html.en AKARI documentation]<br />
Run the policy editor to begin editing. If using TOMOYO Linux 1.x or AKARI, then ''ccs-tools'' should be used:<br />
# /usr/sbin/ccs-editpolicy<br />
If using TOMOYO Linux 2.x, then ''tomoyo-tools'' should be used:<br />
# /usr/sbin/tomoyo-editpolicy<br />
As the system runs, TOMOYO Linux will create domains and add them to the tree. The access analysis/restriction in TOMOYO Linux is applied via domains. Every process belongs to a single domain and the process will transit to a different domain whenever it executes a program. The name of a domain is a concatenated string expression for the process execution history. For example, the name of the domain which the kernel belongs to is "<kernel>"; the name of domain which {{Filename|/sbin/init}} invoked by the kernel belongs to is "<kernel> /sbin/init"; if {{Filename|/sbin/init}} invokes {{Filename|/etc/rc.d/rc}} then the domain it belongs to is "<kernel> /sbin/init /etc/rc.d/rc". You can suppress or initialize domain transitions as needed.<br />
<br />
Profiles can be assigned to each domain. There are four default profiles:<br />
<br />
{| border="1"<br />
| Disabled || Works as if regular kernel.<br />
|-<br />
| Learning || Do not reject an access request if it violates policy. Append the request to policy.<br />
|-<br />
| Permissive || Do not reject an access request if it violates policy. Do not append the request to policy.<br />
|-<br />
| Enforcing || Reject an access request if it violates policy. Do not append the request to policy.<br />
|}<br />
The learning profile can be used to analyse the system or a specific application. Once all of the desired access requests of a domain have been identified, the policy for that domain can be edited as required before selecting the enforcing profile. This can be done for any and all domains from the start of system boot.<br />
<br />
==References==<br />
* [http://tomoyo.sourceforge.jp/ TOMOYO Linux SourceForge page]<br />
* [http://tomoyo.sourceforge.jp/wiki-e/ TOMOYO Linux Wiki]<br />
* [http://akari.sourceforge.jp/index.html.en AKARI SourceForge page]<br />
* [http://akari.sourceforge.jp/index.html.en AKARI documentation]<br />
* [http://tomoyo.sourceforge.jp/1.8/index.html.en TOMOYO Linux 1.8.x documentation]<br />
* [http://tomoyo.sourceforge.jp/2.3/index.html.en TOMOYO Linux 2.3.x documentation]<br />
* [http://lwn.net/Articles/263179/ TOMOYO Linux Security Goal]<br />
* [http://tomoyo.sourceforge.jp/cgi-bin/lxr/source/centos5.5/domain_policy.conf?v=policy-sample Policy sample]<br />
* [http://elinux.org/TomoyoLinux TOMOYO Linux on the Embedded Linux Wiki]<br />
* [http://sourceforge.jp/projects/tomoyo/document/PacSec2007-en-demo.pdf Presentation slides from PacSec 2007]<br />
<br />
==See also==<br />
* [[AppArmor]]<br />
* [[SELinux]]</div>Jnguyenhttps://wiki.archlinux.org/index.php?title=GRUB&diff=145592GRUB2011-06-10T23:11:26Z<p>Jnguyen: get rid of "uber method" and "you can choose to be an exception" stuff, but lets make it more professional</p>
<hr />
<div>[[Category:Boot process (English)]]<br />
{{i18n|GRUB2}}<br />
[[fr:GRUB2]]<br />
<br />
{{Article summary start}}<br />
{{Article summary text|Covers various aspects of the next generation of the GRand Unified Bootloader (GRUB2).}}<br />
{{Article summary heading|Overview}}<br />
{{Article summary text|{{Boot process overview}}}}<br />
{{Article summary heading|Related}}<br />
{{Article summary wiki|Burg}} - Burg is a brand-new boot loader based on GRUB2. It uses a new object format which allows it to be built in a wider range of OS, including Linux/Windows/OSX/Solaris/FreeBSD, etc. It also has a highly configurable menu system which works in both text and graphic mode. <br />
{{Article summary heading|Resources}}<br />
{{Article summary link|GNU GRUB -- GNU Project|http://www.gnu.org/software/grub/}}<br />
{{Article summary link|GNU GRUB Wiki|http://grub.enbug.org/}}<br />
{{Article summary end}}<br />
<br />
[http://www.gnu.org/software/grub/ GRUB2] is the next generation of the GRand Unified Bootloader (GRUB). GRUB2 is derived from [http://www.nongnu.org/pupa/ PUPA] which was a research project to investigate the next generation of GRUB. GRUB 2 has been rewritten from scratch to clean up everything and provide modularity and portability [http://www.gnu.org/software/grub/grub-faq.en.html#q1].<br />
<br />
Briefly, the ''bootloader'' is the first software program that runs when a computer starts. It is responsible for loading and transferring control to the Linux kernel. The kernel, in turn, initializes the rest of the operating system.<br />
<br />
== Preface ==<br />
<br />
Although, [[GRUB]] (i.e. version 0.9x) is the de facto standard bootloader of Linux, it is considered 'legacy' by upstream. It is being replaced by GRUB2 in many distros. Upstream recommends GRUB2 >=1.99~rc2 over grub-legacy, even for current grub-legacy users.<br />
<br />
Note: grub2 >=1.99~rc2 supports btrfs as root (without a separate /boot fs).<br />
<br />
=== Notes for current GRUB users ===<br />
<br />
* There are differences in the commands of GRUB and GRUB2. Familiarize yourself with [http://www.gnu.org/software/grub/manual/grub.html#Commands GRUB2 commands] before proceeding (e.g. "find" has been replaced with "search").<br />
<br />
* GRUB2 is now ''modular'' and no longer requires "stage 1.5". As a result, the bootloader itself is limited -- modules are loaded from the hard drive as needed to expand functionality (e.g. for [[LVM]] or RAID support).<br />
<br />
* Device naming has changed between GRUB and GRUB2. Partitions are numbered from 1 instead of 0 while drives are still numbered from 0, and prefixed with partition-table type. For example, {{Filename|/dev/sda1}} would be referred to as {{Codeline|(hd0,msdos1)}} (for MBR) or {{Codeline|(hd0,gpt1)}} (for GPT) using GRUB2.<br />
<br />
== Installation ==<br />
<br />
=== During Arch Linux installation ===<br />
<br />
* Skip the '''Install Bootloader''' step and exit the installer.<br />
* Configure the network:<br />
# aif -p partial-configure-network<br />
* If you did not configure the installed system's /etc/resolv.conf file during installation (for instance, if you plan to let DHCP generate it later), you will need to copy the one generated by AIF when it configured the network:<br />
# cp /etc/resolv.conf /mnt/etc/resolv.conf<br />
* From the installer's live shell, chroot to the installed system:<br />
# mount -o bind /dev /mnt/dev<br />
# chroot /mnt bash<br />
* Install the GRUB2 package as mentioned in the section [[#From a running Arch Linux]].<br />
<br />
=== From a running Arch Linux ===<br />
<br />
==== BIOS systems ====<br />
<br />
The GRUB2 package can be installed with pacman (and will replace {{Package Official|grub}}, if it is installed):<br />
<br />
# pacman -S grub2-bios<br />
<br />
{{Note|When installing the grub2-common 1.99~rc1 (or later), this took quite some time because the installer does not use the option <code>--no-floppy</code>, for more details search this option in the article.}}<br />
<br />
Then GRUB2 must be installed to the boot sector of a drive or partition:<br />
<br />
# modprobe dm-mod<br />
# grub_bios-install --boot-directory=/boot --no-floppy --recheck /dev/sda<br />
# cp /usr/share/grub/{unicode.pf2,ascii.pf2} /boot/grub/<br />
<br />
To generate a core.img file alone without setting up grub2 in the MBR, add <code>'''--grub-setup=/bin/true'''</code> to grub2_bios-install:<br />
<br />
# grub_bios-install --grub-setup=/bin/true --boot-directory=/boot --no-floppy --recheck /dev/sda<br />
<br />
You can then chainload grub2's core.img from grub-legacy as a linux kernel or a multiboot kernel.<br />
<br />
The <code>--no-floppy</code> tells to not search for floppy devices which will vastly improve the command's overall execution time on many systems (it will also prevent the issue below from occuring) and where {{Filename|/dev/sda}} is the destination of the installation (in this case the MBR of the first SATA disk). If you use [[LVM]] for your {{Filename|/boot}}, you can install GRUB2 on multiple physical disks. <br />
<br />
Executing grub_bios-install without the <code>--no-floppy</code> flag can also lead to this when there is a problem detecting the path of the floppy device:<br />
<br />
grub-probe: error: Cannot get the real path of '/dev/fd0'<br />
Auto-detection of a filesystem module failed.<br />
Please specify the module with the option '--modules' explicitly.<br />
<br />
Thus it is recommended to use the <code>--no-floppy</code> switch, if you don't want to have your MBR on a floppy. If you do, you also want to set floppy as the first boot device in BIOS.<br />
<br />
===== [[GPT]] specific instructions =====<br />
<br />
GRUB2 in BIOS-GPT configuration requires a BIOS Boot Partition to embed its core.img in the absence of 32 KiB post MBR gap in GPT partitioned systems.<br />
<br />
Create a 1 MB (approx) partition using GPT fdisk or GNU Parted with no filesystem. The location of the partition does not matter but it is advisable to put it somewhere in the beginning of the disk before the /boot partition. Set the partition type to "EF02" in GPT fdisk or set "bios_grub" flag on in GNU Parted or GParted.<br />
<br />
This partition is used by GRUB2 only in BIOS-GPT setups. No such partition type exists in case of MBR partitioning (at least not for GRUB2). This partition is also not required if the system is UEFI based, as no embedding takes place in that case. Neither GRUB-legacy nor SYSLINUX require this partition.<br />
<br />
Note: This partition should be created before grub2_bios-install or grub-setup is run or before the '''Install Bootloader''' step of the Archlinux installer (if GRUB2 is selected as bootloader).<br />
<br />
===== Upgrading from grub-legacy (BIOS systems alone) =====<br />
<br />
* Remove grub-legacy traces from the MBR using<br />
# dd if=/dev/zero of=<your_disk> bs='''440''' count=1<br />
* Follow the [[#BIOS systems]] instructions.<br />
* Convert your /boot/grub/{menu.lst or grub.conf} to grub.cfg format using<br />
# grub-menulst2cfg /boot/grub/menu.lst /boot/grub/grub.cfg<br />
<br />
Example:<br />
<br />
{{File|name=menu.lst|content=<br />
default=0<br />
timeout=5<br />
<br />
title Arch Linux Stock Kernel<br />
root (hd0,0)<br />
kernel /vmlinuz26 root=/dev/sda2 ro<br />
initrd /kernel26.img<br />
<br />
title Arch Linux Stock Kernel Fallback<br />
root (hd0,0)<br />
kernel /vmlinuz26 root=/dev/sda2 ro<br />
initrd /kernel26-fallback.img<br />
}}<br />
<br />
{{File|name=grub.cfg|content=<br />
default=0<br />
tset default='0'; if [ x"$default" = xsaved ]; then load_env; set default="$saved_entry"; fi<br />
set timeout=5<br />
<br />
menuentry 'Arch Linux Stock Kernel' {<br />
set root='(hd0,1)'; set legacy_hdbias='0'<br />
legacy_kernel '/vmlinuz26' '/vmlinuz26' 'root=/dev/sda2' 'ro'<br />
legacy_initrd '/kernel26.img' '/kernel26.img'<br />
<br />
}<br />
<br />
menuentry 'Arch Linux Stock Kernel Fallback' {<br />
set root='(hd0,1)'; set legacy_hdbias='0'<br />
legacy_kernel '/vmlinuz26' '/vmlinuz26' 'root=/dev/sda2' 'ro'<br />
legacy_initrd '/kernel26-fallback.img' '/kernel26-fallback.img'<br />
}<br />
}}<br />
<br />
==== [[UEFI]] systems ====<br />
<br />
'''''Note: Unless specified as EFI 1.x , EFI and UEFI terms are used interchangeably to denote UEFI 2.x firmware. Also unless stated explicitely, the instructions are general and not Mac specific. Some of them may not work or may be different in Macs. Apple's EFI implementation is neither a EFI 1.1 version nor UEFI 2.x version but includes features of both. This kind of firmware does not fall under any one UEFI version so it is not a standard EFI firmware.'''''<br />
<br />
GRUB2 UEFI bootloader is available in Arch Linux only from version 1.99~rc1 . To install, first [https://wiki.archlinux.org/index.php/Unified_Extensible_Firmware_Interface#Detecting_UEFI_Firmware_Arch Detect which UEFI firmware arch] you have (i386 or x86_64).<br />
<br />
Depending on that, install the appropriate package<br />
<br />
For 64-bit aka x86_64 UEFI firmware<br />
<br />
# pacman -S grub2-efi-x86_64<br />
<br />
For 32-bit aka i386 UEFI firmware<br />
<br />
# pacman -S grub2-efi-i386<br />
<br />
Mount the [https://wiki.archlinux.org/index.php/Unified_Extensible_Firmware_Interface#Creating_a_EFI_SYSTEM_PARTITION_in_Linux EFI SYSTEM PARTITION] in your system at /boot/efi . It should be FAT32 formatted and should be at least 200 MB in size. If you have mounted the EFISYS partition in some other mountpoint, replace /boot/efi in the below commands with that mountpoint.<br />
<br />
# sudo mkdir -p /boot/efi/efi # If the directory does not exist<br />
<br />
# sudo modprobe dm-mod<br />
<br />
The below commands assume you are using grub2-efi-x86_64 (for grub2-efi-i386, replace all x86_64 with i386 in the commands)<br />
<br />
# sudo grub_efi_x86_64-install --boot-directory=/boot/efi/efi --bootloader-id=grub --no-floppy --recheck<br />
<br />
If you notice carefully, there is no <device_path> option (Eg:- /dev/sda) at the end of the grub_efi_x86_64-install command unlike the case of setting up grub2 for BIOS systems. Any <device_path> provided will be ignored by the install script as UEFI bootloaders do not use MBR or Partition boot sectors at all.<br />
<br />
Then copy the font files required to enable UEFI video mode (GOP mostly) in grub2 (otherwise no kernel boot messages will be seen in the console)<br />
<br />
# sudo cp /usr/share/grub/{unicode.pf2,ascii.pf2} /boot/efi/efi/grub/<br />
<br />
The grub_efi_x86_64-install automatically generates a "grub.efi" while setting up the /boot/efi/efi/grub/ directory.<br />
<br />
If you want, you can create a custom grub2.efi app using :-<br />
<br />
# sudo grub-mkimage -d /usr/lib/grub/x86_64-efi -O x86_64-efi -p "" -o /boot/efi/efi/grub/grub2.efi <Your_List_of_GRUB2_Modules><br />
<br />
Note : The '''-p ""''' option is important for creating a portable grub2.efi app.<br />
<br />
There is no file-size restriction on grub2.efi either due to GRUB2 or due to the UEFI firmware. Therefore you can include any number of modules you want.<br />
<br />
A "grub.cfg" created for BIOS based GRUB2 will be sufficient for the UEFI GRUB2 as long as all the paths in the config are absolute paths. The "grub.efi" uefi application can be launched using the firmware's "Boot Manager", "Boot from file" option or using the [https://wiki.archlinux.org/index.php/UEFI#UEFI_Shell UEFI Shell].<br />
<br />
Alternatively, you can also setup /boot/efi/efi/grub directory by copying all the files in /usr/lib/grub/x86_64-efi to /boot/efi/efi/grub and using the above grub-mkimage command to create a grub2.efi application. Just make sure you have the required modules embedded in grub2.efi to enable it to access the EFI SYSTEM PARTITION. A basic grub2.efi can be generated using the following command -<br />
<br />
# sudo grub-mkimage -d /usr/lib/grub/x86_64-efi -O x86_64-efi -p "" -o /boot/efi/efi/grub/grub2.efi part_gpt fat iso9660 udf normal chain linux \<br />
ls search search_fs_file search_fs_uuid search_label help boot configfile echo efi_gop<br />
<br />
In the /boot/efi/efi/grub/grub.cfg file, add the following lines to enable grub2 to pass the video mode correctly to the kernel, without which you will only get a black screen (no output) but booting (actually) proceeds successfully without any system hang.<br />
<br />
<pre><br />
insmod efi_gop<br />
insmod efi_uga<br />
insmod font<br />
<br />
if loadfont ${prefix}/unicode.pf2<br />
then<br />
insmod gfxterm<br />
set gfxmode=auto<br />
set gfxpayload=keep<br />
terminal_output gfxterm<br />
fi<br />
</pre><br />
<br />
As you can see for gfxterm (graphical terminal) to function properly, unicode.pf2 font file should exists in /boot/efi/efi/grub/ dir.<br />
<br />
===== Launch GRUB2 EFI as default in the Firmware Boot Manager =====<br />
<br />
grub_efi_$EFI_ARCH-install will ensure /boot/efi/efi/grub/grub.efi is launched by default if it detects efibootmgr and if efibootmgr is able to access EFI Runtime Services. This requires the kernel to be booted in UEFI mode and that the kernel processor arch should match the firmware arch (and 'noefi' is NOT used) for efivars kernel module to be loaded and efibootmgr to modify the boot entries. Initially the user is required to manually launch /boot/efi/efi/grub/grub.efi from the firmware itself if grub2-efi was installed in BIOS mode. Then efibootmgr should be run to make.<br />
<br />
First boot into UEFI mode manually either using Firmware Boot menu, EFI shell, or using any UEFI capable bootable iso (Archboot or Ubuntu non-Mac iso). Use grub probe to determine the device path of your EFI System Partition<br />
<br />
# grub-probe --target=device /boot/efi/efi/grub/grub.efi<br />
<br />
It should give something like /dev/sda1 (used as example in the remaining steps). Load 'efivars' kernel module.<br />
<br />
# sudo modprobe efivars<br />
<br />
Then run efibootmgr and reboot.<br />
<br />
# sudo efibootmgr --create --gpt --disk /dev/sda --part 1 --write-signature --label "GRUB2" --loader "\\EFI\\grub\\grub.efi"<br />
<br />
In the above command, /boot/efi/efi/grub/grub/efi can be split up as /boot/efi and /efi/grub/grub.efi, which translates to (/dev/sda) -> partition 1 -> \\EFI\\grub\\grub.efi . <br />
<br />
Note the capital EFI, fat32 fs is case-insensitive since it does not use UTF-8 encoding by default. In that case the firmware uses capital 'EFI' instead of small 'efi', although using \\efi\\grub\\grub.efi should be just fine (this will change if the fs encoding is UTF-8). Also the path names in UEFI firmware are similar to Windows path names and also uses double backward slashes instead of single ones.<br />
<br />
The 'label' is any name for just your identification and does not affect in booting the system. More info can be obtained from [http://linux.dell.com/cgi-bin/gitweb/gitweb.cgi?p=efibootmgr.git;a=blob_plain;f=README;hb=HEAD efibootmgr GIT README]<br />
<br />
== Manual Compilation ==<br />
<br />
=== For BIOS Systems ===<br />
<br />
GRUB2 for BIOS systems should be compiled as follows<br />
<br />
<pre><br />
./autogen.sh<br />
<br />
./configure --with-platform=pc --prefix=/usr<br />
<br />
make<br />
<br />
make install<br />
</pre><br />
<br />
The <code>'''--with-platform=pc'''</code> generates grub2 for bios alone irrespective of the firmware of the build system.<br />
<br />
=== For UEFI Systems ===<br />
<br />
First [https://wiki.archlinux.org/index.php/Unified_Extensible_Firmware_Interface#Detecting_UEFI_Firmware_Arch Detect which UEFI Firmware arch] you have and then follow the compile instructions below -<br />
<br />
<pre><br />
./autogen.sh<br />
<br />
./configure --with-platform=efi --target=TARGET_EFI_ARCH --prefix=/usr<br />
<br />
make<br />
<br />
make install<br />
</pre><br />
<br />
The "--target" option denotes the UEFI firmware arch. for which grub2 should be compiled, not the architecture of the linux kernel grub2 may boot. <br />
<br />
It is possible to use UEFI 64-bit firmware + GRUB2 as x86_64-EFI app loading a i686 linux kernel, as long as the kernel does not try to access UEFI Runtime Services. Vice-versa situation is also possible. But a x86_64 UEFI firmware cannot launch GRUB2 i386-efi app (unlike x86_64 Operating Systems), and a i386 UEFI firmware will not launch GRUB2 x86_64-efi app. It is important to compile GRUB2 to match the architecture of the UEFI firmware.<br />
<br />
== Configuration ==<br />
<br />
The configuration files are <code>/etc/default/grub</code> and <code>/etc/grub.d/*</code>. These files are used to generate the <code>/boot/grub/grub.cfg</code> file. You can also choose to manually edit <code>grub.cfg</code>.<br />
<br />
=== grub-mkconfig ===<br />
<br />
The grub-mkconfig script can be used to generate a {{Filename|grub.cfg}} file. By default the script outputs to stdout. Note that gettext ― an optional dependency of the GRUB2 package ― is required by the grub-mkconfig script. To generate a {{Filename|grub.cfg}} file run the command:<br />
# grub-mkconfig -o /boot/grub/grub.cfg<br />
<br />
=== grub.cfg ===<br />
<br />
A basic grub file uses the following options<br />
* {{Codeline|(hdX,Y)}} is the partition {{Codeline|Y}} on disk {{Codeline|X}}, partition numbers starting at 1, disk numbers starting at 0<br />
* {{Codeline|1=set default=N}} is the default boot entry that is chosen after timeout for user action<br />
* {{Codeline|1=set timeout=M}} is the time {{Codeline|M}} to wait in seconds for a user selection before default is booted<br />
* {{Codeline|<nowiki>menuentry "title" {entry options}</nowiki>}} is a boot entry titled {{Codeline|title}}<br />
* {{Codeline|1=set root=(hdX,Y)}} sets the boot partition, where the kernel and GRUB modules are stored (boot need not be a separate partition, and may simply be a directory under the "root" partition ({{Filename|/}})<br />
<br />
An example configuration:<br />
<br />
{{File<br />
|name=/boot/grub/grub.cfg<br />
|content=<nowiki><br />
# Config file for GRUB2 - The GNU GRand Unified Bootloader<br />
# /boot/grub/grub.cfg<br />
<br />
# DEVICE NAME CONVERSIONS<br />
#<br />
# Linux Grub<br />
# -------------------------<br />
# /dev/fd0 (fd0)<br />
# /dev/sda (hd0)<br />
# /dev/sdb2 (hd1,2)<br />
# /dev/sda3 (hd0,3)<br />
#<br />
<br />
# Timeout for menu<br />
set timeout=5<br />
<br />
# Set default boot entry as Entry 0<br />
set default=0<br />
<br />
# (0) Arch Linux<br />
menuentry "Arch Linux" {<br />
set root=(hd0,1)<br />
linux /vmlinuz26 root=/dev/sda3 ro<br />
initrd /kernel26.img<br />
}<br />
<br />
## (1) Windows<br />
#menuentry "Windows" {<br />
#set root=(hd0,3)<br />
#chainloader +1<br />
#}<br />
</nowiki>}}<br />
<br />
If you choose to modify <code>grub.cfg</code> completely manually and won't even generate the first <code>grub.cfg</code>, you should know that if you do not have a separate boot partition, <code>/boot</code> must prefix entries in <code>grub.cfg</code>. Example:<br />
<br />
# (0) Arch Linux<br />
menuentry "Arch Linux" {<br />
set root=(hd0,1)<br />
linux '''/boot/'''vmlinuz26 root=/dev/sda1 ro<br />
initrd '''/boot/'''kernel26.img<br />
}<br />
<br />
=== Dual-booting ===<br />
<br />
''NOTE: If you want GRUB2 to automatically search for other systems, for example as in Ubuntu. Then you may need to download {{Package AUR|os-prober}} from the [[AUR]].''<br />
<br />
<br />
==== Using grub-mkconfig ====<br />
The best way to add other entries is editing the {{Filename|/etc/grub.d/40_custom}}. The entries in this file will be automatically added when running '''grub-mkconfig'''.<br />
After adding the new lines, run <br />
# grub-mkconfig -o /boot/grub/grub.cfg <br />
to generate an updated {{Filename|grub.cfg}}.<br />
<br />
===== With GNU/Linux =====<br />
<br />
Assuming that the other distro is on partition {{Filename|sda2}}:<br />
<br />
menuentry "Other Linux" {<br />
set root=(hd0,2)<br />
linux /boot/vmlinuz (add other options here as required)<br />
initrd /boot/initrd.img (if the other kernel uses/needs one)<br />
}<br />
<br />
===== With Windows =====<br />
<br />
This assumes that your Windows partition is {{Filename|sda3}}.<br />
<br />
# (2) Windows XP<br />
menuentry "Windows XP" {<br />
set root=(hd0,3)<br />
chainloader (hd0,3)+1<br />
}<br />
<br />
If the windows bootloader is on an entirely different harddrive than grub, it may be neccessary to trick windows into believing that it is in fact the first harddrive. This was possible in the old grub with <code>map</code> and is now done with <code>drivemap</code>. Assume grub is on hd0 and windows on hd2, you need to add the following after <code>set root</code><br />
<br />
drivemap -s hd0 hd2<br />
<br />
==== With Windows via EasyBCD and NeoGRUB ====<br />
<br />
Since EasyBCD's NeoGRUB currently does not understand the GRUB2 menu format, chainload to it by replacing the contents of your {{Filename|C:\NST\menu.lst}} file with lines similar to the following:<br />
<br />
default 0<br />
timeout 1<br />
<br />
title Chainload into GRUB v2<br />
root (hd0,7)<br />
kernel /boot/grub/core.img<br />
<br />
===Visual Configuration===<br />
<br />
In GRUB2 it is possible, by default, to change the look of the menu.<br />
<br />
====Background image and bitmap fonts====<br />
<br />
GRUB2 comes with support for background images and bitmap fonts in pf2 format. The unifont font is included in the grub2 package under the filename {{Filename|unicode.pf2}}, or, as only ascii characters under the name {{Filename|ascii.pf2}}. Image formats supported include tga, png and jpeg, providing the correct modules are loaded. The maximum supported resolution depends on your hardware. There are two ways of setting a tga file as background. Two sample configurations are shown below.<br />
<br />
=====The recommended method=====<br />
<br />
Edit <code>/etc/default/grub</code> like this:<br />
GRUB_GFXMODE=1024x768x32<br />
GRUB_GFXPAYLOAD_LINUX=keep<br />
GRUB_BACKGROUND="/boot/grub/archlinux.tga"<br />
#GRUB_THEME="/path/to/gfxtheme"<br />
<br />
To generate the changes, run: <br />
grub-mkconfig -o /boot/grub/grub.cfg<br />
<br />
=====The manual method=====<br />
<br />
This can be added manually to grub.cfg as shown here:<br />
if loadfont /usr/share/grub/unicode.pf2 ; then<br />
set gfxmode="1024x768x32"<br />
set gfxpayload=keep<br />
insmod gfxterm<br />
insmod vbe<br />
terminal_output gfxterm<br />
if terminal_output gfxterm; then true ; else<br />
terminal gfxterm<br />
fi<br />
fi<br />
insmod tga<br />
background_image /boot/grub/archlinux.tga<br />
<br />
{{Note|If this example doesn't work for you try to replace {{Codeline|1=gfxmode="1024x768x32"}} by {{Codeline|1=vbemode="0x105"}}.}}<br />
{{Note|To show all the modes you can use the {{Codeline|1=vbeinfo}} command at grub2 prompt (you need to load the vbe module before).}}<br />
{{Note|If you have installed Grub on a separate partition, /boot/grub/archlinux.tga becomes /grub/archlinux.tga.}}<br />
<br />
====Menu colors====<br />
<br />
As in Grub (0.9x), you can change the menu colors in Grub2. The available colors for GRUB2 are at http://www.gnu.org/software/grub/manual/html_node/Theme-file-format.html#Theme-file-format . <br />
Here's an example:<br />
<br />
=====The recommended method=====<br />
Edit <code>/etc/default/grub</code>:<br />
GRUB_COLOR_NORMAL="light-blue/black"<br />
GRUB_COLOR_HIGHLIGHT="light-cyan/blue"<br />
<br />
Execute:<br />
grub-mkconfig -o /boot/grub/grub.cfg<br />
<br />
=====The manual method=====<br />
<br />
This can be added manually to grub.cfg as shown here:<br />
<br />
set menu_color_normal=light-blue/black<br />
set menu_color_highlight=light-cyan/blue<br />
<br />
====Hidden menu====<br />
<br />
One of the unique features of Grub2 is hiding/skipping the menu and showing it by holding "Shift" when needed. You can also adjust whether you want to see the timeout counter.<br />
<br />
=====The recommended method=====<br />
<br />
Edit <code>/etc/default/grub</code> as you wish. Here's an example where the comments from the beginning of the two lines have been removed to enable the feature, the timeout has been set to five seconds and to be shown to the user:<br />
GRUB_HIDDEN_TIMEOUT=5<br />
GRUB_HIDDEN_TIMEOUT_QUIET=false<br />
<br />
And run:<br />
grub-mkconfig -o /boot/grub/grub.cfg<br />
<br />
=====The manual method=====<br />
<br />
This can be added manually to grub.cfg as shown here:<br />
<br />
set locale_dir=($root)/boot/grub/locale<br />
set lang=en<br />
'''insmod gettext'''<br />
'''if sleep --interruptible 5 ; then'''<br />
'''set timeout=0'''<br />
'''fi'''<br />
<br />
====Setting the framebuffer resolution ====<br />
<br />
===== The recommended method =====<br />
<br />
Grub2 can set the framebuffer for both grub2 itself and the kernel. The old ''vga='' way is deprecated. The preferred method is editing <code>/etc/default/grub</code> as the following sample:<br />
<br />
GRUB_GFXMODE=1024x768x32<br />
GRUB_GFXPAYLOAD_LINUX=keep<br />
<br />
To generate the changes, run: <br />
grub-mkconfig -o /boot/grub/grub.cfg<br />
<br />
The gfxpayload property will make sure the kernel keeps the resolution.<br />
<br />
If this method does not work for you, the deprecated vga= method will still work. Just<br />
add the vga= setting next to the "GRUB_CMDLINE_LINUX_DEFAULT=" line in "/etc/default/grub"<br />
for eg: "GRUB_CMDLINE_LINUX_DEFAULT="quiet splash vga=792" will give you a 1024x768 resolution.<br />
<br />
You can choose one of these resolutions: 640×480, 800×600, 1024×768, 1280×1024, 1600×1200<br />
<br />
===== The method method =====<br />
<br />
This can be added manually to grub.cfg as shown here:<br />
<br />
if loadfont /usr/share/grub/unicode.pf2 ; then<br />
set gfxmode="1024x768x32" <br />
set gfxpayload=keep<br />
insmod gfxterm<br />
insmod vbe<br />
terminal_output gfxterm<br />
if terminal_output gfxterm; then true ; else<br />
terminal gfxterm<br />
fi<br />
fi<br />
<br />
=== Other Options ===<br />
<br />
==== LVM ====<br />
<br />
If you use [[LVM]] for your {{Filename|/boot}}, add the following before menuentry lines:<br />
<br />
insmod lvm<br />
<br />
and specify your root in the menuentry as:<br />
<br />
set root=(''lvm_group_name''-''lvm_logical_boot_partition_name'')<br />
<br />
Example:<br />
<br />
# (0) Arch Linux<br />
menuentry "Arch Linux" {<br />
insmod lvm<br />
set root=(VolumeGroup-lv_boot)<br />
# you can only set following two lines<br />
linux /vmlinuz26 root=/dev/mapper/VolumeGroup-root ro<br />
initrd /kernel26.img<br />
}<br />
<br />
==== Raid ====<br />
<br />
Grub2 provides convenient handling of raid-volumes. You need to add<br />
<br />
insmod raid<br />
<br />
which allows you to address the volume natively. E.g. {{Filename|/dev/md0}} becomes<br />
<br />
set root=(md0)<br />
<br />
whereas a partitioned raid-volume (e.g. {{Filename|/dev/md0p1}}) becomes <br />
<br />
set root=(md0,1)<br />
<br />
==== Persistent block device naming ====<br />
You can use UUIDs to detect partitions instead of the "old" '''/dev/sd*''' and '''/dev/hd*''' scheming. It has the advantage of detecting partitions by their unique UUIDs, which is needed by some people booting with complicated partition setups.<br />
<br />
UUIDs are used by default in the recent versions of grub2 - there's no downside in it anyway except that you need to re-generate the grub.cfg file every time you resize or reformat your partitions. Remember this when modifying partitions with Live-CD.<br />
<br />
===== The recommended method =====<br />
<br />
The recent versions of grub2 use UUIDs by default. You can re-enable the use of UUIDS by simply commenting the UUID line (this is also what it looks like by default):<br />
#GRUB_DISABLE_LINUX_UUID=true<br />
you can also just set the value as <code>false</code> as shown here:<br />
GRUB_DISABLE_LINUX_UUID=false<br />
<br />
Either way don't forget to generate the changes:<br />
grub-mkconfig -o /boot/grub/grub.cfg<br />
<br />
===== The manual method =====<br />
<br />
To list UUIDs, from a running system:<br />
# blkid<br />
<br />
Replace the value of the {{Codeline|root}} pointer on the linux line with the following:<br />
<br />
linux /vmlinuz26 root='''/dev/disk/by-uuid/<UUID>''' ro<br />
<br />
However, you still have to set Grub2's notion of a root partition. In order to do that, use the {{Codeline|search}} command:<br />
<br />
search --fs-uuid --no-floppy --set=root <UUID><br />
<br />
What the <code>--no-floppy</code> flag does has already been explained. An example boot entry using Persistent block device naming would look like:<br />
<br />
menuentry "Arch Linux" {<br />
'''search --fs-uuid --no-floppy --set=root 355ccb5c-99e1-400d-b612-451f9247e35e'''<br />
linux /boot/vmlinuz26 '''root=/dev/disk/by-uuid/355ccb5c-99e1-400d-b612-451f9247e35e''' ro<br />
initrd /boot/kernel26.img<br />
}<br />
<br />
==== Using Labels ====<br />
<br />
It is possible to use labels, human-readable strings attached to filesystems, by using the {{Codeline|--label}} option to {{Codeline|search}}. First of all, label your existing partition:<br />
<br />
# tune2fs -L a <LABEL> <PARTITION><br />
<br />
Then, add an entry using labels. An example of this:<br />
<br />
menuentry "Arch Linux, session texte" {<br />
search --label --no-floppy --set=root archroot<br />
linux /boot/vmlinuz26 root=/dev/disk/by-label/archroot ro<br />
initrd /boot/kernel26.img<br />
}<br />
<br />
==== Recall previous entry ====<br />
<br />
Grub2 can remember the last entry you booted from and use this as the default entry to boot from next time. This is useful if you have multiple kernels (i.e., the current Arch one and the LTS kernel as a fallback option) or operating systems. To do this, edit {{Codeline|/etc/default/grub}} and change the setting of {{Codeline|GRUB_DEFAULT}}:<br />
<br />
GRUB_DEFAULT=saved<br />
<br />
This ensures that grub will default to the saved entry. To enable saving the selected entry, add the following line to {{Codeline|/etc/default/grub}}:<br />
<br />
GRUB_SAVEDEFAULT=true<br />
<br />
Remember to regenerate your configuration file.<br />
<br />
== Using the command shell ==<br />
<br />
Since the MBR is too small to store all GRUB2 modules, only the menu and a few basic commands reside there. The majority of GRUB2 functionality remains in modules in {{Filename|/boot/grub}}, which are inserted as needed. In error conditions (e.g. if the partition layout changes) GRUB2 may fail to boot. When this happens, a command shell may appear.<br />
<br />
GRUB2 offers multiple shells/prompts. If there is a problem reading the menu but the bootloader is able to find the disk, you will likely be dropped to the "normal" shell:<br />
<br />
sh:grub><br />
<br />
If there is a more serious problem (e.g. GRUB cannot find required files), you may instead be dropped to the "rescue" shell:<br />
<br />
grub rescue><br />
<br />
The rescue shell is a restricted subset of the normal shell, offering much less functionality. If dumped to the rescue shell, first try inserting the "normal" module, then starting the "normal" shell:<br />
<br />
grub rescue> set prefix=(hdX,Y)/boot/grub<br />
grub rescue> insmod (hdX,Y)/boot/grub/normal.mod<br />
rescue:grub> normal<br />
<br />
=== Pager support ===<br />
<br />
GRUB2 supports pager for reading commands that provide long output (like the help command). This works only in normal shell mode and not in rescue mode. To enable pager, in GRUB2 command shell type<br />
<br />
sh:grub> set pager=1<br />
<br />
<br />
== GUI configuration tools ==<br />
<br />
Following package may be installed from [[AUR]]<br />
* [http://kde-apps.org/content/show.php?content=139643 grub2-editor] (requires kdelibs)<br />
*:A KDE4 control module for configuring the GRUB2 bootloader<br />
* [http://kde-apps.org/content/show.php?content=137886 kcm-grub2] (requires kdelibs python2-qt kdebindings-python)<br />
*:This Kcm module manages the most common settings of Grub2.<br />
* [http://sourceforge.net/projects/startup-manager/ startupmanager] (requires gnome-python imagemagick yelp python2 xorg-xrandr)<br />
*:GUI app for changing the settings of GRUB, GRUB2, Usplash and Splashy<br />
<br />
== parttool or legacy hide/unhide ===<br />
<br />
If you have a win9x paradigm with hidden C disks GRUB legacy had the hide/unhide feature. In GRUB2 this has been replaced by parttool. For example, to boot the third C disk of three win9x installations on the CLI enter the CLI and:<br />
parttool hd0,1 hidden+ boot-<br />
parttool hd0,2 hidden+ boot-<br />
parttool hd0,3 hidden- boot+<br />
set root=hd0,3<br />
chainloader +1<br />
boot<br />
<br />
== Using the rescue console ==<br />
<br />
See [[#Using the command shell]] first. If unable to activate the standard shell, one possible solution is to boot using a live CD or some other rescue disk to correct configuration errors and reinstall GRUB. However, such a boot disk is not always available (nor necessary); the rescue console is surprisingly robust.<br />
<br />
The available commands in GRUB rescue include "insmod", "ls", "set", and "unset". This example uses "set" and "insmod". "set" modifies variables and "insmod" inserts new modules to add functionality.<br />
<br />
Before starting, the user must know the location of their {{Filename|/boot}} partition (be it a separate partition, or a subdirectory under their root):<br />
<br />
grub rescue> set prefix=(hdX,Y)/boot/grub<br />
<br />
where X is the physical drive number and Y is the partition number.<br />
<br />
To expand console capabilities, insert the "linux" module:<br />
<br />
grub rescue> insmod (hdX,Y)/boot/grub/linux.mod<br />
<br />
{{Note|With a separate boot partition, omit {{Filename|/boot}} from the path, (i.e. type {{Codeline|1=set prefix=(hdX,Y)/grub}} and {{Codeline|insmod (hdX,Y)/grub/linux.mod}}).}}<br />
<br />
This introduces the "linux" and "initrd" commands, which should be familiar (see [[#Configuration]]).<br />
<br />
An example, booting Arch Linux:<br />
<br />
set root=(hd0,5)<br />
linux /boot/vmlinuz26 root=/dev/sda5<br />
initrd /boot/kernel26.img<br />
boot<br />
<br />
With a separate boot partition, again change the lines accordingly:<br />
<br />
set root=(hd0,5)<br />
linux /vmlinuz26 root=/dev/sda6<br />
initrd /kernel26.img<br />
boot<br />
<br />
After successfully booting the Arch Linux installation, users can correct {{Filename|grub.cfg}} as needed and then run:<br />
<br />
# grub-install /dev/sda --no-floppy<br />
<br />
to reinstall GRUB2 and fix the problem completely, changing {{Filename|/dev/sda}} if needed. See [[#Bootloader installation]] for details.<br />
<br />
== Combining the use of UUID's and basic scripting ==<br />
--[[User:Celilo|Celilo]] 06:04, 19 March 2010 (EDT)<br />
<br />
If you like the idea of using UUID's to avoid unreliable bios mappings or are struggling with grub syntax, here is an example boot menu item that uses UUID's and a small script to direct grub to the proper disk partitions for your system. All you need to do is replace the UUID's in the sample with the correct UUID's for your system. (The example applies to a system with a boot and root partition. You will obviously need to modify the grub configuration if you have additional partitions.)<br />
<br />
menuentry "Arch Linux 64" {<br />
#Enter the UUID of your boot partition (this is where grub and your kernel reside)<br />
set uuid_grub_boot=ece0448f-bb08-486d-9864-ac3271bd8d07<br />
<br />
#Enter the UUID of the partition containing the root partition of your Arch Linux installation. <br />
set uuid_os_root=c55da16f-e2af-4603-9e0b-03f5f565ec4a<br />
<br />
#(Note: this may be the same as your boot partition)<br />
<br />
#Here we set the grub "root" variable by locating the uuid of the root partition identified above <br />
search --fs-uuid --no-floppy --set=root $uuid_os_root<br />
<br />
#Here we set a custom variable grub_boot by locating the uuid of the boot partition identified above <br />
search --fs-uuid --no-floppy --set=grub_boot $uuid_grub_boot<br />
<br />
#Here's the magic. We test to see if the boot and root partitions have the same UUID.<br />
#If they do we append /boot to the $grub_boot variable. For ex. (hd0,1) becomes (hd0,1)/boot.<br />
if [ $uuid_grub_boot == $uuid_os_root ] ; then<br />
set grub_boot=$grub_boot/boot<br />
fi<br />
<br />
# $grub_boot now points to the correct location, so the following will properly find the kernel and initrd<br />
linux ($grub_boot)/vmlinuz26 root=/dev/disk/by-uuid/$uuid_os_root ro<br />
initrd ($grub_boot)/kernel26.img<br />
}<br />
<br />
== Troubleshooting ==<br />
<br />
Any troubleshooting should be added here.<br />
<br />
=== msdos-style error message ===<br />
<br />
grub-setup: warn: This msdos-style partition label has no post-MBR gap; embedding won't be possible!<br />
grub-setup: warn: Embedding is not possible. GRUB can only be installed in this setup by using blocklists.<br />
However, blocklists are UNRELIABLE and its use is discouraged.<br />
grub-setup: error: If you really want blocklists, use --force.<br />
<br />
This error may occur when you try installing GRUB2 in a VMware container. Read more about it [http://bbs.archlinux.org/viewtopic.php?pid=581760#p581760 here]. Hopefully a fix will be provided soon.<br />
<br />
It also happens when the first partition starts just after the MBR, without the usual space of 60-something block before the first partition.<br />
<br />
== References ==<br />
<br />
# Official GRUB2 Manual - http://www.gnu.org/software/grub/manual/grub.html<br />
# GRUB2 wiki page describing steps to compile for BIOS - http://grub.fsij.org/TestingOnX86<br />
# GRUB2 wiki page describing steps to compile for UEFI - http://grub.fsij.org/TestingOnUEFI - moved to https://help.ubuntu.com/community/UEFIBooting<br />
# Wikipedia's page on [http://en.wikipedia.org/wiki/BIOS_Boot_partition BIOS Boot Partition]<br />
# [http://grub.fsij.org/BIOS_Boot_Partition GRUB2 Wiki page] describing why BIOS Boot Partition is required.<br />
<br />
== External Links ==<br />
<br />
# [https://github.com/skodabenz/My_Shell_Scripts/blob/master/grub2/grub2_bios.sh A Linux Bash Shell script to compile and install GRUB2 for BIOS from BZR Source]<br />
# [https://github.com/skodabenz/My_Shell_Scripts/blob/master/grub2/grub2_uefi.sh A Linux Bash Shell script to compile and install GRUB2 for UEFI from BZR Source]</div>Jnguyenhttps://wiki.archlinux.org/index.php?title=Linux-ck&diff=142032Linux-ck2011-05-19T17:56:00Z<p>Jnguyen: /* How to Enable the BFQ I/O Scheduler (Repo Users Only) */ elevator=bfq</p>
<hr />
<div>[[Category:Kernel (English)]]<br />
{{Article summary start}}<br />
{{Article summary text|<br />
'''Kernel26-ck and headers'''<br />
*Current version: '''2.6.38.6-3'''<br />
*Release date: 13-May-2011<br />
*BFS CPU scheduler: v0.401<br />
*CK Patchset: 2.6.38-ck3<br />
<br />
'''Kernel26-lts-ck and headers'''<br />
*Current version: '''2.6.35.13-2'''<br />
*Release date: 01-May-2011<br />
*BFS CPU scheduler: v0.401<br />
*CK Patchset: 2.6.35-ck1}}<br />
{{Article summary heading|Related}}<br />
{{Article summary wiki|Kernels}}<br />
{{Article summary wiki|Kernel Compilation}}<br />
{{Article summary end}}<br />
<br />
[[http://aur.archlinux.org/packages.php?ID=32877 Kernel26-ck]] and [[http://aur.archlinux.org/packages.php?ID=45902 Kernel26-lts-ck]] are packages available in the [[AUR]] that allows users to compile a kernel/headers with Con Kolivas' patchset including the Brain Fuck Scheduler (BFS) and all other goodies contained in the ck patchset. The BFS was written with two major goals in mind:<br />
<br />
*Completely do away with the complex designs of the past for the cpu process scheduler and instead implement one that is very simple in basic design.<br />
*Achieve excellent desktop interactivity and responsiveness without heuristics and tuning knobs that are difficult to understand, impossible to model and predict the effect of, and when tuned to one workload cause massive detriment to another.<br />
<br />
See [http://www.youtube.com/watch?v=F5Ri_HhziI0 this video] about queuing theory for an interesting parallel with<br />
supermarket checkouts. Many Archers elect to use one of these packages for the BFS' excellent desktop interactivity and responsiveness under any load situation.<br />
<br />
=General Package Details=<br />
*Kernel26-ck roughly follows the release cycle of the official ARCH kernel26 package. Once the devs have released the needed components such as the ARCH patch set, release-specific config files, etc. and once CK has released an updated ck patchset, the packages will be updated ASAP.<br />
<br />
{{Note|When packages reach [testing], the PKGBUILD and repo will be updated assuming the needed patch sets are available.}}<br />
*There are two modifications to the config files<br />
#The options that the ck patchset enable/disable. <br />
#CONFIG_FRAME_POINTER option is set from enabled to disabled. Result will be a slightly smaller and faster kernel image without kernel debugging information (precise oopses/stacktraces/warnings). Note that as of gcc 4.6.0+, the -O2 switch adds the corresponding -fomit-frame-pointer switch to your CFLAGS, so this kernel option seems a bit redundant to me.<br />
<br />
All other options are set to the ARCH defaults outlined in the main kernel's config files. Users are of course free to modify them! The kernel26-ck package contains an option to switch on the '''nconfig''' config editor (see section below). Why the changes? See CK's [[http://ck.kolivas.org/patches/bfs/bfs-configuration-faq.txt BFS configuration FAQ]].<br />
<br />
=Installation Options=<br />
Users have two options to get these kernel packages.<br />
==1. Compile the Package From Source==<br />
The AUR contains entries for both packages mentioned above. Download and install as you would any other AUR package.<br />
*[http://aur.archlinux.org/packages.php?ID=32877 kernel26-ck]<br />
*[http://aur.archlinux.org/packages.php?ID=45902 kernel26-lts-ck]<br />
<br />
Users can customize the kernel26-ck package via tweaks in the PKGBUILD itself:<br />
<br />
# Optional addition of BFQ patches for the I/O scheduler<br />
# Optional nconfig for tweaking<br />
# Option to compile a minimal set of modules via a make localmodconfig<br />
# Option to bypass the standard ARCH config options and simply use the current kernel's .config file<br />
<br />
More details about these options are provided in the PKBUILD itself via line comments. Be sure to read them if compiling from the AUR!<br />
<br />
{{Note|There are related PKGBUILDs in the AUR for other common modules unique to kernel26-ck. For example [[http://aur.archlinux.org/packages.php?ID=33305 nvidia-ck]], [[http://aur.archlinux.org/packages.php?ID=44643 lirc-ck]], and [[http://aur.archlinux.org/packages.php?ID=48740 broadcom-wl-ck]].}}<br />
<br />
==2. Use Pre-Compiled Packages==<br />
<br />
If users would rather not spend the time to compile on their own, an unofficial repo maintained by [https://wiki.archlinux.org/index.php/User:Graysky graysky] is available to the community.<br />
<br />
{{Note|Starting with version 2.6.38.6-3, repo packages will include the BFQ I/O Scheduler as a module. Read the [[https://wiki.archlinux.org/index.php/Kernel26-ck#How_to_Enable_the_BFQ_I.2FO_Scheduler_.28Repo_Users_Only.29 section]] below for instructions to load it and enable it.}}<br />
<br />
=== Add the repo to your pacman.conf ===<br />
<br />
1) Add the following to your /etc/pacman.conf (I placed my entry at the bottom of the file):<br />
<br />
[kernel26-ck]<br />
Server = http://home.comcast.net/~repo-ck/$arch<br />
<br />
2) Refresh via pacman -Syy<br />
<br />
That's it. To see the contents of the repo, just search as such:<br />
<br />
pacman -Sl kernel26-ck<br />
<br />
=== Installation Examples ===<br />
==== Example on any system (generic packages)====<br />
To install the generic kernel and nvidia module<br />
pacman -S kernel26-ck nvidia-ck<br />
<br />
==== Example on an a specific processor type ====<br />
Refer to the table above for processor-specific optimized builds for i686 and x86_64. The following example is for the core2 optimized builds.<br />
<br />
To install core2 optimized packages for kernel, headers, and nvidia module<br />
pacman -S kernel26-ck-core2 kernel26-ck-core2-headers nvidia-ck-core2<br />
<br />
=== Current CK Package Offerings ===<br />
{| border="1"<br />
| '''Kernel26-ck and headers''' || '''x86_64''' || '''i686'''|| '''Processor Family Specific Optimizations/Description'''<br />
|-<br />
| [https://aur.archlinux.org/packages.php?ID=32877 kernel26-ck] || Yes || Yes || Compiled with generic optimizations suitable for ''any'' compatible CPU just like the official ARCH kernel26 package.<br />
|- <br />
| kernel26-ck-atom || Yes || Yes || Intel Atom platform specific optimizations (Atoms 3xx/4xx/5xx) - '''NOT''' 2xx!<br />
|- <br />
| kernel26-ck-core2 || Yes || Yes || Intel Core 2-family specific optimizations (Core 2/Newer Xeon/Core i3/i5/i7).<br />
|- <br />
| kernel26-ck-k7 || N/A || Yes || AMD Athlon XP specific optimization - '''NOT''' generic k7!<br />
|- <br />
| kernel26-ck-k8 || Yes || Yes || AMD K8-family specific optimizations (K8/K10/Hammer/Athlon64/Opteron).<br />
|-<br />
| kernel26-ck-p4 || No || Yes || Intel Pentium-4 specific optimizations (P4/P4-based Celeron/Pentium-4 M/Older Xeon).<br />
|-<br />
| kernel26-ck-pentm || N/A || Yes || Intel Pentium-M specific optimizations (Pentium-M notebook chips/not Pentium-4 M).<br />
|-<br />
| || || ||<br />
|-<br />
| '''Nvidia-ck Module''' || '''x86_64''' || '''i686'''|| '''Description''' <br />
|-<br />
| [https://aur.archlinux.org/packages.php?ID=33305 nvidia-ck] || Yes || Yes || The matching nVidia kernel module based on 270.xx series of Official nVidia drivers for kernel26-ck.<br />
|-<br />
| nvidia-ck-atom || Yes || Yes ||<br />
|-<br />
| nvidia-ck-core2 || Yes || Yes ||<br />
|-<br />
| nvidia-ck-k7 || N/A || Yes ||<br />
|-<br />
| nvidia-ck-k8 || Yes || Yes ||<br />
|-<br />
| nvidia-ck-p4 || No || Yes ||<br />
|-<br />
| nvidia-ck-pentm || N/A || Yes ||<br />
|- <br />
| || || ||<br />
|-<br />
| '''Broadcom-wl-ck Module''' || '''x86_64''' || '''i686'''|| '''Description''' <br />
|-<br />
| [https://aur.archlinux.org/packages.php?ID=48740 broadcom-wl-ck] || Yes || Yes || The matching Broadcom-wl-ck kernel module for kernel26-ck.<br />
|-<br />
| broadcom-wl-ck-atom || Yes || Yes ||<br />
|-<br />
| broadcom-wl-ck-core2 || Yes || Yes ||<br />
|-<br />
| broadcom-wl-ck-k7 || N/A || Yes ||<br />
|-<br />
| broadcom-wl-ck-k8 || Yes || Yes ||<br />
|-<br />
| broadcom-wl-ck-p4 || No || Yes ||<br />
|-<br />
| broadcom-wl-ck-pentm || N/A || Yes ||<br />
|- <br />
| || || ||<br />
|-<br />
| '''Kernel26-lts-ck and headers''' || '''x86_64''' || '''i686'''|| '''Processor Family Specific Optimizations/Description'''<br />
|-<br />
| [https://aur.archlinux.org/packages.php?ID=45902 kernel26-lts-ck] || Yes || Yes || Compiled with generic optimizations suitable for ''any'' compatible CPU just like the official ARCH kernel26 package.<br />
|-<br />
| || || ||<br />
|-<br />
| '''Nvidia-lts-ck Module''' || '''x86_64''' || '''i686'''|| '''Description''' <br />
|-<br />
| [https://aur.archlinux.org/packages.php?ID=45917 nvidia-lts-ck] || Yes || Yes || The matching nVidia kernel module based on 270.xx series of Official nVidia drivers for kernel26-lts-ck.<br />
|-<br />
|}<br />
<br />
''N/A = Not Available due to hardware limitations.''<br />
<br />
=== How to Enable the BFQ I/O Scheduler (Repo Users Only) ===<br />
{{Note| To avoid confusion, it should be made clear that ''only'' repo users will get the BFQ I/O Scheduler available as a module. Users who chose to build the package from source will need to implicitly switch on the patching of the BFQ and enable it prior to building their kernel!}}<br />
<br />
To enable the BFQ kernel module simply probe it:<br />
# modprobe bfq-iosched<br />
<br />
Now direct your kernel to use it on a device-by-device basis. For example, to enable it for /dev/sda simply:<br />
# echo bfq > /sys/block/sda/queue/scheduler<br />
<br />
To confirm, simply cat the same file:<br />
# cat /sys/block/sda/queue/scheduler<br />
noop deadline cfq [bfq] <br />
<br />
Note that doing it this way will not survive a reboot. To make the change automatically at the next system boot:<br />
<br />
# Place the module in your MODULES array in {{Filename|/etc/rc.conf}}<br />
# Place the echo line in your {{Filename|/etc/rc.local}}<br />
<br />
<br />
Another better way to do this is to append "elevator=bfq" to your kernel boot parameters. This will automatically load the relevant modules and set bfq as the default scheduler. The line should look something like this:<br />
kernel /boot/vmlinuz26 root=/dev/sda1 rootfstype=ext4 ro elevator=bfq<br />
<br />
=== Make Flags and Processor Specific Optimizations ===<br />
{| border="1"<br />
| '''Package''' || '''CFLAGS/CXXFLAGS''' || '''KCFLAGS'''||'''Processor type and features" -> "Processor family"'''<br />
|-<br />
| kernel26-ck || "-march=x86-64 (or i686) -mtune=generic -O2 -pipe -fomit-frame-pointer" || No || Generic-x86-64 (or Pentium-Pro)<br />
|-<br />
| kernel26-ck-atom || "-march=atom -mtune=atom -O2 -pipe -fomit-frame-pointer" || Yes || Intel Atom<br />
|- <br />
| kernel26-ck-core2 || "-march=core2 -mtune=core2 -O2 -pipe -fomit-frame-pointer" || Yes || Core 2/newer Xeon<br />
|- <br />
| kernel26-ck-k7 || "-march=athlon-4 -mtune=athlon -O2 -pipe -fomit-frame-pointer" || Yes || Athlon/Duron/K7<br />
|- <br />
| kernel26-ck-k8 || "-march=x86-64 (or i686) -mtune=generic -O2 -pipe -fomit-frame-pointer" || Yes || Opteron/Athlon64/Hammer/K8<br />
|-<br />
| kernel26-ck-p4 || "-march=x86-64 (or i686) -mtune=generic -O2 -pipe -fomit-frame-pointer" || Yes || Pentium-4/Celeron(P4-based)/Pentium-4 M/older Xeon<br />
|-<br />
| kernel26-ck-pentm || "-march=pentium-m -mtune=generic -O2 -pipe -fomit-frame-pointer" || Yes || Pentium-M notebook chips/not Pentium-4 M<br />
|-<br />
|}<br />
<br />
*Packages are compiled with the CFLAGS/CXXFLAGS indicated in the table above in a clean chroot on x86_64 and i686 respectively.<br />
*Only the generic packages (kernel26-ck) are compiled without the following line whereas all of the CPU-specific build are compiled with it: "export KCFLAGS=${CFLAGS}"<br />
<br />
{{Warning|Users of older Atom processors such as the N270 should not use the atom-specific packages. They should instead use the generic packages.}}<br />
{{Warning|Users AMD Athlon XP processors can safely use the k7 series of packages while users of AMD Athlon/Duron processors should NOT use these packages (see note below). They should instead use the generic packages.}}<br />
{{Note|AMD K10 users can use the k8 packages or the generic packages.}}<br />
<br />
=== Special Note for Kernel26-ck-k7 Package ONLY ===<br />
{{Note|ONLY the k7's config file has been slightly modified - all other packages use config files that are ''identical'' to the ARCH package's config file (except of the ck-patchset related entries).}}<br />
<br />
Modifications to the k7's config file:<pre>Processor type and features ---><br />
[ ] Paravirtualized guest support<br />
Processor family (Athlon/Duron/K7)<br />
(2) Maximum number of CPUs<br />
[ ] Intel MCE features<br />
[ ] SMT (Hyperthreading) scheduler support<br />
[ ] Multi-core scheduler support <br />
< > Toshiba Laptop support<br />
< > Dell laptop support<br />
High Memory Support (off)<br />
[ ] Virtualization<br />
</pre><br />
<br />
=== Package Trivia ===<br />
*Various package sets are compiled via a bash wrapper script for makepkg. The script is publicly accessible at graysky's [[https://github.com/graysky2/repo-ck github]] repo.<br />
<br />
=Questions/Comments=<br />
Please use [https://bbs.archlinux.org/viewtopic.php?id=111715 this discussion thread] to voice comments, questions, suggestions, requests, etc. Note from graysky, "I can add other CPU-specific builds upon request. I just wanna be sure people will actually use them if I take the time to compile them."<br />
<br />
=Further Reading on BFS and CK Patchset=<br />
*[http://ck.kolivas.org/patches/bfs/sched-BFS.txt Con Kolivas' White Paper on the BFS]<br />
*[http://ck.kolivas.org/patches/bfs/bfs-faq.txt Con Kolivas' BFS FAQ]<br />
*[http://en.wikipedia.org/wiki/Brain_Fuck_Scheduler Wikipedia's BFS Article]<br />
*[http://ck-hack.blogspot.com/ Con Kolivas' Blog]<br />
<br />
=Kernel26-ck Package Changelog=<br />
'''13-May-2011 kernel26-ck 2.6.38.6-2'''<br />
<br />
Bump to latest version with a fixed libata regression <br />
http://projects.archlinux.org/svntogit/packages.git/commit/?id=82d1e0060dfe93404bd54305da18469d51e4ee13<br />
<br />
For repo-only versions, the package now comes with the BFQ I/O scheduler built as a module which users can enable at will. Read the [https://wiki.archlinux.org/index.php/Kernel26-ck#How_to_Enable_the_BFQ_I.2FO_Scheduler_.28Repo_Users_Only.29 section] for instructions to load it and enable it.<br />
<br />
<br />
'''11-May-2011 kernel26-ck 2.6.38.6-2'''<br />
<br />
Minor change to the config and config.x86_64: set the CONFIG_FRAME_POINTER option from enabled to disabled. Result will be a slightly smaller and faster kernel image without kernel debugging information (precise oopses/stacktraces/warnings). Note that as of gcc 4.6.0+, the -O2 switch adds the corresponding -fomit-frame-pointer switch to your CFLAGS, so this kernel option seems a bit redundant. <br />
<br />
'''10-May-2011 kernel26-ck 2.6.38.6-1'''<br />
<br />
Bump to late version.<br />
http://projects.archlinux.org/svntogit/packages.git/commit/?id=6d930e1582988016b3f6ac119ffcbfe0bfb4809b<br />
<br />
<br />
'''07-May-2011 kernel26-ck 2.6.38.5-2'''<br />
<br />
Added a line to the PKGBUILD that appends user defined CFLAGS to the KCFLAGS since, as falconindy pointed out in [https://bbs.archlinux.org/viewtopic.php?id=111715&p=8 this thread] (see post #185), the kernel does not use the userland CFLAGS defined in {{Filename|/etc/makepkg.conf}} as we thought.<br />
<br />
<br />
'''03-May-2011 kernel26-ck 2.6.38.5-1'''<br />
<br />
Bump to latest version.<br />
http://projects.archlinux.org/svntogit/packages.git/commit/?id=8a62f9f25cdbe754fa70d448ad7dea6287f2ff71<br />
<br />
'''22-Apr-2011 kernel26-ck 2.6.38.4-1'''<br />
<br />
Bump to latest version.<br />
http://projects.archlinux.org/svntogit/packages.git/commit/?id=31611f00a15d7f1ffc3317afcbc63d6158cea457<br />
<br />
'''17-Apr-2011 kernel26-ck 2.6.38.3-1'''<br />
<br />
Bump to latest version.<br />
http://projects.archlinux.org/svntogit/packages.git/commit/?id=f13814c4550d17d05d2cc36bd01596aecc24b5aa<br />
<br />
Also, updated BFS from v0.400 --> v0.401<br />
<br />
'''15-Apr-2011 kernel26-ck 2.6.38.2-6'''<br />
<br />
Major f*ckup on my part: I included the WRONG config/config.x86_64 when I packaged the -5 release. The 1000 Hz/tickless=n options were still there. This release has the correct settings! Once you update and reboot, you can verify that you have tickless enabled (CONFIG_NO_HZ=y) and that the ARCH default value of 300 Hz is in use (CONFIG_HZ_300=y and CONFIG_HZ=300) from the following command:<br />
<br />
$ zcat /proc/config.gz | grep HZ<br />
<br />
'''14-Apr-2011 kernel26-ck 2.6.38.2-5'''<br />
<br />
Reverted to the ARCH default configs (plus BFS) based on several reports from the community regarding significant decreases in battery life for laptop users.<br />
<br />
'''13-Apr-2011 kernel26-ck 2.6.38.2-4'''<br />
<br />
Changed the configs based on CK's suggestions:<br />
# Disabled dynamic ticks (ARCH default is enabled).<br />
# Tick rate = 1000 Hz (ARCH default is 300 Hz).<br />
<br />
All other options are set to the ARCH defaults outlined in the main kernel's config files. Why the changes? See CK's [[http://ck.kolivas.org/patches/bfs/bfs-configuration-faq.txt BFS configuration FAQ]]. These settings are based on his recommended configuration for "Desktop."<br />
<br />
'''10-Apr-2011 kernel26-ck 2.6.38.2-3'''<br />
<br />
Added official CK3 patchset which includes the BFS v0.400. Functionally, there is no difference between -3 and -2.<br />
http://ck-hack.blogspot.com/2011/04/bfs-0400.html<br />
<br />
'''10-Apr-2011 kernel26-ck 2.6.38.2-2'''<br />
<br />
Added BFS v0.400<br />
<br />
'''30-Mar-2011 kernel26-ck 2.6.38.2-1'''<br />
<br />
Bump to latest version git-svn-id: eb2447ed-0c53-47e4-bac8-5bc4a241df78<br />
<br />
'''29-Mar-2011 kernel26-ck 2.6.38.1-3'''<br />
<br />
Downgraded to ck1 patchset due to regression introduced by the BFS v0.370. For more, see CK's blog: http://ck-hack.blogspot.com/2011/03/2638-ck1-bfs-0363.html<br />
<br />
'''26-Mar-2011 kernel26-ck 2.6.38.1-2'''<br />
<br />
Added CK's bfs363-test2 patch to the standard ck1 patchset. This further refines the bfs on a per-cpu frequency scaling basis and is enabled by default. See CK's blog entry: http://ck-hack.blogspot.com/2011/03/bfs-and-optimising-global-scheduler-for.html<br />
<br />
Files affected:<br />
*{{Filename|kernel/sched_bfs.c}}<br />
*{{Filename|include/linux/sched.h}}<br />
*{{Filename|drivers/cpufreq/cpufreq_conservative.c}}<br />
*{{Filename|drivers/cpufreq/cpufreq_ondemand.c}}<br />
*{{Filename|drivers/cpufreq/cpufreq_userspace.c}}<br />
<br />
Excerpt from the blog, "Not only will the workload complete faster, but almost certainly battery usage will be reduced. It also has no effect without cpu frequency scaling, and no effect on single CPU machines, but the more cores and threads you have, the greater the benefit. Since some new Linux distributions now no longer even allow you to change the governor and just set it to ondemand by default, this change is something that will be essential."<br />
<br />
'''25-Mar-2011 kernel26-ck 2.6.38.1-1'''<br />
<br />
bump to latest version git-svn-id: eb2447ed-0c53-47e4-bac8-5bc4a241df78<br />
<br />
Features included:<br />
- latest stable patches<br />
- disabled /dev/kmem<br />
- added AMD_IOMMU support<br />
- kernel image is now xz compressed<br />
- NUMA is enabled on x86_64<br />
- AUTOSCHED (aka the wonder patch) is enabled<br />
- aufs2.1 latest snapshot <br />
- added additional i915 patch<br />
- added radeaon kms fix <br />
<br />
'''08-Mar-2011 kernel26-ck 2.6.37.3-1'''<br />
<br />
bump to latest version git-svn-id: eb2447ed-0c53-47e4-bac8-5bc4a241df78 <br />
<br />
<br />
'''08-Mar-2011 kernel26-ck 2.6.37.3-1'''<br />
<br />
Bump to latest version git-svn-id: eb2447ed-0c53-47e4-bac8-5bc4a241df78 <br />
<br />
'''25-Feb-2011 kernel26-ck 2.6.37.2-1'''<br />
<br />
Bump to latest version git-svn-id: eb2447ed-0c53-47e4-bac8-5bc4a241df78 <br />
<br />
{{Note|Users will need to have util-linux-2.19-3 and mkinitcpio-0.6.8-2 to use this release.}}<br />
for i686<br />
sudo pacman -U ftp://mirror.rit.edu/archlinux/testing/os/i686/util-linux-2.19-4-i686.pkg.tar.xz ftp://mirror.rit.edu/archlinux/testing/os/i686/mkinitcpio-0.6.8-2-any.pkg.tar.xz<br />
for x86_64<br />
sudo pacman -U ftp://mirror.rit.edu/archlinux/testing/os/x86_64/mkinitcpio-0.6.8-2-any.pkg.tar.xz ftp://mirror.rit.edu/archlinux/testing/os/x86_64/util-linux-2.19-3-x86_64.pkg.tar.xz<br />
<br />
'''23-Feb-2011 kernel26-ck 2.6.37.1-2'''<br />
<br />
Bump dependency to avoid util-linux breakage.<br />
<br />
{{Note|Users will need to have util-linux-2.19-2 and mkinitcpio-0.6.8-2 to use this release.}}<br />
for i686<br />
sudo pacman -U ftp://mirror.rit.edu/archlinux/testing/os/i686/util-linux-2.19-4-i686.pkg.tar.xz ftp://mirror.rit.edu/archlinux/testing/os/i686/mkinitcpio-0.6.8-2-any.pkg.tar.xz<br />
for x86_64<br />
sudo pacman -U ftp://mirror.rit.edu/archlinux/testing/os/x86_64/mkinitcpio-0.6.8-2-any.pkg.tar.xz ftp://mirror.rit.edu/archlinux/testing/os/x86_64/util-linux-2.19-3-x86_64.pkg.tar.xz<br />
<br />
'''19-Feb-2011 kernel26-ck 2.6.37.1-1'''<br />
<br />
Bump to latest version - thanks to koeleck for providing [[http://aur.pastebin.com/ajz5yyUC this patch]] to fix the ck2 patchset!<br />
<br />
'''13-Feb-2011 kernel26-ck 2.6.37-7'''<br />
<br />
Includes ck2 patchset not ck1 patchset. From ck's blog:<br />
<br />
"I've put up a small updated -ck version for 2.6.37. There are only 2 changes: 1. The build fix for it not compiling with CPU HOTPLUG disabled, and 2. I've dropped the patch called mm-make_swappiness_really_mean_it.patch . This second patch broke a while back and I never noticed because I had swap disabled, sorry. It works better with it disabled. Note that the ubuntu packages I recently made available include this change which I quietly snuck in, but I will make ck2 packages officially available just to avoid confusion ;) If you've built your own 2.6.37-ck1 then I recommend upgrading only if you have swap enabled on your machine (which most people still do). Alternatively if you built it with CPU_HOTPLUG enabled just to make it build, then you _can_ upgrade to this version to build with it disabled but you won't notice a difference with the feature disabled - your kernel will only be slightly smaller. It might be a few nanoseconds faster.." <br />
<br />
'''12-Feb-2011 kernel26-ck/headers-ck 2.6.37-6'''<br />
<br />
rebuild against latest glibc, binutils git-svn-id: 109724 eb2447ed-0c53-47e4-bac8-5bc4a241df78<br />
<br />
I am reading this as glibc 2.13-3 and binutils 2.21-4, both of which are currently in [testing] need to be installed prior to kernel compilation. I can install both of these testing packages on my machine, and compile for the repo, but individual users will have to install those packages, THEN compile their own kernels... therefore both glibc and binuntils have been ''temporarily'' added to the deps array in the PKGBUILD. Users will need to snag them either by enabling [testing] in /etc/pacman.conf or simply by downloading via pacman -U.<br />
<br />
Example on x86_64:<br />
<pre>pacman -U ftp://ftp.gtlib.gatech.edu/pub/linux/distributions/archlinux/testing/os/x86_64/glibc-2.13-3-x86_64.pkg.tar.xz ftp://ftp.gtlib.gatech.edu/pub/linux/distributions/archlinux/testing/os/x86_64/binutils-2.21-4-x86_64.pkg.tar.xz</pre><br />
<br />
Example on i686:<br />
<pre>pacman -U ftp://ftp.gtlib.gatech.edu/pub/linux/distributions/archlinux/testing/os/i686/binutils-2.21-4-i686.pkg.tar.xz ftp://ftp.gtlib.gatech.edu/pub/linux/distributions/archlinux/testing/os/i686/glibc-2.13-3-i686.pkg.tar.xz</pre><br />
<br />
'''29-Jan-2011 kernel26-ck/headers-ck 2.6.37-5'''<br />
<br />
fix module-init-tools dependency git-svn-id: eb2447ed-0c53-47e4-bac8-5bc4a241df78 <br />
<br />
It's a very MINOR change. Same ARCH patch set (-4) and same config files. Other than that change, it's identical to -4.<br />
<br />
s/module-init-tools/module-init-tools>=3.12-2/<br />
<br />
'''27-Jan-2011 kernel26-ck/headers-ck 2.6.37-4'''<br />
<br />
added i915 patch git-svn-id: eb2447ed-0c53-47e4-bac8-5bc4a241df78<br />
removed nfs idmapper option git-svn-id: eb2447ed-0c53-47e4-bac8-5bc4a241df78 <br />
<br />
'''26-Jan-2011 kernel26-ck/headers-ck 2.6.37-3'''<br />
<br />
rebuild with mkinitcpio bump to 0.6.8 and gzipped modules saves 70MB space git-svn-id: eb2447ed-0c53-47e4-bac8-5bc4a241df78<br />
<br />
'''24-Jan-2011 kernel26-ck/headers-ck 2.6.37-2'''<br />
<br />
fix udev crash, updated aufs, changed ext3 mount default git-svn-id: eb2447ed-0c53-47e4-bac8-5bc4a241df78</div>Jnguyenhttps://wiki.archlinux.org/index.php?title=Nouveau&diff=141731Nouveau2011-05-16T21:52:49Z<p>Jnguyen: /* Installation */</p>
<hr />
<div>[[Category: Graphics (English)]]<br />
[[Category: X Server (English)]]<br />
[[Category: HOWTOs (English)]]<br />
{{i18n|Nouveau}}<br />
{{Article summary start}}<br />
{{Article summary text|This article details the installation of the Nouveau Open Source 3D acceleration graphics driver for NVIDIA cards. The name of the project refers to the fact that "nouveau" means "new" in French.}}<br />
{{Article summary heading|Related}}<br />
{{Article summary wiki|KMS}}<br />
{{Article summary wiki|Xorg}}<br />
{{Article summary wiki|NVIDIA}}<br />
{{Article summary end}}<br />
<br />
[http://nouveau.freedesktop.org/wiki/ Nouveau] is an open source graphic driver for NVIDIA cards.<br />
Do not forget to check out the [http://nouveau.freedesktop.org/wiki/FAQ FAQ] if you have any questions, as there is a lot of valuable information there.<br />
<br />
==Installation==<br />
Before proceeding, have a look at the [http://nouveau.freedesktop.org/wiki/FeatureMatrix FeatureMatrix] to see what features are supported for a given architecture, and the list of [http://nouveau.freedesktop.org/wiki/CodeNames codenames] to determine the card's category.<br />
<br />
You could also consult [[Wikipedia:Comparison of Nvidia Graphics Processing Units|wikipedia]] for an even more detailed list.<br />
<br />
Install the following packages:<br />
# pacman -S xf86-video-nouveau<br />
<br />
If you want experimental Gallium3D features:<br />
# pacman -S nouveau-dri mesa libgl<br />
<br />
Also make sure you have Xorg properly installed.<br />
<br />
Don't forget to [[Nouveau#Configuration|enable the Xorg driver]] after installing the Nouveau packages.<br />
<br />
{{Warning|3D acceleration is still not officially supported, so don't report any bugs unless you are looking to contribute patches.}}<br />
<br />
==Loading==<br />
<br />
If you kept the proprietary nvidia driver installed, nouveau is probably not going to work.<br />
Either '''uninstall the proprietary Nvidia driver''' <br />
<br />
pacman -Rdd nvidia nvidia-utils<br />
<br />
or '''blacklist it''' by adding the following line to /etc/modprobe.d/modprobe.conf<br />
<br />
blacklist nvidia<br />
<br />
Then nouveau should load fine automatically on next reboot. To test it now, first make sure nvidia is no longer loaded<br />
# rmmod nvidia<br />
Then load nouveau<br />
# modprobe nouveau<br />
And check that it loaded fine by looking at kernel messages<br />
$ dmesg<br />
<br />
'''Note:''' You can use [https://wiki.archlinux.org/index.php/NVIDIA#Switching_between_nvidia_and_nouveau_drivers those scripts] if you are switching between open and closed drivers often.<br />
<br />
==Configuration==<br />
Create the file {{Filename|/etc/X11/xorg.conf.d/20-nouveau.conf}}, and input the following contents:<br />
Section "Device"<br />
Identifier "Nvidia card"<br />
Driver "nouveau"<br />
EndSection<br />
<br />
This is '''required''' to ensure that nouveau driver is loaded. Xorg''' does not yet automatically load the xf86-video-nouveau driver'''.<br />
<br />
==KMS==<br />
Kernel Mode-Setting ([[KMS]]) is required by the Nouveau driver. See the [http://nouveau.freedesktop.org/wiki/KernelModeSetting KernelModeSetting] page for more information.<br />
<br />
===Late start===<br />
With this choice, KMS will be enabled when the boot process says, "Loading modules." This may cause an undesirable screen flicker as the mode changes.<br />
<br />
Remove all "vga=" options from your kernel commandline in {{Filename|/boot/grub/menu.lst}}. Using other framebuffer drivers (such as uvesafb) will conflict with KMS.<br />
<br />
===Early start===<br />
{{Warning|If you have troubles with nouveau, and are led to rebuild nouveau-drm several times for testing purpose, do not add nouveau to the initramfs. It is too easy to forget to rebuild the initramfs and it will just make any testing harder. Just use ''late start''. There might be additional problems with initramfs if you need a firmware for the nv50 family}}<br />
<br />
This method will start KMS as early as possible in the boot process, when the [[initramfs]] is loaded. Here is how to do this with the official packages:<br />
<br />
1) Add "nouveau" to the ''MODULES'' array in {{Filename|/etc/mkinitcpio.conf}}:<br />
MODULES="'''nouveau''' ..."<br />
<br />
2) Add "/etc/modprobe.d/modprobe.conf" to the FILES section in {{Filename|/etc/mkinitcpio.conf}}:<br />
FILES="/etc/modprobe.d/modprobe.conf"<br />
<br />
3) Re-generate your initcpio:<br />
# mkinitcpio -p <''your kernel preset (kernel26, etc.)''><br />
<br />
<small>You can also look at the [[Intel]] instructions for an early start: [[Intel#KMS_.28Kernel_Mode_Setting.29|Intel Graphics:KMS (Kernel Mode Setting)]]</small><br />
<br />
==Alternative installation [latest Mesa]==<br />
<br />
You may install the latest -git packages, through AUR. You can use [http://aur.archlinux.org/packages.php?ID=8266 mesa-git] which will allow the installation of the latest Mesa.<br />
<br />
You can also try installing a newer kernel version, through packages like [http://aur.archlinux.org/packages.php?ID=39965 kernel26-mainline] in which the Nouveau DRM code would allow better performance.<br />
<br />
==DualHead==<br />
Nouveau supports the xrandr extension for modesetting and multiple monitors. See the [[RandR12]] page for tutorials.<br />
<br />
Here is a full sample {{Filename|/etc/X11/xorg.conf}} above for running 2 monitors in dual head mode. You may prefer to use a graphical tool to configure monitors like gnome-display-properties (System -> Preferences -> Display).<br />
<pre><br />
# the right one<br />
Section "Monitor"<br />
Identifier "NEC"<br />
Option "PreferredMode" "1280x1024_60.00"<br />
EndSection<br />
<br />
# the left one<br />
Section "Monitor"<br />
Identifier "FUS"<br />
Option "PreferredMode" "1280x1024_60.00"<br />
Option "LeftOf" "NEC"<br />
EndSection<br />
<br />
Section "Device"<br />
Identifier "nvidia card"<br />
Driver "nouveau"<br />
Option "Monitor-DVI-I-0" "NEC"<br />
Option "Monitor-DVI-I-1" "FUS"<br />
EndSection<br />
<br />
Section "Screen"<br />
Identifier "screen1"<br />
DefaultDepth 24<br />
SubSection "Display"<br />
Depth 24<br />
Virtual 2560 1024<br />
EndSubSection<br />
Device "nvidia card"<br />
EndSection<br />
<br />
Section "ServerLayout"<br />
Identifier "layout1"<br />
Screen "screen1"<br />
EndSection<br />
</pre><br />
<br />
==Setting console resolution==<br />
Use the {{Package Official|fbset}} tool to adjust console resolution.<br />
<br />
You can also pass the resolution to nouveau with the video= kernel line option (see [[KMS]]).</div>Jnguyenhttps://wiki.archlinux.org/index.php?title=AppArmor&diff=139738AppArmor2011-05-04T22:12:18Z<p>Jnguyen: </p>
<hr />
<div>[[Category:Security (English)]]<br />
[[Category:Kernel (English)]]<br />
[[Category:Networking (English)]]<br />
[[Category:HOWTOs (English)]]<br />
[[Wikipedia:AppArmor|AppArmor]] is a MAC (Mandatory Access Control) system, implemented upon LSM (Linux Security Modules).<br />
<br />
== Implementation Status ==<br />
AppArmor is currently available in Arch Linux kernel and [[AUR]], but we still don't have the user-space tools tested:<br />
* http://aur.archlinux.org/packages.php?ID=42279<br />
* https://bugs.archlinux.org/task/21406<br />
<br />
It will take some time to make everything work Out-of-the-box.<br />
<br />
=== aur/apparmor package ===<br />
Added lot of features:<br />
* apparmor-parser<br />
* libapparmor<br />
* apparmor-utils<br />
* apparmor-profiles<br />
* apparmor-notify<br />
* apparmor-lib<br />
* apparmor-perl<br />
* apparmor-python<br />
* apparmor-ruby<br />
* apparmor-dbus<br />
* apparmor-profile-editor<br />
<br />
But we still miss following features (TODO):<br />
* init (rc.d) scripts! http://aur.pastebin.com/beQ4BjGX<br />
* chase missing dependencies<br />
* test everything<br />
* make list of files that should go to backup=() arrays in packages...<br />
* changehat modules for PAM(!), Apache and Tomcat (btw those are dependent on libapparmor)<br />
* out-of-box-experience know-how<br />
** make some package with profiles for all [core] packages enabled by default without need for any further user configuration<br />
** etc...<br />
* apparmor gnome applet (can't build, deprecated...)<br />
<br />
==== When compared to Ubuntu ====<br />
we have almost everything that is in following Ubuntu packages:<br />
* apparmor<br />
* apparmor-profiles<br />
* apparmor-utils<br />
* apparmor-notify<br />
* apparmor-docs<br />
* libapparmor1<br />
* libapparmor-dev<br />
* libapparmor-perl<br />
<br />
We don't have<br />
* /etc/init.d/apparmor http://aur.pastebin.com/beQ4BjGX<br />
* packages: libapache2-mod-apparmor libpam-apparmor<br />
* KNOW-HOW<br />
<br />
== Links ==<br />
* Official pages<br />
** kernel: https://apparmor.wiki.kernel.org/<br />
** userspace: https://launchpad.net/apparmor<br />
<br />
* http://ubuntuforums.org/showthread.php?t=1008906 (Very good tutorial on HOWTO make profiles and configure AppArmor)<br />
* https://help.ubuntu.com/community/AppArmor<br />
* https://bugs.archlinux.org/task/21406<br />
* http://stuff.mit.edu/afs/sipb/contrib/linux/Documentation/apparmor.txt <br />
* https://apparmor.wiki.kernel.org/index.php/Kernel_interfaces<br />
* https://apparmor.wiki.kernel.org/index.php/AppArmor_versions<br />
* http://manpages.ubuntu.com/manpages/maverick/man5/apparmor.d.5.html<br />
* http://manpages.ubuntu.com/manpages/maverick/man8/apparmor_parser.8.html<br />
* https://apparmor.wiki.kernel.org/index.php/Distro_CentOS<br />
* http://bodhizazen.net/aa-profiles/<br />
* https://wiki.ubuntu.com/ApparmorProfileMigration<br />
* http://en.wikipedia.org/wiki/Linux_Security_Modules<br />
* https://apparmor.wiki.kernel.org/index.php/Gittutorial<br />
* http://kernel.org/pub/linux/security/apparmor/apparmor-2.6.36-patches.tgz<br />
<br />
== AppArmor Packages ==<br />
* kernel26 >= 2.6.36 have AppArmor support<br />
* aur/[http://aur.archlinux.org/packages.php?ID=42279 apparmor]<br />
<br />
== Kernel Configuration ==<br />
Here is configuration of ArchLinux kernel which enables AppArmor (just FYI, you don't need to touch it):<br />
CONFIG_SECURITY_APPARMOR=y<br />
CONFIG_SECURITY_APPARMOR_BOOTPARAM_VALUE=0<br />
# CONFIG_DEFAULT_SECURITY_APPARMOR is not set<br />
<br />
However, integration of AppArmor into the 2.6.36 kernel is not quite complete. It is missing network mediation and some of the interfaces for introspection. See [https://apparmor.wiki.kernel.org/index.php/Apparmor/upstream_release_notes here] for details. There are compatibility patches that can be applied on top of the 2.6.36 kernel to reintroduce these interfaces, but do not currently build against the Arch Linux kernel.<br />
<br />
== GRUB Configuration ==<br />
=== GRUB1 ===<br />
To test profiles, or enforce the use of AppArmor it must be enabled at boot time. To do this add apparmor=1 security=apparmor to the kernel boot parameters in /boot/grub/menu.lst so the entry for the Arch Linux kernel looks something like<br />
<br />
# (0) Arch Linux<br />
title Arch Linux [/boot/vmlinuz26]<br />
root (hd0,1)<br />
kernel /boot/vmlinuz26 root=/dev/sdaX resume=/dev/sdaY ro '''apparmor=1 security=apparmor'''<br />
initrd /boot/kernel26.img<br />
<br />
Once you are happy with all your profiles, you may wish to force users to boot with AppArmor enabled. To do this add a password entry to the start of /boot/grub/menu.lst. This will prevent users editing any boot entries or using the Grub shell (which permits read access to any file on the system such as /etc/shadow) before booting. You can also password protect any insecure entries in /boot/grub/menu.lst that you do not want unauthorized users to boot by adding the lock command (or another password) immediately below the title line for that entry. See [[Grub#Password_protection]] or [http://www.gnu.org/software/grub/manual/legacy/Security.html#Security Security in the Grub Manual] for more details. If you are going to the trouble of securing Grub don't forget to secure your BIOS settings as well or users will be able to boot from their own CDs and USB sticks, gaining root access to the machine.<br />
<br />
=== GRUB2 ===<br />
<br />
==== Enable ====<br />
Note that you can safely enable apparmor and '''it will not affect the system''' at all until you will enable it, load profiles and set them to enforce mode by userspace tools. So you don't have to be afraid to enable AA for testing purposes until you are enforcing AA profiles from init scripts (on each startup).<br />
<br />
# (0) Arch Linux<br />
menuentry "Arch Linux" {<br />
set root=(hd0,1)<br />
linux /vmlinuz26 root=/dev/sda1 ro '''apparmor=1 security=apparmor'''<br />
initrd /kernel26.img<br />
}<br />
<br />
After reboot you can test if apparmor is really enabled using this command as root:<br />
# cat /sys/module/apparmor/parameters/enabled <br />
Y<br />
(Y=enabled, N=disabled, no such file = module not in kernel)<br />
<br />
==== Disable ====<br />
AppArmor will be disabled by default in ArchLinux, so you will not need to disable it explicitly until you will build your own kernel with AppArmor enabled by default.<br />
# (0) Arch Linux<br />
menuentry "Arch Linux" {<br />
set root=(hd0,1)<br />
linux /vmlinuz26 root=/dev/sda1 ro '''apparmor=0 security=""'''<br />
initrd /kernel26.img<br />
}<br />
<br />
== System Configuration ==<br />
=== Mounts (/etc/fstab securityfs) ===<br />
https://apparmor.wiki.kernel.org/index.php/Kernel_interfaces<br />
none /sys/kernel/security securityfs defaults 0 0<br />
<br />
=== Init scripts ===<br />
In future we'll implement some /etc/rc.d/ scripts that will enable and load profiles during startup.<br />
http://aur.pastebin.com/beQ4BjGX<br />
The RC.d file of Slackware might be more interesting than ubuntu's init.d version<br />
http://sprunge.us/IbeJ<br />
<br />
==== For developers ====<br />
<br />
from /lib/apparmor/rc.apparmor.functions<br />
<br />
# NOTE: rc.apparmor initscripts that source this file need to implement<br />
# the following set of functions:<br />
# aa_action<br />
# aa_log_action_start<br />
# aa_log_action_end<br />
# aa_log_success_msg<br />
# aa_log_warning_msg<br />
# aa_log_failure_msg<br />
# aa_log_skipped_msg<br />
# aa_log_daemon_msg<br />
# aa_log_end_msg<br />
<br />
== UserSpace Tools ==<br />
=== Users ===<br />
You can currently install userspace tools from [[AUR]].<br />
<br />
=== Maintainers ===<br />
You need userspace tools that are compatible with your kernel version. The compatibility list can be found here: https://apparmor.wiki.kernel.org/index.php/AppArmor_versions<br />
eg.: Kernel 2.6.36 is compatible with AppArmor 2.5.1<br />
<br />
== More Info ==<br />
Ubuntu, Suse and a number of other Linux distributions use it. Redhat uses SELINUX which is apparently a little bit more difficult to configure properly.<br />
<br />
It suplements, rather than replaces the standard POSIX access control system.<br />
<br />
What you can do with it is very easily create profiles for applications which either acccess the Internet or listen via IP (e.g servers).<br />
<br />
One may specify at quite a fine grained level what applications may or may not do. <br />
<br />
Taking a common example - Firefox is frequently the victim of Zero day exploits. If you were to browse to a website that ran a buffer overflow or such thing against your browser - all data accessible to Firefox would then belong to the attackers, think SSH keys, password stores etc etc.<br />
<br />
Likewise Wireshark (tcpdump) has had decoder modules with buffer overflows before, imagine the scenario - you suspect a server has been compromised, run a packet capture on the network, and then your own machine is compromised (tcpdump must run as root).<br />
<br />
For both these applications, apparmor profiles exist. The configuration is stored in easy to read text files in /etc/apparmor.d/<application name>.<br />
<br />
You can lock down your applications using wildcards, specifying for example that Firefox can only read the ~/Downloads folder and it's own profile directory, that it cannot create shell processes etc.<br />
<br />
Every breach of policy triggers a message in the syslog, many distributions also integrate it into DBUS so that you get realtime violation warnings popping up on your desktop.<br />
<br />
== See also ==<br />
* [[TOMOYO Linux]]<br />
* [[SELinux]]<br />
* [[DNSSEC]]</div>Jnguyenhttps://wiki.archlinux.org/index.php?title=Udev&diff=139678Udev2011-05-04T14:02:19Z<p>Jnguyen: /* UDisks Shell Functions */</p>
<hr />
<div>[[Category:Hardware detection and troubleshooting (English)]]<br />
[[Category:HOWTOs (English)]]<br />
[[Category:Auto-mounting (English)]]<br />
{{i18n|Udev}}<br />
<br />
== Introduction ==<br />
''"udev is the device manager for the Linux 2.6 kernel series. Primarily, it manages device nodes in {{Filename|/dev}}. It is the successor of devfs and hotplug, which means that it handles the {{Filename|/dev}} directory and all user space actions when adding/removing devices, including firmware load."'' Source: [http://en.wikipedia.org/wiki/Udev Wikipedia]<br />
<br />
udev replaces the functionality of both {{Codeline|hotplug}} and {{Codeline|hwdetect}}.<br />
<br />
udev loads kernel modules by utilizing coding parallelism to provide a potential performance advantage versus loading these modules serially. The modules are therefore loaded asynchronously. The inherent disadvantage of this method is that udev does not always load modules in the same order on each boot. If the machine has multiple block devices, this may manifest itself in the form of device nodes changing designations randomly. For example, if the machine has two hard drives, /dev/sda may randomly become /dev/sdb. See below for more info on this.<br />
<br />
==About modules auto-loading==<br />
udev will not do ''any'' module loading for you unless {{Codeline|MOD_AUTOLOAD}} is enabled in {{Filename|/etc/rc.conf}}. If you disable auto-loading you must manually load the modules you want/need by putting the list in the {{Codeline|MODULES}} array in {{Filename|[[rc.conf]]}}, you can generate this list with the {{Codeline|hwdetect --modules}} command.<br />
<br />
==About udev rules==<br />
udev rules go in {{Filename|/etc/udev/rules.d/}}, their file name has to end with {{Filename|.rules}}.<br />
<br />
If you want to learn how to write udev rules see [http://www.reactivated.net/writing_udev_rules.html Writing udev rules].<br />
<br />
To get a list of all the attributes of a device you can use to write rules:<br />
# udevadm info -a -p $(udevadm info -q path -n [device name])<br />
<br />
Replace [device name] with the device present in the system, such as '/dev/sda' or '/dev/ttyUSB0'.<br />
<br />
To restart the udev system once you create or modify udev rules, run the following command. Hotpluggable devices, such as USB devices, will probably have to be reconnected for the new rules to take effect.<br />
# udevadm control --reload-rules<br />
<br />
== Tips & Tricks ==<br />
=== UDisks ===<br />
Simply install UDisks:<br />
pacman -S udisks<br />
and all your media should be auto mounted in GNOME and KDE SC 4.6. There is no need for any additional rules this way.<br />
As an extra bonus you can remove HAL if you were only using that for auto mounting purposes.<br />
<br />
==== Automounting UDisks Wrappers ====<br />
A UDisks wrapper has the advantage of being very easy to install and needing no (or minimal) configuration. The wrapper will automatically mount things like CDs and flash drives.<br />
<br />
* [http://igurublog.wordpress.com/downloads/script-devmon/ devmon] - devmon ([http://aur.archlinux.org/packages.php?ID=45842 AUR]) is a configuration-less bash wrapper script for udisks which automounts optical discs and removable drives. It can also selectively autostart apps or execute commands after mounting, ignore specified devices and volume labels, and unmount removable drives. <br />
* [[udiskie]] - Written in Python. Allows auto mount and unmount by any user.<br />
* [http://aur.archlinux.org/packages.php?ID=38723 udisksevt] - Written in Haskell. Allows auto mount by any user. Designed to be integrated with [http://aur.archlinux.org/packages.php?ID=32005 traydevice].<br />
* The [http://aur.archlinux.org/packages.php?ID=46572 udisksvm bash script] uses udisks and [http://aur.archlinux.org/packages.php?ID=32005 Traydevice] to automount removable media and to control in GUI, with mouse clicks in systray, the un-mounting and re-mounting of disks or the ejection of optical disks.<br />
<br />
==== UDisks Shell Functions ====<br />
While UDisks includes a simple method of (un)mounting devices via command-line, it can be tiresome to type the commands out each time. These shell functions will generally shorten and ease command-line usage.<br />
<br />
* [https://bbs.archlinux.org/viewtopic.php?id=109307 udisks_functions] - Written for Bash.<br />
* [https://bbs.archlinux.org/viewtopic.php?id=117674 bashmount] - bashmount [http://aur.archlinux.org/packages.php?ID=48524 (AUR)] is a menu-driven bash script with a configuration file that makes it easy to configure and extend.<br />
<br />
=== Auto mounting USB devices ===<br />
{{Note|In the following rules the mount options are defined as {{Codeline|<nowiki>ENV{mount_options}="relatime"</nowiki>}}, see {{Codeline|man mount}} (and possibly {{Codeline|man ntfs-3g}}) for all available options and [[Maximizing Performance#Mount options]] for performance-related options.}}<br />
{{Note|The {{Codeline|users}} mount option will '''not''' allow users to unmount the filesystem.}}<br />
{{Tip|The {{Codeline|noexec}} mount option prevents execution of binaries on the mounted filesystem.}}<br />
<br />
==== Mount under {{Filename|/media}}; use partition label if present ====<br />
The following udev rule set automatically mounts devices/partitions that are represented by /dev/sd* (USB drives, external hard drives and sometimes SD cards). If a partition label is available, it mounts the device to /media/<label> and otherwise to /media/usbhd-sd* (ex: /media/usbhd-sdb1):<br />
{{File|name=/etc/udev/rules.d/11-media-by-label-auto-mount.rules|content=<nowiki><br />
KERNEL!="sd[a-z][0-9]", GOTO="media_by_label_auto_mount_end"<br />
<br />
# Import FS infos<br />
IMPORT{program}="/sbin/blkid -o udev -p %N"<br />
<br />
# Get a label if present, otherwise specify one<br />
ENV{ID_FS_LABEL}!="", ENV{dir_name}="%E{ID_FS_LABEL}"<br />
ENV{ID_FS_LABEL}=="", ENV{dir_name}="usbhd-%k"<br />
<br />
# Global mount options<br />
ACTION=="add", ENV{mount_options}="relatime"<br />
# Filesystem-specific mount options<br />
ACTION=="add", ENV{ID_FS_TYPE}=="vfat|ntfs", ENV{mount_options}="$env{mount_options},utf8,gid=100,umask=002"<br />
<br />
# Mount the device<br />
ACTION=="add", RUN+="/bin/mkdir -p /media/%E{dir_name}", RUN+="/bin/mount -o $env{mount_options} /dev/%k /media/%E{dir_name}"<br />
<br />
# Clean up after removal<br />
ACTION=="remove", ENV{dir_name}!="", RUN+="/bin/umount -l /media/%E{dir_name}", RUN+="/bin/rmdir /media/%E{dir_name}"<br />
<br />
# Exit<br />
LABEL="media_by_label_auto_mount_end"<br />
</nowiki>}}<br />
<br />
==== Mount under {{Filename|/media}}; use partition label if present; support LUKS encryption ====<br />
Similar to the above rule set, but if the device is a LUKS-encrypted partition it will open an xterm window to ask for the passphrase (provided that xterm is installed). Also see [http://bbs.archlinux.org/viewtopic.php?pid=696239#p696239 this post] and the follow-ups.<br />
<br />
{{Note|You may need to modify the path to cryptsetup, depending on the version installed (e.g., < 1.1.1_rc2-1).}}<br />
<br />
{{File|name=/etc/udev/rules.d/11-media-by-label-auto-mount.rules|content=<nowiki><br />
KERNEL!="sd[a-z]*", GOTO="media_by_label_auto_mount_end"<br />
ACTION=="add", PROGRAM!="/sbin/blkid %N", GOTO="media_by_label_auto_mount_end"<br />
<br />
# Do not mount devices on boot because otherwise fsck may fail<br />
ACTION=="add", PROGRAM!="/bin/grep ' / / rw[, ]' /proc/self/mountinfo", GOTO="media_by_label_auto_mount_end"<br />
<br />
# Open LUKS partition if necessary<br />
PROGRAM=="/sbin/blkid -o value -s TYPE %N", RESULT=="crypto_LUKS", ENV{crypto}="mapper/", ENV{device}="/dev/mapper/%k"<br />
ENV{crypto}=="", ENV{device}="%N"<br />
ACTION=="add", ENV{crypto}!="", PROGRAM=="/usr/bin/xterm -display :0.0 -e 'echo Password for /dev/%k; /sbin/cryptsetup luksOpen %N %k'"<br />
ACTION=="add", ENV{crypto}!="", TEST!="/dev/mapper/%k", GOTO="media_by_label_auto_mount_end"<br />
<br />
# Global mount options<br />
ACTION=="add", ENV{mount_options}="noatime"<br />
# Filesystem-specific mount options<br />
ACTION=="add", PROGRAM=="/sbin/blkid -o value -s TYPE %E{device}", RESULT=="vfat|ntfs", ENV{mount_options}="%E{mount_options},utf8,gid=100,umask=002"<br />
<br />
# Get label if present, otherwise assign one<br />
PROGRAM=="/sbin/blkid -o value -s LABEL %E{device}", ENV{dir_name}="%c"<br />
# Use basename to correctly handle labels such as ../mnt/foo<br />
PROGRAM=="/usr/bin/basename '%E{dir_name}'", ENV{dir_name}="%c"<br />
ENV{dir_name}=="", ENV{dir_name}="usbhd-%k"<br />
<br />
# Mount the device<br />
ACTION=="add", ENV{dir_name}!="", RUN+="/bin/mkdir -p '/media/%E{dir_name}'", RUN+="/bin/mount -o %E{mount_options} /dev/%E{crypto}%k '/media/%E{dir_name}'"<br />
<br />
# Clean up after removal<br />
ACTION=="remove", ENV{dir_name}!="", RUN+="/bin/umount -l '/media/%E{dir_name}'"<br />
ACTION=="remove", ENV{crypto}!="", RUN+="/sbin/cryptsetup luksClose %k"<br />
ACTION=="remove", ENV{dir_name}!="", RUN+="/bin/rmdir '/media/%E{dir_name}'"<br />
<br />
# Exit<br />
LABEL="media_by_label_auto_mount_end"<br />
</nowiki>}}<br />
<br />
==== Mount under {{Filename|/media}}; use partition label if present; support user un-mounting ====<br />
This is a variation on the above rule set. It uses pmount (which will need to be installed) instead of mount, allowing a non-root user to unmount udev-mounted devices. The required username must be hard-coded in the RUN command, so this rule set may not be suitable for multi-user systems. LUKS support has also been removed from the example, but can be easily reinstated as above. You must edit the /bin/su invocation to run as the correct user for your system.<br />
{{File|name=/etc/udev/rules.d/11-media-by-label-with-pmount.rules|content=<nowiki><br />
KERNEL!="sd[a-z]*", GOTO="media_by_label_auto_mount_end"<br />
ACTION=="add", PROGRAM!="/sbin/blkid %N", GOTO="media_by_label_auto_mount_end"<br />
<br />
# Get label<br />
PROGRAM=="/sbin/blkid -o value -s LABEL %N", ENV{dir_name}="%c"<br />
# use basename to correctly handle labels such as ../mnt/foo<br />
PROGRAM=="/usr/bin/basename '%E{dir_name}'", ENV{dir_name}="%c"<br />
ENV{dir_name}=="", ENV{dir_name}="usbhd-%k"<br />
<br />
ACTION=="add", ENV{dir_name}!="", RUN+="/bin/su tomk -c '/usr/bin/pmount %N %E{dir_name}'"<br />
ACTION=="remove", ENV{dir_name}!="", RUN+="/bin/su tomk -c '/usr/bin/pumount /media/%E{dir_name}'"<br />
LABEL="media_by_label_auto_mount_end"<br />
</nowiki>}}<br />
<br />
==== Mount under {{Filename|/mnt}}; create symbolic link under {{Filename|/media}} ====<br />
The following rule set does not make use of partition labels; instead it mounts devices as usbhd-sdXY under the /mnt directory (ex: /mnt/usbhd-sdb1) and creates a symbolic link under /media.<br />
{{File|name=/etc/udev/rules.d/11-mnt-auto-mount.rules|content=<nowiki><br />
KERNEL!="sd[a-z][0-9]", GOTO="mnt_auto_mount_end"<br />
<br />
# Global mount options<br />
ACTION=="add", ENV{mount_options}="relatime"<br />
# Filesystem-specific mount options<br />
ACTION=="add", IMPORT{program}="/sbin/blkid -o udev -p %N"<br />
ACTION=="add", ENV{ID_FS_TYPE}=="vfat|ntfs", ENV{mount_options}="$env{mount_options},utf8,gid=100,umask=002"<br />
<br />
# Mount under /mnt and create the symbolic link in /media <br />
ACTION=="add", RUN+="/bin/mount -o $env{mount_options} /dev/%k /mnt/usbhd-%k", RUN+="/bin/ln -s /mnt/usbhd-%k /media/usbhd-%k"<br />
<br />
# Clean up after removal<br />
ACTION=="remove", RUN+="/bin/rm -f /media/usbhd-%k", RUN+="/bin/umount -l /mnt/usbhd-%k", RUN+="/bin/rmdir /mnt/usbhd-%k"<br />
<br />
# Exit<br />
LABEL="mnt_auto_mount_end"<br />
</nowiki>}}<br />
<br />
==== Mount under {{Filename|/media}} ''only'' if the partition has a label ====<br />
{{File|name=/etc/udev/rules.d/11-media-by-label-only-auto-mount.rules|content=<nowiki><br />
KERNEL!="sd[a-z][0-9]", GOTO="media_by_label_only_auto_mount_end"<br />
<br />
# Import FS infos<br />
IMPORT{program}="/sbin/blkid -o udev -p %N"<br />
ENV{ID_FS_LABEL}=="", GOTO="media_by_label_only_auto_mount_end"<br />
<br />
# Global mount options<br />
ACTION=="add", ENV{mount_options}="relatime"<br />
# Filesystem-specific mount options<br />
ACTION=="add", ENV{ID_FS_TYPE}=="vfat|ntfs", ENV{mount_options}="$env{mount_options},utf8,gid=100,umask=002"<br />
<br />
# Mount the device<br />
ACTION=="add", RUN+="/bin/mkdir -p /media/$env{ID_FS_LABEL}", RUN+="/bin/mount -o $env{mount_options} /dev/%k /media/$env{ID_FS_LABEL}"<br />
<br />
# Clean up after removal<br />
ACTION=="remove", ENV{ID_FS_LABEL}!="", RUN+="/bin/umount -l /media/$env{ID_FS_LABEL}", RUN+="/bin/rmdir /media/$env{ID_FS_LABEL}"<br />
<br />
# Exit<br />
LABEL="media_by_label_only_auto_mount_end"<br />
</nowiki>}}<br />
<br />
==== Mount under {{Filename|/media}}; use partition label if present; ntfs-3g ====<br />
Yet another example, this time making use of ntfs-3g read/write drivers for NTFS filesystems:<br />
<br />
{{File|name=/etc/udev/rules.d/10-my-media-automount.rules|content=<nowiki><br />
# vim:enc=utf-8:nu:ai:si:et:ts=4:sw=4:ft=udevrules:<br />
#<br />
# /etc/udev/rules.d/10-my-media-automount.rules<br />
<br />
# start at sdb to ignore the system hard drive<br />
KERNEL!="sd[b-z]*", GOTO="my_media_automount_end"<br />
ACTION=="add", PROGRAM!="/sbin/blkid %N", GOTO="my_media_automount_end"<br />
<br />
# import some useful filesystem info as variables<br />
IMPORT{program}="/sbin/blkid -o udev -p %N"<br />
<br />
# get the label if present, otherwise assign one based on device/partition<br />
ENV{ID_FS_LABEL}!="", ENV{dir_name}="%E{ID_FS_LABEL}"<br />
ENV{ID_FS_LABEL}=="", ENV{dir_name}="usbhd-%k"<br />
<br />
# create the dir in /media and symlink it to /mnt<br />
ACTION=="add", RUN+="/bin/mkdir -p '/media/%E{dir_name}'"<br />
<br />
# global mount options<br />
ACTION=="add", ENV{mount_options}="relatime"<br />
# filesystem-specific mount options (777/666 dir/file perms for ntfs/vfat) <br />
ACTION=="add", ENV{ID_FS_TYPE}=="vfat|ntfs", ENV{mount_options}="$env{mount_options},gid=100,dmask=000,fmask=111,utf8"<br />
<br />
# automount ntfs filesystems using ntfs-3g driver<br />
ACTION=="add", ENV{ID_FS_TYPE}=="ntfs", RUN+="/bin/mount -t ntfs-3g -o %E{mount_options} /dev/%k '/media/%E{dir_name}'"<br />
# automount all other filesystems<br />
ACTION=="add", ENV{ID_FS_TYPE}!="ntfs", RUN+="/bin/mount -t auto -o %E{mount_options} /dev/%k '/media/%E{dir_name}'"<br />
<br />
# clean up after device removal<br />
ACTION=="remove", ENV{dir_name}!="", RUN+="/bin/umount -l '/media/%E{dir_name}'", RUN+="/bin/rmdir '/media/%E{dir_name}'"<br />
<br />
# exit<br />
LABEL="my_media_automount_end"<br />
<br />
</nowiki>}}<br />
<br />
==== Mount SD cards ====<br />
The same rules as above can be used to auto-mount SD cards, you just need to replace {{Codeline|sd[a-z][0-9]}} by {{Codeline|mmcblk[0-9]p[0-9]}}:<br />
{{File|name=/etc/udev/rules.d/11-sd-cards-auto-mount.rules|content=<nowiki><br />
KERNEL!="mmcblk[0-9]p[0-9]", GOTO="sd_cards_auto_mount_end"<br />
<br />
# Global mount options<br />
ACTION=="add", ENV{mount_options}="relatime"<br />
# Filesystem specific options<br />
ACTION=="add", IMPORT{program}="/sbin/blkid -o udev -p %N"<br />
ACTION=="add", ENV{ID_FS_TYPE}=="vfat|ntfs", ENV{mount_options}="$env{mount_options},utf8,gid=100,umask=002"<br />
<br />
ACTION=="add", RUN+="/bin/mkdir -p /media/sd-%k", RUN+="/bin/ln -s /media/sd-%k /mnt/sd-%k", RUN+="/bin/mount -o $env{mount_options} /dev/%k /media/sd-%k"<br />
ACTION=="remove", RUN+="/bin/umount -l /media/sd-%k", RUN+="/bin/rmdir /media/sd-%k"<br />
LABEL="sd_cards_auto_mount_end"<br />
</nowiki>}}<br />
<br />
==== Mount CDs ====<br />
To auto mount a CD a simple [[#UDisks Wrapper|UDisks wrapper]] will get the job done properly.<br />
{{Note|Maybe this should be merged to the Udisks wrapper section.}}<br />
<br />
==== Accessing Firmware Programmers and USB Virtual Comm Devices ====<br />
The following ruleset will allow normal users (within the "users" group) the ability to access the [http://www.ladyada.net/make/usbtinyisp/ USBtinyISP] USB programmer for AVR microcontrollers and a generic (SiLabs [http://www.silabs.com/products/interface/usbtouart CP2102]) USB to UART adapter. Adjust the permissions accordingly. Verified as of 2010-02-11.<br />
<br />
{{File|name=/etc/udev/rules.d/50-embedded_devices.rules|content=<nowiki><br />
# USBtinyISP Programmer rules<br />
SUBSYSTEMS=="usb", ATTRS{idVendor}=="1781", ATTRS{idProduct}=="0c9f", GROUP="users", MODE="0666"<br />
SUBSYSTEMS=="usb", ATTRS{idVendor}=="16c0", ATTRS{idProduct}=="0479", GROUP="users", MODE="0666"<br />
<br />
# Mdfly.com Generic (SiLabs CP2102) 3.3v/5v USB VComm adapter<br />
SUBSYSTEMS=="usb", ATTRS{idVendor}=="10c4", ATTRS{idProduct}=="ea60", GROUP="users", MODE="0666"<br />
</nowiki>}}<br />
<br />
=== Speed Up udev ===<br />
<br />
Performance gains can be realized by bypassing the blacklisting logic present in the {{Filename|/lib/udev/load-modules.sh}} script. See [[Speed_Up_udev]] for additional details.<br />
<br />
=== Execute on USB Insert ===<br />
<br />
See [[Execute_on_usb_insert|execute on usb insert]] article or the [http://igurublog.wordpress.com/downloads/script-devmon/ devmon wrapper script].<br />
<br />
=== Mount external drives as a normal user ===<br />
<br />
If you want to mount a external drive on KDE or Gnome (maybe on other Desktop Environments too) as a normal user (without the need to type your superuser password) you just have to edit the {{Filename|/usr/share/polkit-1/actions/org.freedesktop.udisks.policy}} (remember to backup first) and change the line '''<allow_active>auth_admin_keep</allow_active>''' on '''<action id="org.freedesktop.udisks.filesystem-mount-system-internal">''' to '''<allow_active>yes</allow_active>'''.<br />
<br />
==Troubleshooting==<br />
=== Disabling modules auto-loading with the load_modules boot parameter ===<br />
If you pass {{Codeline|<nowiki>load_modules=off</nowiki>}} on your kernel boot line, then udev will skip all the auto-loading business. This is to provide you with a big ripcord to pull if something goes wrong. If udev loads a problematic module that hangs your system or something equally awful, then you can bypass auto-loading with this parameter, then go in and blacklist the offensive module(s).<br />
<br />
=== Blacklisting Modules ===<br />
In rare cases, Udev can make mistakes and load the wrong modules. To prevent it from doing this, you can blacklist modules. Once blacklisted, udev will never load that module. See [[blacklisting]]. Not at boot-time ''or'' later on when a hotplug event is received (eg, you plug in your USB flash drive).<br />
<br />
=== udevd hangs at boot ===<br />
After migrating to LDAP or updating an LDAP-backed system udevd can hang at boot at the message "Starting UDev Daemon". This is usually caused by udevd trying to look up a name from LDAP but failing, because the network is not up yet. The solution is to ensure that all system group names are present locally.<br />
<br />
Extract the group names referenced in udev rules and the group names actually present on the system:<br />
<br />
# fgrep -r GROUP /etc/udev/rules.d/ /lib/udev/rules.d | perl -nle '/GROUP\s*=\s*"(.*?)"/ && print $1;' | sort | uniq > udev_groups<br />
# cut -f1 -d: /etc/gshadow /etc/group | sort | uniq > present_groups<br />
<br />
To see the differences, do a side-by-side diff:<br />
<br />
# diff -y present_groups udev_groups<br />
...<br />
network <<br />
nobody <<br />
ntp <<br />
optical optical<br />
power | pcscd<br />
rfkill <<br />
root root<br />
scanner scanner<br />
smmsp <<br />
storage storage<br />
...<br />
<br />
In this case, the pcscd group is for some reason not present in the system. Add the missing groups:<br />
<br />
# groupadd pcscd<br />
<br />
Also, make sure local resources are looked up before resorting to LDAP. {{Filename|/etc/nsswitch.conf}} should contain the line<br />
<br />
group: files ldap<br />
<br />
=== Known Problems with Hardware ===<br />
====BusLogic devices can be broken and will cause a freeze during startup====<br />
This is a kernel bug and no fix has been provided yet.<br />
====PCMCIA Card readers are not treated as removable devices====<br />
To get access to them with hal's pmount backend add them to {{Filename|/etc/pmount.allow}}<br />
<br />
=== Known Problems with Auto-Loading ===<br />
==== CPU frequency modules ====<br />
The current detection method for the various CPU frequency controllers is inadequate, so this has been omitted from the auto-loading process for the time being. To use CPU frequency scaling, load the proper module explicitly in your {{Codeline|MODULES}} array in {{Filename|[[rc.conf]]}}.<br />
<br />
====Sound Problems or Some Modules Not Loaded Automatically====<br />
Some users have traced this problem to old entries in {{Filename|/etc/modprobe.d/sound.conf}}. Try cleaning that file out and trying again.<br />
<br />
==== Mixed Up Devices, Sound/Network Cards Changing Order Each Boot ====<br />
Because udev loads all modules asynchronously, they are initialized in a different order. This can result in devices randomly switching names. For example, with two network cards, you may notice a switching of designations between {{Codeline|eth0}} and {{Codeline|eth1}}.<br />
<br />
Arch Linux provides the advantage of specifying the module load order by listing the modules in the {{Codeline|MODULES}} array in {{Filename|[[rc.conf]]}}. Modules in this array are loaded before udev begins auto-loading, so you have full control over the load order.<br />
<br />
# Always load 8139too before e100<br />
MODULES=(8139too e100)<br />
<br />
<br />
Another method for network card ordering is to use the udev-sanctioned method of statically-naming each interface. Create the following file to bind the MAC address of each of your cards to a certain interface name:<br />
{{File|name=/etc/udev/rules.d/10-network.rules|content=<nowiki><br />
SUBSYSTEM=="net", ATTR{address}=="aa:bb:cc:dd:ee:ff", NAME="lan0"<br />
SUBSYSTEM=="net", ATTR{address}=="ff:ee:dd:cc:bb:aa", NAME="wlan0"<br />
</nowiki>}}<br />
<br />
A couple things to note:<br />
* To get the MAC address of each card, use this command: {{Codeline|<nowiki>udevadm info -a -p /sys/class/net/<yourdevice> | grep address | tr [A-Z] [a-z]</nowiki>}}<br />
* Make sure to use the lower-case hex values in your udev rules. It doesn't like upper-case.<br />
* Some people have problems naming their interfaces after the old style: eth0, eth1, etc. Try something like "lan" or "wlan" if you experience this problem.<br />
<br />
Don't forget to update your {{Filename|/etc/rc.conf}} and other configuration files using the old ethX notation!<br />
<br />
<br />
Another method for setting network interface names is described in the Configuring Network wiki entry.<br />
http://wiki.archlinux.org/index.php/Configuring_Network<br/><br />
http://wiki.archlinux.org/index.php/Configuring_Network#Interface_names_varying<br />
<br />
=== Known Problems for Custom Kernel Users ===<br />
==== Udev doesn't start at all ====<br />
Make sure you have a kernel version later than or equal to 2.6.15. Earlier kernels do not have the necessary uevent stuff that udev needs for auto-loading.<br />
<br />
==== CD/DVD symlinks and permissions are broken ====<br />
If you're using a 2.6.15 kernel, you'll need the uevent patch from ABS (which backports certain uevent functionality from 2.6.16). Just sync up your ABS tree with the {{Codeline|abs}} command, then you'll find the patch in {{Codeline|/var/abs/kernels/kernel26/}}.<br />
<br />
==Other Resources==<br />
* [http://www.kernel.org/pub/linux/utils/kernel/hotplug/udev.html Udev Homepage]<br />
* [http://www.linux.com/news/hardware/peripherals/180950-udev An Introduction to Udev]<br />
* [http://vger.kernel.org/vger-lists.html#linux-hotplug Udev mailing list information]</div>Jnguyenhttps://wiki.archlinux.org/index.php?title=Udev&diff=139677Udev2011-05-04T14:00:21Z<p>Jnguyen: /* UDisks Shell Functions */ add AUR link for bashmount</p>
<hr />
<div>[[Category:Hardware detection and troubleshooting (English)]]<br />
[[Category:HOWTOs (English)]]<br />
[[Category:Auto-mounting (English)]]<br />
{{i18n|Udev}}<br />
<br />
== Introduction ==<br />
''"udev is the device manager for the Linux 2.6 kernel series. Primarily, it manages device nodes in {{Filename|/dev}}. It is the successor of devfs and hotplug, which means that it handles the {{Filename|/dev}} directory and all user space actions when adding/removing devices, including firmware load."'' Source: [http://en.wikipedia.org/wiki/Udev Wikipedia]<br />
<br />
udev replaces the functionality of both {{Codeline|hotplug}} and {{Codeline|hwdetect}}.<br />
<br />
udev loads kernel modules by utilizing coding parallelism to provide a potential performance advantage versus loading these modules serially. The modules are therefore loaded asynchronously. The inherent disadvantage of this method is that udev does not always load modules in the same order on each boot. If the machine has multiple block devices, this may manifest itself in the form of device nodes changing designations randomly. For example, if the machine has two hard drives, /dev/sda may randomly become /dev/sdb. See below for more info on this.<br />
<br />
==About modules auto-loading==<br />
udev will not do ''any'' module loading for you unless {{Codeline|MOD_AUTOLOAD}} is enabled in {{Filename|/etc/rc.conf}}. If you disable auto-loading you must manually load the modules you want/need by putting the list in the {{Codeline|MODULES}} array in {{Filename|[[rc.conf]]}}, you can generate this list with the {{Codeline|hwdetect --modules}} command.<br />
<br />
==About udev rules==<br />
udev rules go in {{Filename|/etc/udev/rules.d/}}, their file name has to end with {{Filename|.rules}}.<br />
<br />
If you want to learn how to write udev rules see [http://www.reactivated.net/writing_udev_rules.html Writing udev rules].<br />
<br />
To get a list of all the attributes of a device you can use to write rules:<br />
# udevadm info -a -p $(udevadm info -q path -n [device name])<br />
<br />
Replace [device name] with the device present in the system, such as '/dev/sda' or '/dev/ttyUSB0'.<br />
<br />
To restart the udev system once you create or modify udev rules, run the following command. Hotpluggable devices, such as USB devices, will probably have to be reconnected for the new rules to take effect.<br />
# udevadm control --reload-rules<br />
<br />
== Tips & Tricks ==<br />
=== UDisks ===<br />
Simply install UDisks:<br />
pacman -S udisks<br />
and all your media should be auto mounted in GNOME and KDE SC 4.6. There is no need for any additional rules this way.<br />
As an extra bonus you can remove HAL if you were only using that for auto mounting purposes.<br />
<br />
==== Automounting UDisks Wrappers ====<br />
A UDisks wrapper has the advantage of being very easy to install and needing no (or minimal) configuration. The wrapper will automatically mount things like CDs and flash drives.<br />
<br />
* [http://igurublog.wordpress.com/downloads/script-devmon/ devmon] - devmon ([http://aur.archlinux.org/packages.php?ID=45842 AUR]) is a configuration-less bash wrapper script for udisks which automounts optical discs and removable drives. It can also selectively autostart apps or execute commands after mounting, ignore specified devices and volume labels, and unmount removable drives. <br />
* [[udiskie]] - Written in Python. Allows auto mount and unmount by any user.<br />
* [http://aur.archlinux.org/packages.php?ID=38723 udisksevt] - Written in Haskell. Allows auto mount by any user. Designed to be integrated with [http://aur.archlinux.org/packages.php?ID=32005 traydevice].<br />
* The [http://aur.archlinux.org/packages.php?ID=46572 udisksvm bash script] uses udisks and [http://aur.archlinux.org/packages.php?ID=32005 Traydevice] to automount removable media and to control in GUI, with mouse clicks in systray, the un-mounting and re-mounting of disks or the ejection of optical disks.<br />
<br />
==== UDisks Shell Functions ====<br />
While UDisks includes a simple method of (un)mounting devices via command-line, it can be tiresome to type the commands out each time. These shell functions will generally shorten and ease command-line usage.<br />
<br />
* [https://bbs.archlinux.org/viewtopic.php?id=109307 udisks_functions] - Written for Bash.<br />
* [https://bbs.archlinux.org/viewtopic.php?id=117674 bashmount] - a menu-driven bash script with a configuration file that makes it easy to configure and extend [http://aur.archlinux.org/packages.php?ID=48524 [AUR]].<br />
<br />
=== Auto mounting USB devices ===<br />
{{Note|In the following rules the mount options are defined as {{Codeline|<nowiki>ENV{mount_options}="relatime"</nowiki>}}, see {{Codeline|man mount}} (and possibly {{Codeline|man ntfs-3g}}) for all available options and [[Maximizing Performance#Mount options]] for performance-related options.}}<br />
{{Note|The {{Codeline|users}} mount option will '''not''' allow users to unmount the filesystem.}}<br />
{{Tip|The {{Codeline|noexec}} mount option prevents execution of binaries on the mounted filesystem.}}<br />
<br />
==== Mount under {{Filename|/media}}; use partition label if present ====<br />
The following udev rule set automatically mounts devices/partitions that are represented by /dev/sd* (USB drives, external hard drives and sometimes SD cards). If a partition label is available, it mounts the device to /media/<label> and otherwise to /media/usbhd-sd* (ex: /media/usbhd-sdb1):<br />
{{File|name=/etc/udev/rules.d/11-media-by-label-auto-mount.rules|content=<nowiki><br />
KERNEL!="sd[a-z][0-9]", GOTO="media_by_label_auto_mount_end"<br />
<br />
# Import FS infos<br />
IMPORT{program}="/sbin/blkid -o udev -p %N"<br />
<br />
# Get a label if present, otherwise specify one<br />
ENV{ID_FS_LABEL}!="", ENV{dir_name}="%E{ID_FS_LABEL}"<br />
ENV{ID_FS_LABEL}=="", ENV{dir_name}="usbhd-%k"<br />
<br />
# Global mount options<br />
ACTION=="add", ENV{mount_options}="relatime"<br />
# Filesystem-specific mount options<br />
ACTION=="add", ENV{ID_FS_TYPE}=="vfat|ntfs", ENV{mount_options}="$env{mount_options},utf8,gid=100,umask=002"<br />
<br />
# Mount the device<br />
ACTION=="add", RUN+="/bin/mkdir -p /media/%E{dir_name}", RUN+="/bin/mount -o $env{mount_options} /dev/%k /media/%E{dir_name}"<br />
<br />
# Clean up after removal<br />
ACTION=="remove", ENV{dir_name}!="", RUN+="/bin/umount -l /media/%E{dir_name}", RUN+="/bin/rmdir /media/%E{dir_name}"<br />
<br />
# Exit<br />
LABEL="media_by_label_auto_mount_end"<br />
</nowiki>}}<br />
<br />
==== Mount under {{Filename|/media}}; use partition label if present; support LUKS encryption ====<br />
Similar to the above rule set, but if the device is a LUKS-encrypted partition it will open an xterm window to ask for the passphrase (provided that xterm is installed). Also see [http://bbs.archlinux.org/viewtopic.php?pid=696239#p696239 this post] and the follow-ups.<br />
<br />
{{Note|You may need to modify the path to cryptsetup, depending on the version installed (e.g., < 1.1.1_rc2-1).}}<br />
<br />
{{File|name=/etc/udev/rules.d/11-media-by-label-auto-mount.rules|content=<nowiki><br />
KERNEL!="sd[a-z]*", GOTO="media_by_label_auto_mount_end"<br />
ACTION=="add", PROGRAM!="/sbin/blkid %N", GOTO="media_by_label_auto_mount_end"<br />
<br />
# Do not mount devices on boot because otherwise fsck may fail<br />
ACTION=="add", PROGRAM!="/bin/grep ' / / rw[, ]' /proc/self/mountinfo", GOTO="media_by_label_auto_mount_end"<br />
<br />
# Open LUKS partition if necessary<br />
PROGRAM=="/sbin/blkid -o value -s TYPE %N", RESULT=="crypto_LUKS", ENV{crypto}="mapper/", ENV{device}="/dev/mapper/%k"<br />
ENV{crypto}=="", ENV{device}="%N"<br />
ACTION=="add", ENV{crypto}!="", PROGRAM=="/usr/bin/xterm -display :0.0 -e 'echo Password for /dev/%k; /sbin/cryptsetup luksOpen %N %k'"<br />
ACTION=="add", ENV{crypto}!="", TEST!="/dev/mapper/%k", GOTO="media_by_label_auto_mount_end"<br />
<br />
# Global mount options<br />
ACTION=="add", ENV{mount_options}="noatime"<br />
# Filesystem-specific mount options<br />
ACTION=="add", PROGRAM=="/sbin/blkid -o value -s TYPE %E{device}", RESULT=="vfat|ntfs", ENV{mount_options}="%E{mount_options},utf8,gid=100,umask=002"<br />
<br />
# Get label if present, otherwise assign one<br />
PROGRAM=="/sbin/blkid -o value -s LABEL %E{device}", ENV{dir_name}="%c"<br />
# Use basename to correctly handle labels such as ../mnt/foo<br />
PROGRAM=="/usr/bin/basename '%E{dir_name}'", ENV{dir_name}="%c"<br />
ENV{dir_name}=="", ENV{dir_name}="usbhd-%k"<br />
<br />
# Mount the device<br />
ACTION=="add", ENV{dir_name}!="", RUN+="/bin/mkdir -p '/media/%E{dir_name}'", RUN+="/bin/mount -o %E{mount_options} /dev/%E{crypto}%k '/media/%E{dir_name}'"<br />
<br />
# Clean up after removal<br />
ACTION=="remove", ENV{dir_name}!="", RUN+="/bin/umount -l '/media/%E{dir_name}'"<br />
ACTION=="remove", ENV{crypto}!="", RUN+="/sbin/cryptsetup luksClose %k"<br />
ACTION=="remove", ENV{dir_name}!="", RUN+="/bin/rmdir '/media/%E{dir_name}'"<br />
<br />
# Exit<br />
LABEL="media_by_label_auto_mount_end"<br />
</nowiki>}}<br />
<br />
==== Mount under {{Filename|/media}}; use partition label if present; support user un-mounting ====<br />
This is a variation on the above rule set. It uses pmount (which will need to be installed) instead of mount, allowing a non-root user to unmount udev-mounted devices. The required username must be hard-coded in the RUN command, so this rule set may not be suitable for multi-user systems. LUKS support has also been removed from the example, but can be easily reinstated as above. You must edit the /bin/su invocation to run as the correct user for your system.<br />
{{File|name=/etc/udev/rules.d/11-media-by-label-with-pmount.rules|content=<nowiki><br />
KERNEL!="sd[a-z]*", GOTO="media_by_label_auto_mount_end"<br />
ACTION=="add", PROGRAM!="/sbin/blkid %N", GOTO="media_by_label_auto_mount_end"<br />
<br />
# Get label<br />
PROGRAM=="/sbin/blkid -o value -s LABEL %N", ENV{dir_name}="%c"<br />
# use basename to correctly handle labels such as ../mnt/foo<br />
PROGRAM=="/usr/bin/basename '%E{dir_name}'", ENV{dir_name}="%c"<br />
ENV{dir_name}=="", ENV{dir_name}="usbhd-%k"<br />
<br />
ACTION=="add", ENV{dir_name}!="", RUN+="/bin/su tomk -c '/usr/bin/pmount %N %E{dir_name}'"<br />
ACTION=="remove", ENV{dir_name}!="", RUN+="/bin/su tomk -c '/usr/bin/pumount /media/%E{dir_name}'"<br />
LABEL="media_by_label_auto_mount_end"<br />
</nowiki>}}<br />
<br />
==== Mount under {{Filename|/mnt}}; create symbolic link under {{Filename|/media}} ====<br />
The following rule set does not make use of partition labels; instead it mounts devices as usbhd-sdXY under the /mnt directory (ex: /mnt/usbhd-sdb1) and creates a symbolic link under /media.<br />
{{File|name=/etc/udev/rules.d/11-mnt-auto-mount.rules|content=<nowiki><br />
KERNEL!="sd[a-z][0-9]", GOTO="mnt_auto_mount_end"<br />
<br />
# Global mount options<br />
ACTION=="add", ENV{mount_options}="relatime"<br />
# Filesystem-specific mount options<br />
ACTION=="add", IMPORT{program}="/sbin/blkid -o udev -p %N"<br />
ACTION=="add", ENV{ID_FS_TYPE}=="vfat|ntfs", ENV{mount_options}="$env{mount_options},utf8,gid=100,umask=002"<br />
<br />
# Mount under /mnt and create the symbolic link in /media <br />
ACTION=="add", RUN+="/bin/mount -o $env{mount_options} /dev/%k /mnt/usbhd-%k", RUN+="/bin/ln -s /mnt/usbhd-%k /media/usbhd-%k"<br />
<br />
# Clean up after removal<br />
ACTION=="remove", RUN+="/bin/rm -f /media/usbhd-%k", RUN+="/bin/umount -l /mnt/usbhd-%k", RUN+="/bin/rmdir /mnt/usbhd-%k"<br />
<br />
# Exit<br />
LABEL="mnt_auto_mount_end"<br />
</nowiki>}}<br />
<br />
==== Mount under {{Filename|/media}} ''only'' if the partition has a label ====<br />
{{File|name=/etc/udev/rules.d/11-media-by-label-only-auto-mount.rules|content=<nowiki><br />
KERNEL!="sd[a-z][0-9]", GOTO="media_by_label_only_auto_mount_end"<br />
<br />
# Import FS infos<br />
IMPORT{program}="/sbin/blkid -o udev -p %N"<br />
ENV{ID_FS_LABEL}=="", GOTO="media_by_label_only_auto_mount_end"<br />
<br />
# Global mount options<br />
ACTION=="add", ENV{mount_options}="relatime"<br />
# Filesystem-specific mount options<br />
ACTION=="add", ENV{ID_FS_TYPE}=="vfat|ntfs", ENV{mount_options}="$env{mount_options},utf8,gid=100,umask=002"<br />
<br />
# Mount the device<br />
ACTION=="add", RUN+="/bin/mkdir -p /media/$env{ID_FS_LABEL}", RUN+="/bin/mount -o $env{mount_options} /dev/%k /media/$env{ID_FS_LABEL}"<br />
<br />
# Clean up after removal<br />
ACTION=="remove", ENV{ID_FS_LABEL}!="", RUN+="/bin/umount -l /media/$env{ID_FS_LABEL}", RUN+="/bin/rmdir /media/$env{ID_FS_LABEL}"<br />
<br />
# Exit<br />
LABEL="media_by_label_only_auto_mount_end"<br />
</nowiki>}}<br />
<br />
==== Mount under {{Filename|/media}}; use partition label if present; ntfs-3g ====<br />
Yet another example, this time making use of ntfs-3g read/write drivers for NTFS filesystems:<br />
<br />
{{File|name=/etc/udev/rules.d/10-my-media-automount.rules|content=<nowiki><br />
# vim:enc=utf-8:nu:ai:si:et:ts=4:sw=4:ft=udevrules:<br />
#<br />
# /etc/udev/rules.d/10-my-media-automount.rules<br />
<br />
# start at sdb to ignore the system hard drive<br />
KERNEL!="sd[b-z]*", GOTO="my_media_automount_end"<br />
ACTION=="add", PROGRAM!="/sbin/blkid %N", GOTO="my_media_automount_end"<br />
<br />
# import some useful filesystem info as variables<br />
IMPORT{program}="/sbin/blkid -o udev -p %N"<br />
<br />
# get the label if present, otherwise assign one based on device/partition<br />
ENV{ID_FS_LABEL}!="", ENV{dir_name}="%E{ID_FS_LABEL}"<br />
ENV{ID_FS_LABEL}=="", ENV{dir_name}="usbhd-%k"<br />
<br />
# create the dir in /media and symlink it to /mnt<br />
ACTION=="add", RUN+="/bin/mkdir -p '/media/%E{dir_name}'"<br />
<br />
# global mount options<br />
ACTION=="add", ENV{mount_options}="relatime"<br />
# filesystem-specific mount options (777/666 dir/file perms for ntfs/vfat) <br />
ACTION=="add", ENV{ID_FS_TYPE}=="vfat|ntfs", ENV{mount_options}="$env{mount_options},gid=100,dmask=000,fmask=111,utf8"<br />
<br />
# automount ntfs filesystems using ntfs-3g driver<br />
ACTION=="add", ENV{ID_FS_TYPE}=="ntfs", RUN+="/bin/mount -t ntfs-3g -o %E{mount_options} /dev/%k '/media/%E{dir_name}'"<br />
# automount all other filesystems<br />
ACTION=="add", ENV{ID_FS_TYPE}!="ntfs", RUN+="/bin/mount -t auto -o %E{mount_options} /dev/%k '/media/%E{dir_name}'"<br />
<br />
# clean up after device removal<br />
ACTION=="remove", ENV{dir_name}!="", RUN+="/bin/umount -l '/media/%E{dir_name}'", RUN+="/bin/rmdir '/media/%E{dir_name}'"<br />
<br />
# exit<br />
LABEL="my_media_automount_end"<br />
<br />
</nowiki>}}<br />
<br />
==== Mount SD cards ====<br />
The same rules as above can be used to auto-mount SD cards, you just need to replace {{Codeline|sd[a-z][0-9]}} by {{Codeline|mmcblk[0-9]p[0-9]}}:<br />
{{File|name=/etc/udev/rules.d/11-sd-cards-auto-mount.rules|content=<nowiki><br />
KERNEL!="mmcblk[0-9]p[0-9]", GOTO="sd_cards_auto_mount_end"<br />
<br />
# Global mount options<br />
ACTION=="add", ENV{mount_options}="relatime"<br />
# Filesystem specific options<br />
ACTION=="add", IMPORT{program}="/sbin/blkid -o udev -p %N"<br />
ACTION=="add", ENV{ID_FS_TYPE}=="vfat|ntfs", ENV{mount_options}="$env{mount_options},utf8,gid=100,umask=002"<br />
<br />
ACTION=="add", RUN+="/bin/mkdir -p /media/sd-%k", RUN+="/bin/ln -s /media/sd-%k /mnt/sd-%k", RUN+="/bin/mount -o $env{mount_options} /dev/%k /media/sd-%k"<br />
ACTION=="remove", RUN+="/bin/umount -l /media/sd-%k", RUN+="/bin/rmdir /media/sd-%k"<br />
LABEL="sd_cards_auto_mount_end"<br />
</nowiki>}}<br />
<br />
==== Mount CDs ====<br />
To auto mount a CD a simple [[#UDisks Wrapper|UDisks wrapper]] will get the job done properly.<br />
{{Note|Maybe this should be merged to the Udisks wrapper section.}}<br />
<br />
==== Accessing Firmware Programmers and USB Virtual Comm Devices ====<br />
The following ruleset will allow normal users (within the "users" group) the ability to access the [http://www.ladyada.net/make/usbtinyisp/ USBtinyISP] USB programmer for AVR microcontrollers and a generic (SiLabs [http://www.silabs.com/products/interface/usbtouart CP2102]) USB to UART adapter. Adjust the permissions accordingly. Verified as of 2010-02-11.<br />
<br />
{{File|name=/etc/udev/rules.d/50-embedded_devices.rules|content=<nowiki><br />
# USBtinyISP Programmer rules<br />
SUBSYSTEMS=="usb", ATTRS{idVendor}=="1781", ATTRS{idProduct}=="0c9f", GROUP="users", MODE="0666"<br />
SUBSYSTEMS=="usb", ATTRS{idVendor}=="16c0", ATTRS{idProduct}=="0479", GROUP="users", MODE="0666"<br />
<br />
# Mdfly.com Generic (SiLabs CP2102) 3.3v/5v USB VComm adapter<br />
SUBSYSTEMS=="usb", ATTRS{idVendor}=="10c4", ATTRS{idProduct}=="ea60", GROUP="users", MODE="0666"<br />
</nowiki>}}<br />
<br />
=== Speed Up udev ===<br />
<br />
Performance gains can be realized by bypassing the blacklisting logic present in the {{Filename|/lib/udev/load-modules.sh}} script. See [[Speed_Up_udev]] for additional details.<br />
<br />
=== Execute on USB Insert ===<br />
<br />
See [[Execute_on_usb_insert|execute on usb insert]] article or the [http://igurublog.wordpress.com/downloads/script-devmon/ devmon wrapper script].<br />
<br />
=== Mount external drives as a normal user ===<br />
<br />
If you want to mount a external drive on KDE or Gnome (maybe on other Desktop Environments too) as a normal user (without the need to type your superuser password) you just have to edit the {{Filename|/usr/share/polkit-1/actions/org.freedesktop.udisks.policy}} (remember to backup first) and change the line '''<allow_active>auth_admin_keep</allow_active>''' on '''<action id="org.freedesktop.udisks.filesystem-mount-system-internal">''' to '''<allow_active>yes</allow_active>'''.<br />
<br />
==Troubleshooting==<br />
=== Disabling modules auto-loading with the load_modules boot parameter ===<br />
If you pass {{Codeline|<nowiki>load_modules=off</nowiki>}} on your kernel boot line, then udev will skip all the auto-loading business. This is to provide you with a big ripcord to pull if something goes wrong. If udev loads a problematic module that hangs your system or something equally awful, then you can bypass auto-loading with this parameter, then go in and blacklist the offensive module(s).<br />
<br />
=== Blacklisting Modules ===<br />
In rare cases, Udev can make mistakes and load the wrong modules. To prevent it from doing this, you can blacklist modules. Once blacklisted, udev will never load that module. See [[blacklisting]]. Not at boot-time ''or'' later on when a hotplug event is received (eg, you plug in your USB flash drive).<br />
<br />
=== udevd hangs at boot ===<br />
After migrating to LDAP or updating an LDAP-backed system udevd can hang at boot at the message "Starting UDev Daemon". This is usually caused by udevd trying to look up a name from LDAP but failing, because the network is not up yet. The solution is to ensure that all system group names are present locally.<br />
<br />
Extract the group names referenced in udev rules and the group names actually present on the system:<br />
<br />
# fgrep -r GROUP /etc/udev/rules.d/ /lib/udev/rules.d | perl -nle '/GROUP\s*=\s*"(.*?)"/ && print $1;' | sort | uniq > udev_groups<br />
# cut -f1 -d: /etc/gshadow /etc/group | sort | uniq > present_groups<br />
<br />
To see the differences, do a side-by-side diff:<br />
<br />
# diff -y present_groups udev_groups<br />
...<br />
network <<br />
nobody <<br />
ntp <<br />
optical optical<br />
power | pcscd<br />
rfkill <<br />
root root<br />
scanner scanner<br />
smmsp <<br />
storage storage<br />
...<br />
<br />
In this case, the pcscd group is for some reason not present in the system. Add the missing groups:<br />
<br />
# groupadd pcscd<br />
<br />
Also, make sure local resources are looked up before resorting to LDAP. {{Filename|/etc/nsswitch.conf}} should contain the line<br />
<br />
group: files ldap<br />
<br />
=== Known Problems with Hardware ===<br />
====BusLogic devices can be broken and will cause a freeze during startup====<br />
This is a kernel bug and no fix has been provided yet.<br />
====PCMCIA Card readers are not treated as removable devices====<br />
To get access to them with hal's pmount backend add them to {{Filename|/etc/pmount.allow}}<br />
<br />
=== Known Problems with Auto-Loading ===<br />
==== CPU frequency modules ====<br />
The current detection method for the various CPU frequency controllers is inadequate, so this has been omitted from the auto-loading process for the time being. To use CPU frequency scaling, load the proper module explicitly in your {{Codeline|MODULES}} array in {{Filename|[[rc.conf]]}}.<br />
<br />
====Sound Problems or Some Modules Not Loaded Automatically====<br />
Some users have traced this problem to old entries in {{Filename|/etc/modprobe.d/sound.conf}}. Try cleaning that file out and trying again.<br />
<br />
==== Mixed Up Devices, Sound/Network Cards Changing Order Each Boot ====<br />
Because udev loads all modules asynchronously, they are initialized in a different order. This can result in devices randomly switching names. For example, with two network cards, you may notice a switching of designations between {{Codeline|eth0}} and {{Codeline|eth1}}.<br />
<br />
Arch Linux provides the advantage of specifying the module load order by listing the modules in the {{Codeline|MODULES}} array in {{Filename|[[rc.conf]]}}. Modules in this array are loaded before udev begins auto-loading, so you have full control over the load order.<br />
<br />
# Always load 8139too before e100<br />
MODULES=(8139too e100)<br />
<br />
<br />
Another method for network card ordering is to use the udev-sanctioned method of statically-naming each interface. Create the following file to bind the MAC address of each of your cards to a certain interface name:<br />
{{File|name=/etc/udev/rules.d/10-network.rules|content=<nowiki><br />
SUBSYSTEM=="net", ATTR{address}=="aa:bb:cc:dd:ee:ff", NAME="lan0"<br />
SUBSYSTEM=="net", ATTR{address}=="ff:ee:dd:cc:bb:aa", NAME="wlan0"<br />
</nowiki>}}<br />
<br />
A couple things to note:<br />
* To get the MAC address of each card, use this command: {{Codeline|<nowiki>udevadm info -a -p /sys/class/net/<yourdevice> | grep address | tr [A-Z] [a-z]</nowiki>}}<br />
* Make sure to use the lower-case hex values in your udev rules. It doesn't like upper-case.<br />
* Some people have problems naming their interfaces after the old style: eth0, eth1, etc. Try something like "lan" or "wlan" if you experience this problem.<br />
<br />
Don't forget to update your {{Filename|/etc/rc.conf}} and other configuration files using the old ethX notation!<br />
<br />
<br />
Another method for setting network interface names is described in the Configuring Network wiki entry.<br />
http://wiki.archlinux.org/index.php/Configuring_Network<br/><br />
http://wiki.archlinux.org/index.php/Configuring_Network#Interface_names_varying<br />
<br />
=== Known Problems for Custom Kernel Users ===<br />
==== Udev doesn't start at all ====<br />
Make sure you have a kernel version later than or equal to 2.6.15. Earlier kernels do not have the necessary uevent stuff that udev needs for auto-loading.<br />
<br />
==== CD/DVD symlinks and permissions are broken ====<br />
If you're using a 2.6.15 kernel, you'll need the uevent patch from ABS (which backports certain uevent functionality from 2.6.16). Just sync up your ABS tree with the {{Codeline|abs}} command, then you'll find the patch in {{Codeline|/var/abs/kernels/kernel26/}}.<br />
<br />
==Other Resources==<br />
* [http://www.kernel.org/pub/linux/utils/kernel/hotplug/udev.html Udev Homepage]<br />
* [http://www.linux.com/news/hardware/peripherals/180950-udev An Introduction to Udev]<br />
* [http://vger.kernel.org/vger-lists.html#linux-hotplug Udev mailing list information]</div>Jnguyenhttps://wiki.archlinux.org/index.php?title=Udev&diff=139676Udev2011-05-04T13:58:48Z<p>Jnguyen: /* UDisks Shell Functions */ add link to bashmount</p>
<hr />
<div>[[Category:Hardware detection and troubleshooting (English)]]<br />
[[Category:HOWTOs (English)]]<br />
[[Category:Auto-mounting (English)]]<br />
{{i18n|Udev}}<br />
<br />
== Introduction ==<br />
''"udev is the device manager for the Linux 2.6 kernel series. Primarily, it manages device nodes in {{Filename|/dev}}. It is the successor of devfs and hotplug, which means that it handles the {{Filename|/dev}} directory and all user space actions when adding/removing devices, including firmware load."'' Source: [http://en.wikipedia.org/wiki/Udev Wikipedia]<br />
<br />
udev replaces the functionality of both {{Codeline|hotplug}} and {{Codeline|hwdetect}}.<br />
<br />
udev loads kernel modules by utilizing coding parallelism to provide a potential performance advantage versus loading these modules serially. The modules are therefore loaded asynchronously. The inherent disadvantage of this method is that udev does not always load modules in the same order on each boot. If the machine has multiple block devices, this may manifest itself in the form of device nodes changing designations randomly. For example, if the machine has two hard drives, /dev/sda may randomly become /dev/sdb. See below for more info on this.<br />
<br />
==About modules auto-loading==<br />
udev will not do ''any'' module loading for you unless {{Codeline|MOD_AUTOLOAD}} is enabled in {{Filename|/etc/rc.conf}}. If you disable auto-loading you must manually load the modules you want/need by putting the list in the {{Codeline|MODULES}} array in {{Filename|[[rc.conf]]}}, you can generate this list with the {{Codeline|hwdetect --modules}} command.<br />
<br />
==About udev rules==<br />
udev rules go in {{Filename|/etc/udev/rules.d/}}, their file name has to end with {{Filename|.rules}}.<br />
<br />
If you want to learn how to write udev rules see [http://www.reactivated.net/writing_udev_rules.html Writing udev rules].<br />
<br />
To get a list of all the attributes of a device you can use to write rules:<br />
# udevadm info -a -p $(udevadm info -q path -n [device name])<br />
<br />
Replace [device name] with the device present in the system, such as '/dev/sda' or '/dev/ttyUSB0'.<br />
<br />
To restart the udev system once you create or modify udev rules, run the following command. Hotpluggable devices, such as USB devices, will probably have to be reconnected for the new rules to take effect.<br />
# udevadm control --reload-rules<br />
<br />
== Tips & Tricks ==<br />
=== UDisks ===<br />
Simply install UDisks:<br />
pacman -S udisks<br />
and all your media should be auto mounted in GNOME and KDE SC 4.6. There is no need for any additional rules this way.<br />
As an extra bonus you can remove HAL if you were only using that for auto mounting purposes.<br />
<br />
==== Automounting UDisks Wrappers ====<br />
A UDisks wrapper has the advantage of being very easy to install and needing no (or minimal) configuration. The wrapper will automatically mount things like CDs and flash drives.<br />
<br />
* [http://igurublog.wordpress.com/downloads/script-devmon/ devmon] - devmon ([http://aur.archlinux.org/packages.php?ID=45842 AUR]) is a configuration-less bash wrapper script for udisks which automounts optical discs and removable drives. It can also selectively autostart apps or execute commands after mounting, ignore specified devices and volume labels, and unmount removable drives. <br />
* [[udiskie]] - Written in Python. Allows auto mount and unmount by any user.<br />
* [http://aur.archlinux.org/packages.php?ID=38723 udisksevt] - Written in Haskell. Allows auto mount by any user. Designed to be integrated with [http://aur.archlinux.org/packages.php?ID=32005 traydevice].<br />
* The [http://aur.archlinux.org/packages.php?ID=46572 udisksvm bash script] uses udisks and [http://aur.archlinux.org/packages.php?ID=32005 Traydevice] to automount removable media and to control in GUI, with mouse clicks in systray, the un-mounting and re-mounting of disks or the ejection of optical disks.<br />
<br />
==== UDisks Shell Functions ====<br />
While UDisks includes a simple method of (un)mounting devices via command-line, it can be tiresome to type the commands out each time. These shell functions will generally shorten and ease command-line usage.<br />
<br />
* [https://bbs.archlinux.org/viewtopic.php?id=109307 udisks_functions] - Written for Bash.<br />
* [https://bbs.archlinux.org/viewtopic.php?id=117674 bashmount] - a menu-driven bash script with a configuration file that makes it easy to configure and extend.<br />
<br />
=== Auto mounting USB devices ===<br />
{{Note|In the following rules the mount options are defined as {{Codeline|<nowiki>ENV{mount_options}="relatime"</nowiki>}}, see {{Codeline|man mount}} (and possibly {{Codeline|man ntfs-3g}}) for all available options and [[Maximizing Performance#Mount options]] for performance-related options.}}<br />
{{Note|The {{Codeline|users}} mount option will '''not''' allow users to unmount the filesystem.}}<br />
{{Tip|The {{Codeline|noexec}} mount option prevents execution of binaries on the mounted filesystem.}}<br />
<br />
==== Mount under {{Filename|/media}}; use partition label if present ====<br />
The following udev rule set automatically mounts devices/partitions that are represented by /dev/sd* (USB drives, external hard drives and sometimes SD cards). If a partition label is available, it mounts the device to /media/<label> and otherwise to /media/usbhd-sd* (ex: /media/usbhd-sdb1):<br />
{{File|name=/etc/udev/rules.d/11-media-by-label-auto-mount.rules|content=<nowiki><br />
KERNEL!="sd[a-z][0-9]", GOTO="media_by_label_auto_mount_end"<br />
<br />
# Import FS infos<br />
IMPORT{program}="/sbin/blkid -o udev -p %N"<br />
<br />
# Get a label if present, otherwise specify one<br />
ENV{ID_FS_LABEL}!="", ENV{dir_name}="%E{ID_FS_LABEL}"<br />
ENV{ID_FS_LABEL}=="", ENV{dir_name}="usbhd-%k"<br />
<br />
# Global mount options<br />
ACTION=="add", ENV{mount_options}="relatime"<br />
# Filesystem-specific mount options<br />
ACTION=="add", ENV{ID_FS_TYPE}=="vfat|ntfs", ENV{mount_options}="$env{mount_options},utf8,gid=100,umask=002"<br />
<br />
# Mount the device<br />
ACTION=="add", RUN+="/bin/mkdir -p /media/%E{dir_name}", RUN+="/bin/mount -o $env{mount_options} /dev/%k /media/%E{dir_name}"<br />
<br />
# Clean up after removal<br />
ACTION=="remove", ENV{dir_name}!="", RUN+="/bin/umount -l /media/%E{dir_name}", RUN+="/bin/rmdir /media/%E{dir_name}"<br />
<br />
# Exit<br />
LABEL="media_by_label_auto_mount_end"<br />
</nowiki>}}<br />
<br />
==== Mount under {{Filename|/media}}; use partition label if present; support LUKS encryption ====<br />
Similar to the above rule set, but if the device is a LUKS-encrypted partition it will open an xterm window to ask for the passphrase (provided that xterm is installed). Also see [http://bbs.archlinux.org/viewtopic.php?pid=696239#p696239 this post] and the follow-ups.<br />
<br />
{{Note|You may need to modify the path to cryptsetup, depending on the version installed (e.g., < 1.1.1_rc2-1).}}<br />
<br />
{{File|name=/etc/udev/rules.d/11-media-by-label-auto-mount.rules|content=<nowiki><br />
KERNEL!="sd[a-z]*", GOTO="media_by_label_auto_mount_end"<br />
ACTION=="add", PROGRAM!="/sbin/blkid %N", GOTO="media_by_label_auto_mount_end"<br />
<br />
# Do not mount devices on boot because otherwise fsck may fail<br />
ACTION=="add", PROGRAM!="/bin/grep ' / / rw[, ]' /proc/self/mountinfo", GOTO="media_by_label_auto_mount_end"<br />
<br />
# Open LUKS partition if necessary<br />
PROGRAM=="/sbin/blkid -o value -s TYPE %N", RESULT=="crypto_LUKS", ENV{crypto}="mapper/", ENV{device}="/dev/mapper/%k"<br />
ENV{crypto}=="", ENV{device}="%N"<br />
ACTION=="add", ENV{crypto}!="", PROGRAM=="/usr/bin/xterm -display :0.0 -e 'echo Password for /dev/%k; /sbin/cryptsetup luksOpen %N %k'"<br />
ACTION=="add", ENV{crypto}!="", TEST!="/dev/mapper/%k", GOTO="media_by_label_auto_mount_end"<br />
<br />
# Global mount options<br />
ACTION=="add", ENV{mount_options}="noatime"<br />
# Filesystem-specific mount options<br />
ACTION=="add", PROGRAM=="/sbin/blkid -o value -s TYPE %E{device}", RESULT=="vfat|ntfs", ENV{mount_options}="%E{mount_options},utf8,gid=100,umask=002"<br />
<br />
# Get label if present, otherwise assign one<br />
PROGRAM=="/sbin/blkid -o value -s LABEL %E{device}", ENV{dir_name}="%c"<br />
# Use basename to correctly handle labels such as ../mnt/foo<br />
PROGRAM=="/usr/bin/basename '%E{dir_name}'", ENV{dir_name}="%c"<br />
ENV{dir_name}=="", ENV{dir_name}="usbhd-%k"<br />
<br />
# Mount the device<br />
ACTION=="add", ENV{dir_name}!="", RUN+="/bin/mkdir -p '/media/%E{dir_name}'", RUN+="/bin/mount -o %E{mount_options} /dev/%E{crypto}%k '/media/%E{dir_name}'"<br />
<br />
# Clean up after removal<br />
ACTION=="remove", ENV{dir_name}!="", RUN+="/bin/umount -l '/media/%E{dir_name}'"<br />
ACTION=="remove", ENV{crypto}!="", RUN+="/sbin/cryptsetup luksClose %k"<br />
ACTION=="remove", ENV{dir_name}!="", RUN+="/bin/rmdir '/media/%E{dir_name}'"<br />
<br />
# Exit<br />
LABEL="media_by_label_auto_mount_end"<br />
</nowiki>}}<br />
<br />
==== Mount under {{Filename|/media}}; use partition label if present; support user un-mounting ====<br />
This is a variation on the above rule set. It uses pmount (which will need to be installed) instead of mount, allowing a non-root user to unmount udev-mounted devices. The required username must be hard-coded in the RUN command, so this rule set may not be suitable for multi-user systems. LUKS support has also been removed from the example, but can be easily reinstated as above. You must edit the /bin/su invocation to run as the correct user for your system.<br />
{{File|name=/etc/udev/rules.d/11-media-by-label-with-pmount.rules|content=<nowiki><br />
KERNEL!="sd[a-z]*", GOTO="media_by_label_auto_mount_end"<br />
ACTION=="add", PROGRAM!="/sbin/blkid %N", GOTO="media_by_label_auto_mount_end"<br />
<br />
# Get label<br />
PROGRAM=="/sbin/blkid -o value -s LABEL %N", ENV{dir_name}="%c"<br />
# use basename to correctly handle labels such as ../mnt/foo<br />
PROGRAM=="/usr/bin/basename '%E{dir_name}'", ENV{dir_name}="%c"<br />
ENV{dir_name}=="", ENV{dir_name}="usbhd-%k"<br />
<br />
ACTION=="add", ENV{dir_name}!="", RUN+="/bin/su tomk -c '/usr/bin/pmount %N %E{dir_name}'"<br />
ACTION=="remove", ENV{dir_name}!="", RUN+="/bin/su tomk -c '/usr/bin/pumount /media/%E{dir_name}'"<br />
LABEL="media_by_label_auto_mount_end"<br />
</nowiki>}}<br />
<br />
==== Mount under {{Filename|/mnt}}; create symbolic link under {{Filename|/media}} ====<br />
The following rule set does not make use of partition labels; instead it mounts devices as usbhd-sdXY under the /mnt directory (ex: /mnt/usbhd-sdb1) and creates a symbolic link under /media.<br />
{{File|name=/etc/udev/rules.d/11-mnt-auto-mount.rules|content=<nowiki><br />
KERNEL!="sd[a-z][0-9]", GOTO="mnt_auto_mount_end"<br />
<br />
# Global mount options<br />
ACTION=="add", ENV{mount_options}="relatime"<br />
# Filesystem-specific mount options<br />
ACTION=="add", IMPORT{program}="/sbin/blkid -o udev -p %N"<br />
ACTION=="add", ENV{ID_FS_TYPE}=="vfat|ntfs", ENV{mount_options}="$env{mount_options},utf8,gid=100,umask=002"<br />
<br />
# Mount under /mnt and create the symbolic link in /media <br />
ACTION=="add", RUN+="/bin/mount -o $env{mount_options} /dev/%k /mnt/usbhd-%k", RUN+="/bin/ln -s /mnt/usbhd-%k /media/usbhd-%k"<br />
<br />
# Clean up after removal<br />
ACTION=="remove", RUN+="/bin/rm -f /media/usbhd-%k", RUN+="/bin/umount -l /mnt/usbhd-%k", RUN+="/bin/rmdir /mnt/usbhd-%k"<br />
<br />
# Exit<br />
LABEL="mnt_auto_mount_end"<br />
</nowiki>}}<br />
<br />
==== Mount under {{Filename|/media}} ''only'' if the partition has a label ====<br />
{{File|name=/etc/udev/rules.d/11-media-by-label-only-auto-mount.rules|content=<nowiki><br />
KERNEL!="sd[a-z][0-9]", GOTO="media_by_label_only_auto_mount_end"<br />
<br />
# Import FS infos<br />
IMPORT{program}="/sbin/blkid -o udev -p %N"<br />
ENV{ID_FS_LABEL}=="", GOTO="media_by_label_only_auto_mount_end"<br />
<br />
# Global mount options<br />
ACTION=="add", ENV{mount_options}="relatime"<br />
# Filesystem-specific mount options<br />
ACTION=="add", ENV{ID_FS_TYPE}=="vfat|ntfs", ENV{mount_options}="$env{mount_options},utf8,gid=100,umask=002"<br />
<br />
# Mount the device<br />
ACTION=="add", RUN+="/bin/mkdir -p /media/$env{ID_FS_LABEL}", RUN+="/bin/mount -o $env{mount_options} /dev/%k /media/$env{ID_FS_LABEL}"<br />
<br />
# Clean up after removal<br />
ACTION=="remove", ENV{ID_FS_LABEL}!="", RUN+="/bin/umount -l /media/$env{ID_FS_LABEL}", RUN+="/bin/rmdir /media/$env{ID_FS_LABEL}"<br />
<br />
# Exit<br />
LABEL="media_by_label_only_auto_mount_end"<br />
</nowiki>}}<br />
<br />
==== Mount under {{Filename|/media}}; use partition label if present; ntfs-3g ====<br />
Yet another example, this time making use of ntfs-3g read/write drivers for NTFS filesystems:<br />
<br />
{{File|name=/etc/udev/rules.d/10-my-media-automount.rules|content=<nowiki><br />
# vim:enc=utf-8:nu:ai:si:et:ts=4:sw=4:ft=udevrules:<br />
#<br />
# /etc/udev/rules.d/10-my-media-automount.rules<br />
<br />
# start at sdb to ignore the system hard drive<br />
KERNEL!="sd[b-z]*", GOTO="my_media_automount_end"<br />
ACTION=="add", PROGRAM!="/sbin/blkid %N", GOTO="my_media_automount_end"<br />
<br />
# import some useful filesystem info as variables<br />
IMPORT{program}="/sbin/blkid -o udev -p %N"<br />
<br />
# get the label if present, otherwise assign one based on device/partition<br />
ENV{ID_FS_LABEL}!="", ENV{dir_name}="%E{ID_FS_LABEL}"<br />
ENV{ID_FS_LABEL}=="", ENV{dir_name}="usbhd-%k"<br />
<br />
# create the dir in /media and symlink it to /mnt<br />
ACTION=="add", RUN+="/bin/mkdir -p '/media/%E{dir_name}'"<br />
<br />
# global mount options<br />
ACTION=="add", ENV{mount_options}="relatime"<br />
# filesystem-specific mount options (777/666 dir/file perms for ntfs/vfat) <br />
ACTION=="add", ENV{ID_FS_TYPE}=="vfat|ntfs", ENV{mount_options}="$env{mount_options},gid=100,dmask=000,fmask=111,utf8"<br />
<br />
# automount ntfs filesystems using ntfs-3g driver<br />
ACTION=="add", ENV{ID_FS_TYPE}=="ntfs", RUN+="/bin/mount -t ntfs-3g -o %E{mount_options} /dev/%k '/media/%E{dir_name}'"<br />
# automount all other filesystems<br />
ACTION=="add", ENV{ID_FS_TYPE}!="ntfs", RUN+="/bin/mount -t auto -o %E{mount_options} /dev/%k '/media/%E{dir_name}'"<br />
<br />
# clean up after device removal<br />
ACTION=="remove", ENV{dir_name}!="", RUN+="/bin/umount -l '/media/%E{dir_name}'", RUN+="/bin/rmdir '/media/%E{dir_name}'"<br />
<br />
# exit<br />
LABEL="my_media_automount_end"<br />
<br />
</nowiki>}}<br />
<br />
==== Mount SD cards ====<br />
The same rules as above can be used to auto-mount SD cards, you just need to replace {{Codeline|sd[a-z][0-9]}} by {{Codeline|mmcblk[0-9]p[0-9]}}:<br />
{{File|name=/etc/udev/rules.d/11-sd-cards-auto-mount.rules|content=<nowiki><br />
KERNEL!="mmcblk[0-9]p[0-9]", GOTO="sd_cards_auto_mount_end"<br />
<br />
# Global mount options<br />
ACTION=="add", ENV{mount_options}="relatime"<br />
# Filesystem specific options<br />
ACTION=="add", IMPORT{program}="/sbin/blkid -o udev -p %N"<br />
ACTION=="add", ENV{ID_FS_TYPE}=="vfat|ntfs", ENV{mount_options}="$env{mount_options},utf8,gid=100,umask=002"<br />
<br />
ACTION=="add", RUN+="/bin/mkdir -p /media/sd-%k", RUN+="/bin/ln -s /media/sd-%k /mnt/sd-%k", RUN+="/bin/mount -o $env{mount_options} /dev/%k /media/sd-%k"<br />
ACTION=="remove", RUN+="/bin/umount -l /media/sd-%k", RUN+="/bin/rmdir /media/sd-%k"<br />
LABEL="sd_cards_auto_mount_end"<br />
</nowiki>}}<br />
<br />
==== Mount CDs ====<br />
To auto mount a CD a simple [[#UDisks Wrapper|UDisks wrapper]] will get the job done properly.<br />
{{Note|Maybe this should be merged to the Udisks wrapper section.}}<br />
<br />
==== Accessing Firmware Programmers and USB Virtual Comm Devices ====<br />
The following ruleset will allow normal users (within the "users" group) the ability to access the [http://www.ladyada.net/make/usbtinyisp/ USBtinyISP] USB programmer for AVR microcontrollers and a generic (SiLabs [http://www.silabs.com/products/interface/usbtouart CP2102]) USB to UART adapter. Adjust the permissions accordingly. Verified as of 2010-02-11.<br />
<br />
{{File|name=/etc/udev/rules.d/50-embedded_devices.rules|content=<nowiki><br />
# USBtinyISP Programmer rules<br />
SUBSYSTEMS=="usb", ATTRS{idVendor}=="1781", ATTRS{idProduct}=="0c9f", GROUP="users", MODE="0666"<br />
SUBSYSTEMS=="usb", ATTRS{idVendor}=="16c0", ATTRS{idProduct}=="0479", GROUP="users", MODE="0666"<br />
<br />
# Mdfly.com Generic (SiLabs CP2102) 3.3v/5v USB VComm adapter<br />
SUBSYSTEMS=="usb", ATTRS{idVendor}=="10c4", ATTRS{idProduct}=="ea60", GROUP="users", MODE="0666"<br />
</nowiki>}}<br />
<br />
=== Speed Up udev ===<br />
<br />
Performance gains can be realized by bypassing the blacklisting logic present in the {{Filename|/lib/udev/load-modules.sh}} script. See [[Speed_Up_udev]] for additional details.<br />
<br />
=== Execute on USB Insert ===<br />
<br />
See [[Execute_on_usb_insert|execute on usb insert]] article or the [http://igurublog.wordpress.com/downloads/script-devmon/ devmon wrapper script].<br />
<br />
=== Mount external drives as a normal user ===<br />
<br />
If you want to mount a external drive on KDE or Gnome (maybe on other Desktop Environments too) as a normal user (without the need to type your superuser password) you just have to edit the {{Filename|/usr/share/polkit-1/actions/org.freedesktop.udisks.policy}} (remember to backup first) and change the line '''<allow_active>auth_admin_keep</allow_active>''' on '''<action id="org.freedesktop.udisks.filesystem-mount-system-internal">''' to '''<allow_active>yes</allow_active>'''.<br />
<br />
==Troubleshooting==<br />
=== Disabling modules auto-loading with the load_modules boot parameter ===<br />
If you pass {{Codeline|<nowiki>load_modules=off</nowiki>}} on your kernel boot line, then udev will skip all the auto-loading business. This is to provide you with a big ripcord to pull if something goes wrong. If udev loads a problematic module that hangs your system or something equally awful, then you can bypass auto-loading with this parameter, then go in and blacklist the offensive module(s).<br />
<br />
=== Blacklisting Modules ===<br />
In rare cases, Udev can make mistakes and load the wrong modules. To prevent it from doing this, you can blacklist modules. Once blacklisted, udev will never load that module. See [[blacklisting]]. Not at boot-time ''or'' later on when a hotplug event is received (eg, you plug in your USB flash drive).<br />
<br />
=== udevd hangs at boot ===<br />
After migrating to LDAP or updating an LDAP-backed system udevd can hang at boot at the message "Starting UDev Daemon". This is usually caused by udevd trying to look up a name from LDAP but failing, because the network is not up yet. The solution is to ensure that all system group names are present locally.<br />
<br />
Extract the group names referenced in udev rules and the group names actually present on the system:<br />
<br />
# fgrep -r GROUP /etc/udev/rules.d/ /lib/udev/rules.d | perl -nle '/GROUP\s*=\s*"(.*?)"/ && print $1;' | sort | uniq > udev_groups<br />
# cut -f1 -d: /etc/gshadow /etc/group | sort | uniq > present_groups<br />
<br />
To see the differences, do a side-by-side diff:<br />
<br />
# diff -y present_groups udev_groups<br />
...<br />
network <<br />
nobody <<br />
ntp <<br />
optical optical<br />
power | pcscd<br />
rfkill <<br />
root root<br />
scanner scanner<br />
smmsp <<br />
storage storage<br />
...<br />
<br />
In this case, the pcscd group is for some reason not present in the system. Add the missing groups:<br />
<br />
# groupadd pcscd<br />
<br />
Also, make sure local resources are looked up before resorting to LDAP. {{Filename|/etc/nsswitch.conf}} should contain the line<br />
<br />
group: files ldap<br />
<br />
=== Known Problems with Hardware ===<br />
====BusLogic devices can be broken and will cause a freeze during startup====<br />
This is a kernel bug and no fix has been provided yet.<br />
====PCMCIA Card readers are not treated as removable devices====<br />
To get access to them with hal's pmount backend add them to {{Filename|/etc/pmount.allow}}<br />
<br />
=== Known Problems with Auto-Loading ===<br />
==== CPU frequency modules ====<br />
The current detection method for the various CPU frequency controllers is inadequate, so this has been omitted from the auto-loading process for the time being. To use CPU frequency scaling, load the proper module explicitly in your {{Codeline|MODULES}} array in {{Filename|[[rc.conf]]}}.<br />
<br />
====Sound Problems or Some Modules Not Loaded Automatically====<br />
Some users have traced this problem to old entries in {{Filename|/etc/modprobe.d/sound.conf}}. Try cleaning that file out and trying again.<br />
<br />
==== Mixed Up Devices, Sound/Network Cards Changing Order Each Boot ====<br />
Because udev loads all modules asynchronously, they are initialized in a different order. This can result in devices randomly switching names. For example, with two network cards, you may notice a switching of designations between {{Codeline|eth0}} and {{Codeline|eth1}}.<br />
<br />
Arch Linux provides the advantage of specifying the module load order by listing the modules in the {{Codeline|MODULES}} array in {{Filename|[[rc.conf]]}}. Modules in this array are loaded before udev begins auto-loading, so you have full control over the load order.<br />
<br />
# Always load 8139too before e100<br />
MODULES=(8139too e100)<br />
<br />
<br />
Another method for network card ordering is to use the udev-sanctioned method of statically-naming each interface. Create the following file to bind the MAC address of each of your cards to a certain interface name:<br />
{{File|name=/etc/udev/rules.d/10-network.rules|content=<nowiki><br />
SUBSYSTEM=="net", ATTR{address}=="aa:bb:cc:dd:ee:ff", NAME="lan0"<br />
SUBSYSTEM=="net", ATTR{address}=="ff:ee:dd:cc:bb:aa", NAME="wlan0"<br />
</nowiki>}}<br />
<br />
A couple things to note:<br />
* To get the MAC address of each card, use this command: {{Codeline|<nowiki>udevadm info -a -p /sys/class/net/<yourdevice> | grep address | tr [A-Z] [a-z]</nowiki>}}<br />
* Make sure to use the lower-case hex values in your udev rules. It doesn't like upper-case.<br />
* Some people have problems naming their interfaces after the old style: eth0, eth1, etc. Try something like "lan" or "wlan" if you experience this problem.<br />
<br />
Don't forget to update your {{Filename|/etc/rc.conf}} and other configuration files using the old ethX notation!<br />
<br />
<br />
Another method for setting network interface names is described in the Configuring Network wiki entry.<br />
http://wiki.archlinux.org/index.php/Configuring_Network<br/><br />
http://wiki.archlinux.org/index.php/Configuring_Network#Interface_names_varying<br />
<br />
=== Known Problems for Custom Kernel Users ===<br />
==== Udev doesn't start at all ====<br />
Make sure you have a kernel version later than or equal to 2.6.15. Earlier kernels do not have the necessary uevent stuff that udev needs for auto-loading.<br />
<br />
==== CD/DVD symlinks and permissions are broken ====<br />
If you're using a 2.6.15 kernel, you'll need the uevent patch from ABS (which backports certain uevent functionality from 2.6.16). Just sync up your ABS tree with the {{Codeline|abs}} command, then you'll find the patch in {{Codeline|/var/abs/kernels/kernel26/}}.<br />
<br />
==Other Resources==<br />
* [http://www.kernel.org/pub/linux/utils/kernel/hotplug/udev.html Udev Homepage]<br />
* [http://www.linux.com/news/hardware/peripherals/180950-udev An Introduction to Udev]<br />
* [http://vger.kernel.org/vger-lists.html#linux-hotplug Udev mailing list information]</div>Jnguyenhttps://wiki.archlinux.org/index.php?title=TOMOYO_Linux&diff=138986TOMOYO Linux2011-04-30T16:06:04Z<p>Jnguyen: </p>
<hr />
<div>[[Category:Security (English)]]<br />
[[Category:Kernel (English)]]<br />
[[Category:Networking (English)]]<br />
[[Category:HOWTOs (English)]]<br />
[http://tomoyo.sourceforge.jp/ TOMOYO Linux] is Mandatory Access Control (MAC) implementation for Linux. It was launched in March 2003 and is sponsored by [http://www.nttdata.co.jp/en/ NTT Data Corporation]. TOMOYO Linux focuses on the behaviour of a system, allowing each process to declare behaviours and resources needed to achieve its purpose. It can be used as a system analysis tool as well as an access restriction tool.<br />
<br />
The security goal of TOMOYO Linux is to provide "MAC that covers practical requirements for most users and keeps usable for most administrators". TOMOYO Linux is not a tool or security professional but for average users and administrators.<br />
{{Note|This article does not aim to be an exhaustive guide and should be used as a supplement to the extensive [http://tomoyo.sourceforge.jp/documentation.html user documentation] provided by the project.}}<br />
{{Tip|The [[#TOMOYO Linux 2.x|TOMOYO Linux 2.x]] branch is already in the Arch Linux [community] repository. This branch will eventually come closer to reaching feature parity with the 1.x branch, but for those wanting an easy start the 2.x branch is easy to install. The [[#TOMOYO Linux 1.x|TOMOYO Linux 1.x]] branch is for those wanting the greatest security, while [[#AKARI|AKARI]] is somewhere in between.}}<br />
<br />
==Introduction==<br />
TOMOYO Linux attempts to make the system where everything is prearranged in an easy to understand way:<br />
* Make all access requests that will occur at least once during the lifetime of the kernel known in advance<br />
* Allow the administrator to write a policy that only allows expected and desirable access requests<br />
Unlike AppArmor, TOMOYO Linux is intended to protect the whole system from attackers exploiting vulnerabilities in applications. TOMOYO Linux addresses this threat by recording the behaviour of all applications in the test environment and then forcing all applications to act within these recorded behaviours in the production environment.<br />
<br />
TOMOYO Linux is not for users wanting ready-made policy files supplied by others. It involves creating policy from scratch, aided by the "learning mode" which can automatically generate policy files with necessary and sufficient permissions for a specific system. TOMOYO Linux reports what is happening within the Linux system and can therefore be used as a system analysis tool. It resembles strace and reports what is being executed by each program and what files/networks are accessed.<br />
<br />
This [http://tomoyo.sourceforge.jp/wiki-e/?WhatIs#comparison table] provides a comprehensive comparison of TOMOYO Linux with [[AppArmor]], [[SELinux]] and [http://schaufler-ca.com/ SMACK].<br />
<br />
==Branches of development==<br />
[http://tomoyo.sourceforge.jp/1.8/index.html.en TOMOYO Linux 1.x] is the original branch of development. TOMOYO Linux was first released on 11th November 2005. It was implemented as a patch that can be applied to the Linux kernel and is still in active development. It can coexist with other security modules such as SELinux, SMACK and AppArmor.<br />
<br />
[http://tomoyo.sourceforge.jp/2.3/index.html.en TOMOYO Linux 2.x] is the Linux mainline kernel branch of development. In June 2009, TOMOYO was merged into the Linux kernel version 2.6.30 and it uses standard Linux Security Module (LSM) hooks. However, the LSM hooks must be extended further in order to port the full MAC functionality of TOMOYO Linux into the Linux kernel. Thus, it does not yet provide equal functionality with the 1.x branch of development. This [http://tomoyo.sourceforge.jp/comparison.html.en chart] compares the differences between each branch.<br />
<br />
[http://akari.sourceforge.jp/ AKARI] is based on the TOMOYO Linux 1.x branch and is implemented as a Loadable Kernel Module (LKM). It therefore has the advantage of not requiring the user to patch and recompile the kernel. This [http://akari.sourceforge.jp/comparison.html table] provides a comprehensive comparison of AKARI with the TOMOYO Linux 1.x and 2.x branches.<br />
<br />
==TOMOYO Linux Repository==<br />
'''This repository has temporarily been taken down for reasons listed [https://bbs.archlinux.org/viewtopic.php?pid=917720#p917720 here].'''<br />
<br />
<br />
An [[Unofficial_User_Repositories|unofficial user repository]] has been made available that has all the necessary packages, including patched versions of kernel26 for both i686 and x86_64. The repository can be browsed at [http://repo.tomoyolinux.co.uk repo.tomoyolinux.co.uk]. Add the following to the bottom of "/etc/pacman.conf":<br />
<br />
<pre><br />
[tomoyo]<br />
Server = http://repo.tomoyolinux.co.uk/archlinux/$arch<br />
</pre><br />
<br />
To view the packages in the repository, run the following:<br />
<br />
<pre><br />
pacman -Sl tomoyo<br />
</pre><br />
<br />
Forum thread can be found [https://bbs.archlinux.org/viewtopic.php?id=114075 here].<br />
<br />
==TOMOYO Linux 1.x==<br />
Implementing TOMOYO Linux 1.x using a kernel patched with ccs-patch provides the full functionality obtainable from the TOMOYO Linux project. However, implementation of this branch requires the most hurdles to be overcome, as the kernel must be patched with [http://sourceforge.jp/projects/tomoyo/ ccs-patch] and subsequently recompiled.<br />
<br />
Both kernel26-ccs and the userspace tools must be installed. A package for [http://aur.archlinux.org/packages.php?ID=44131 kernel-ccs] and a package for [http://aur.archlinux.org/packages.php?ID=42606 ccs-tools] are available on the AUR.<br />
<br />
Binary packages are available in the [[#TOMOYO Linux Repository|[tomoyo] repository]].<br />
<br />
===Initializing configuration===<br />
The policy must first be initialized:<br />
# /usr/lib/ccs/init_policy<br />
The policy files are saved in the /etc/css/ directory and can be edited by running:<br />
# ccs-editpolicy<br />
<br />
==AKARI==<br />
===Limitations of AKARI===<br />
AKARI has the advantage of not requiring kernel recompilation. If using the TOMOYO Linux project purely for system analysis, then AKARI is the easiest method of achieving this. If using the TOMOYO Linux project for system restriction, it is a minimal effort way to gain most of the functionality of the TOMOYO Linux 1.x branch. However, there are a few limitations that must be considered:<br />
* It depends on the kernel version and configuration provided by the distribution:<br />
<pre><br />
CONFIG_SECURITY=y [required]<br />
CONFIG_KALLSYMS=y [required]<br />
CONFIG_PROC_FS=y [required]<br />
CONFIG_MODULES=y [required]<br />
CONFIG_SECURITY_PATH=y [optional: for using absolute pathnames]<br />
CONFIG_SECURITY_NETWORK=y [optional: for providing network restriction]<br />
</pre><br />
* The restriction of a few advanced networking operations are limited or unavailable due to the absence of required LSM hooks<br />
* Restricting use of [http://en.wikipedia.org/wiki/Capability-based_security capabilities] is not possible<br />
* Looking up per-task variables is slower as they are managed outside "struct task_struct" in order to keep KABI unchanged. However, this should not be noticeable for the typical end-user as performance decrease by pathname based permission checking is dominant<br />
This [http://akari.sourceforge.jp/comparison.html table] provides a comprehensive comparison of AKARI with the TOMOYO Linux 1.x and 2.x branches.<br />
<br />
{{Note|The Arch Linux kernel from 2.6.36 onwards provides all of the configuration options required for full functionality.}}<br />
<br />
===Installation===<br />
Both AKARI and the userspace tools must be installed. A package for [http://aur.archlinux.org/packages.php?ID=42608 AKARI] and a package for [http://aur.archlinux.org/packages.php?ID=42606 ccs-tools] are available on the AUR.<br />
<br />
The bootloader configuration must be changed in order to activate AKARI:<br />
title Arch Linux<br />
root (hd0,0)<br />
kernel /boot/vmlinuz26 root=/dev/sda1 ro init=/sbin/ccs-init<br />
initrd /boot/kernel26.img<br />
<br />
Binary packages are available in the [[#TOMOYO Linux Repository|[tomoyo] repository]].<br />
<br />
===Initializing configuration===<br />
The policy must first be initialized:<br />
# /usr/lib/ccs/init_policy --module_name=akari<br />
The policy files are saved in the /etc/css/ directory and can be edited by running:<br />
# ccs-editpolicy<br />
<br />
==TOMOYO Linux 2.x==<br />
===Limitations of TOMOYO Linux 2.x===<br />
The implementation of TOMOYO Linux 2.x into the Linux mainline kernel is not yet complete but is still effective for MAC of files. It does not yet support the restriction of:<br />
* file attribute and namespace manipulation<br />
* capabilities<br />
* network<br />
* signal<br />
* environment variables<br />
* local port reservation<br />
This [http://tomoyo.sourceforge.jp/comparison.html.en chart] has a more comprehensive comparison of the differences between each branch of development.<br />
<br />
===Installation===<br />
TOMOYO Linux 2.x is part of the Linux mainline kernel and, in addition to those previously mentioned, requires the following kernel configuration:<br />
CONFIG_SECURITY_TOMOYO=y<br />
{{note|The Arch Linux kernel from 2.6.36 onwards provides all of the configuration options required for full functionality.}}<br />
<br />
If the kernel supports TOMOYO Linux 2.x, then only the userspace tools need to be installed:<br />
<br />
<pre><br />
pacman -S tomoyo-tools<br />
</pre><br />
<br />
For kernel versions between 2.6.30 and 2.6.35, tomoyo-tools 2.2.x should be installed. A package is available on the [http://aur.archlinux.org/packages.php?ID=42272 AUR]<br />
<br />
===Initializing configuration===<br />
The policy must first be initialized:<br />
# /usr/lib/tomoyo/init_policy<br />
The policy files are saved in the /etc/tomoyo/ directory and can be edited by running:<br />
# tomoyo-editpolicy<br />
<br />
==Usage==<br />
It is important to consult the relevant documentation in order to use TOMOYO Linux or AKARI effectively:<br />
* [http://tomoyo.sourceforge.jp/documentation.html.en TOMOYO Linux documentation]<br />
* [http://akari.sourceforge.jp/index.html.en AKARI documentation]<br />
Run the policy editor to begin editing. If using TOMOYO Linux 1.x or AKARI then ccs-tools should be used:<br />
# /usr/sbin/ccs-editpolicy<br />
If using TOMOYO Linux 2.x then tomoyo-tools should be used:<br />
# /usr/sbin/tomoyo-editpolicy<br />
As the system runs, TOMOYO Linux will create domains and add them to the tree. The access analysis/restriction in TOMOYO Linux is applied via domains. Every process belongs to a single domain and the process will transit to a different domain whenever it executes a program. The name of a domain is a concatenated string expression for the process execution history. For example, the name of the domain which the kernel belongs to is "<kernel>"; the name of domain which /sbin/init invoked by the kernel belongs to is "<kernel> /sbin/init"; if /sbin/init invokes /etc/rc.d/rc then the domain it belongs to is "<kernel> /sbin/init /etc/rc.d/rc". You can suppress or initialize domain transitions as needed.<br />
<br />
Profiles can be assigned to each domain. There are four default profiles:<br />
<br />
{| border="1"<br />
| Disabled || Works as if regular kernel.<br />
|-<br />
| Learning || Do not reject an access request if it violates policy. Append the request to policy.<br />
|-<br />
| Permissive || Do not reject an access request if it violates policy. Do not append the request to policy.<br />
|-<br />
| Enforcing || Reject an access request if it violates policy. Do not append the request to policy.<br />
|}<br />
The learning profile can be used to analyse the system or a specific application. Once all of the desired access requests of a domain have been identified, the policy for that domain can be edited as required before selecting the enforcing profile. This can be done for any and all domains from the start of system boot.<br />
<br />
==References==<br />
* [http://tomomyo.sourceforge.jp/ TOMOYO Linux SourceForge page]<br />
* [http://tomoyo.sourceforge.jp/wiki-e/ TOMOYO Linux Wiki]<br />
* [http://akari.sourceforge.jp/index.html.en AKARI SourceForge page]<br />
* [http://akari.sourceforge.jp/index.html.en AKARI documentation]<br />
* [http://tomoyo.sourceforge.jp/1.8/index.html.en TOMOYO Linux 1.8.x documentation]<br />
* [http://tomoyo.sourceforge.jp/2.3/index.html.en TOMOYO Linux 2.3.x documentation]<br />
* [http://lwn.net/Articles/263179/ TOMOYO Linux Security Goal]<br />
* [http://tomoyo.sourceforge.jp/cgi-bin/lxr/source/centos5.5/domain_policy.conf?v=policy-sample Policy sample]<br />
* [http://elinux.org/TomoyoLinux TOMOYO Linux on the Embedded Linux Wiki]<br />
* [http://sourceforge.jp/projects/tomoyo/document/PacSec2007-en-demo.pdf Presentation slides from PacSec 2007]<br />
<br />
==See also==<br />
* [[AppArmor]]<br />
* [[SELinux]]</div>Jnguyenhttps://wiki.archlinux.org/index.php?title=TOMOYO_Linux&diff=138985TOMOYO Linux2011-04-30T16:05:15Z<p>Jnguyen: </p>
<hr />
<div>[[Category:Security (English)]]<br />
[[Category:Kernel (English)]]<br />
[[Category:Networking (English)]]<br />
[[Category:HOWTOs (English)]]<br />
[http://tomoyo.sourceforge.jp/ TOMOYO Linux] is Mandatory Access Control (MAC) implementation for Linux. It was launched in March 2003 and is sponsored by [http://www.nttdata.co.jp/en/ NTT Data Corporation]. TOMOYO Linux focuses on the behaviour of a system, allowing each process to declare behaviours and resources needed to achieve its purpose. It can be used as a system analysis tool as well as an access restriction tool.<br />
<br />
The security goal of TOMOYO Linux is to provide "MAC that covers practical requirements for most users and keeps usable for most administrators". TOMOYO Linux is not a tool or security professional but for average users and administrators.<br />
{{Note|This article does not aim to be an exhaustive guide and should be used as a supplement to the extensive [http://tomoyo.sourceforge.jp/documentation.html user documentation] provided by the project.}}<br />
{{Tip|The [[#TOMOYO Linux 2.x|TOMOYO Linux 2.x]] branch is already in the Arch Linux [community] repository. This branch will eventually come closer to reaching feature parity with the 1.x branch, but for those wanting an easy start the 2.x branch is easy to install. The [[#TOMOYO Linux 1.x|TOMOYO Linux 1.x]] branch is for those wanting the greatest security, while AKARI is somewhere in between.}}<br />
<br />
==Introduction==<br />
TOMOYO Linux attempts to make the system where everything is prearranged in an easy to understand way:<br />
* Make all access requests that will occur at least once during the lifetime of the kernel known in advance<br />
* Allow the administrator to write a policy that only allows expected and desirable access requests<br />
Unlike AppArmor, TOMOYO Linux is intended to protect the whole system from attackers exploiting vulnerabilities in applications. TOMOYO Linux addresses this threat by recording the behaviour of all applications in the test environment and then forcing all applications to act within these recorded behaviours in the production environment.<br />
<br />
TOMOYO Linux is not for users wanting ready-made policy files supplied by others. It involves creating policy from scratch, aided by the "learning mode" which can automatically generate policy files with necessary and sufficient permissions for a specific system. TOMOYO Linux reports what is happening within the Linux system and can therefore be used as a system analysis tool. It resembles strace and reports what is being executed by each program and what files/networks are accessed.<br />
<br />
This [http://tomoyo.sourceforge.jp/wiki-e/?WhatIs#comparison table] provides a comprehensive comparison of TOMOYO Linux with [[AppArmor]], [[SELinux]] and [http://schaufler-ca.com/ SMACK].<br />
<br />
==Branches of development==<br />
[http://tomoyo.sourceforge.jp/1.8/index.html.en TOMOYO Linux 1.x] is the original branch of development. TOMOYO Linux was first released on 11th November 2005. It was implemented as a patch that can be applied to the Linux kernel and is still in active development. It can coexist with other security modules such as SELinux, SMACK and AppArmor.<br />
<br />
[http://tomoyo.sourceforge.jp/2.3/index.html.en TOMOYO Linux 2.x] is the Linux mainline kernel branch of development. In June 2009, TOMOYO was merged into the Linux kernel version 2.6.30 and it uses standard Linux Security Module (LSM) hooks. However, the LSM hooks must be extended further in order to port the full MAC functionality of TOMOYO Linux into the Linux kernel. Thus, it does not yet provide equal functionality with the 1.x branch of development. This [http://tomoyo.sourceforge.jp/comparison.html.en chart] compares the differences between each branch.<br />
<br />
[http://akari.sourceforge.jp/ AKARI] is based on the TOMOYO Linux 1.x branch and is implemented as a Loadable Kernel Module (LKM). It therefore has the advantage of not requiring the user to patch and recompile the kernel. This [http://akari.sourceforge.jp/comparison.html table] provides a comprehensive comparison of AKARI with the TOMOYO Linux 1.x and 2.x branches.<br />
<br />
==TOMOYO Linux Repository==<br />
'''This repository has temporarily been taken down for reasons listed [https://bbs.archlinux.org/viewtopic.php?pid=917720#p917720 here].'''<br />
<br />
<br />
An [[Unofficial_User_Repositories|unofficial user repository]] has been made available that has all the necessary packages, including patched versions of kernel26 for both i686 and x86_64. The repository can be browsed at [http://repo.tomoyolinux.co.uk repo.tomoyolinux.co.uk]. Add the following to the bottom of "/etc/pacman.conf":<br />
<br />
<pre><br />
[tomoyo]<br />
Server = http://repo.tomoyolinux.co.uk/archlinux/$arch<br />
</pre><br />
<br />
To view the packages in the repository, run the following:<br />
<br />
<pre><br />
pacman -Sl tomoyo<br />
</pre><br />
<br />
Forum thread can be found [https://bbs.archlinux.org/viewtopic.php?id=114075 here].<br />
<br />
==TOMOYO Linux 1.x==<br />
Implementing TOMOYO Linux 1.x using a kernel patched with ccs-patch provides the full functionality obtainable from the TOMOYO Linux project. However, implementation of this branch requires the most hurdles to be overcome, as the kernel must be patched with [http://sourceforge.jp/projects/tomoyo/ ccs-patch] and subsequently recompiled.<br />
<br />
Both kernel26-ccs and the userspace tools must be installed. A package for [http://aur.archlinux.org/packages.php?ID=44131 kernel-ccs] and a package for [http://aur.archlinux.org/packages.php?ID=42606 ccs-tools] are available on the AUR.<br />
<br />
Binary packages are available in the [[#TOMOYO Linux Repository|[tomoyo] repository]].<br />
<br />
===Initializing configuration===<br />
The policy must first be initialized:<br />
# /usr/lib/ccs/init_policy<br />
The policy files are saved in the /etc/css/ directory and can be edited by running:<br />
# ccs-editpolicy<br />
<br />
==AKARI==<br />
===Limitations of AKARI===<br />
AKARI has the advantage of not requiring kernel recompilation. If using the TOMOYO Linux project purely for system analysis, then AKARI is the easiest method of achieving this. If using the TOMOYO Linux project for system restriction, it is a minimal effort way to gain most of the functionality of the TOMOYO Linux 1.x branch. However, there are a few limitations that must be considered:<br />
* It depends on the kernel version and configuration provided by the distribution:<br />
<pre><br />
CONFIG_SECURITY=y [required]<br />
CONFIG_KALLSYMS=y [required]<br />
CONFIG_PROC_FS=y [required]<br />
CONFIG_MODULES=y [required]<br />
CONFIG_SECURITY_PATH=y [optional: for using absolute pathnames]<br />
CONFIG_SECURITY_NETWORK=y [optional: for providing network restriction]<br />
</pre><br />
* The restriction of a few advanced networking operations are limited or unavailable due to the absence of required LSM hooks<br />
* Restricting use of [http://en.wikipedia.org/wiki/Capability-based_security capabilities] is not possible<br />
* Looking up per-task variables is slower as they are managed outside "struct task_struct" in order to keep KABI unchanged. However, this should not be noticeable for the typical end-user as performance decrease by pathname based permission checking is dominant<br />
This [http://akari.sourceforge.jp/comparison.html table] provides a comprehensive comparison of AKARI with the TOMOYO Linux 1.x and 2.x branches.<br />
<br />
{{Note|The Arch Linux kernel from 2.6.36 onwards provides all of the configuration options required for full functionality.}}<br />
<br />
===Installation===<br />
Both AKARI and the userspace tools must be installed. A package for [http://aur.archlinux.org/packages.php?ID=42608 AKARI] and a package for [http://aur.archlinux.org/packages.php?ID=42606 ccs-tools] are available on the AUR.<br />
<br />
The bootloader configuration must be changed in order to activate AKARI:<br />
title Arch Linux<br />
root (hd0,0)<br />
kernel /boot/vmlinuz26 root=/dev/sda1 ro init=/sbin/ccs-init<br />
initrd /boot/kernel26.img<br />
<br />
Binary packages are available in the [[#TOMOYO Linux Repository|[tomoyo] repository]].<br />
<br />
===Initializing configuration===<br />
The policy must first be initialized:<br />
# /usr/lib/ccs/init_policy --module_name=akari<br />
The policy files are saved in the /etc/css/ directory and can be edited by running:<br />
# ccs-editpolicy<br />
<br />
==TOMOYO Linux 2.x==<br />
===Limitations of TOMOYO Linux 2.x===<br />
The implementation of TOMOYO Linux 2.x into the Linux mainline kernel is not yet complete but is still effective for MAC of files. It does not yet support the restriction of:<br />
* file attribute and namespace manipulation<br />
* capabilities<br />
* network<br />
* signal<br />
* environment variables<br />
* local port reservation<br />
This [http://tomoyo.sourceforge.jp/comparison.html.en chart] has a more comprehensive comparison of the differences between each branch of development.<br />
<br />
===Installation===<br />
TOMOYO Linux 2.x is part of the Linux mainline kernel and, in addition to those previously mentioned, requires the following kernel configuration:<br />
CONFIG_SECURITY_TOMOYO=y<br />
{{note|The Arch Linux kernel from 2.6.36 onwards provides all of the configuration options required for full functionality.}}<br />
<br />
If the kernel supports TOMOYO Linux 2.x, then only the userspace tools need to be installed:<br />
<br />
<pre><br />
pacman -S tomoyo-tools<br />
</pre><br />
<br />
For kernel versions between 2.6.30 and 2.6.35, tomoyo-tools 2.2.x should be installed. A package is available on the [http://aur.archlinux.org/packages.php?ID=42272 AUR]<br />
<br />
===Initializing configuration===<br />
The policy must first be initialized:<br />
# /usr/lib/tomoyo/init_policy<br />
The policy files are saved in the /etc/tomoyo/ directory and can be edited by running:<br />
# tomoyo-editpolicy<br />
<br />
==Usage==<br />
It is important to consult the relevant documentation in order to use TOMOYO Linux or AKARI effectively:<br />
* [http://tomoyo.sourceforge.jp/documentation.html.en TOMOYO Linux documentation]<br />
* [http://akari.sourceforge.jp/index.html.en AKARI documentation]<br />
Run the policy editor to begin editing. If using TOMOYO Linux 1.x or AKARI then ccs-tools should be used:<br />
# /usr/sbin/ccs-editpolicy<br />
If using TOMOYO Linux 2.x then tomoyo-tools should be used:<br />
# /usr/sbin/tomoyo-editpolicy<br />
As the system runs, TOMOYO Linux will create domains and add them to the tree. The access analysis/restriction in TOMOYO Linux is applied via domains. Every process belongs to a single domain and the process will transit to a different domain whenever it executes a program. The name of a domain is a concatenated string expression for the process execution history. For example, the name of the domain which the kernel belongs to is "<kernel>"; the name of domain which /sbin/init invoked by the kernel belongs to is "<kernel> /sbin/init"; if /sbin/init invokes /etc/rc.d/rc then the domain it belongs to is "<kernel> /sbin/init /etc/rc.d/rc". You can suppress or initialize domain transitions as needed.<br />
<br />
Profiles can be assigned to each domain. There are four default profiles:<br />
<br />
{| border="1"<br />
| Disabled || Works as if regular kernel.<br />
|-<br />
| Learning || Do not reject an access request if it violates policy. Append the request to policy.<br />
|-<br />
| Permissive || Do not reject an access request if it violates policy. Do not append the request to policy.<br />
|-<br />
| Enforcing || Reject an access request if it violates policy. Do not append the request to policy.<br />
|}<br />
The learning profile can be used to analyse the system or a specific application. Once all of the desired access requests of a domain have been identified, the policy for that domain can be edited as required before selecting the enforcing profile. This can be done for any and all domains from the start of system boot.<br />
<br />
==References==<br />
* [http://tomomyo.sourceforge.jp/ TOMOYO Linux SourceForge page]<br />
* [http://tomoyo.sourceforge.jp/wiki-e/ TOMOYO Linux Wiki]<br />
* [http://akari.sourceforge.jp/index.html.en AKARI SourceForge page]<br />
* [http://akari.sourceforge.jp/index.html.en AKARI documentation]<br />
* [http://tomoyo.sourceforge.jp/1.8/index.html.en TOMOYO Linux 1.8.x documentation]<br />
* [http://tomoyo.sourceforge.jp/2.3/index.html.en TOMOYO Linux 2.3.x documentation]<br />
* [http://lwn.net/Articles/263179/ TOMOYO Linux Security Goal]<br />
* [http://tomoyo.sourceforge.jp/cgi-bin/lxr/source/centos5.5/domain_policy.conf?v=policy-sample Policy sample]<br />
* [http://elinux.org/TomoyoLinux TOMOYO Linux on the Embedded Linux Wiki]<br />
* [http://sourceforge.jp/projects/tomoyo/document/PacSec2007-en-demo.pdf Presentation slides from PacSec 2007]<br />
<br />
==See also==<br />
* [[AppArmor]]<br />
* [[SELinux]]</div>Jnguyenhttps://wiki.archlinux.org/index.php?title=Unofficial_user_repositories&diff=137114Unofficial user repositories2011-04-13T07:56:33Z<p>Jnguyen: /* Both i686 and x86_64 */ temporarily remove [tomoyo]</p>
<hr />
<div>[[Category: Package management (English)]]<br />
==Why unofficial user repositories==<br />
Since the AUR only allows users to upload PKGBUILD and other package build related files, but does not provide a means for distributing a binary package, a user may want to create a binary repository of their packages elsewhere.<br />
<br />
==The future of Unofficial repos==<br />
I'd like to see more work of this type. Sometimes there are certain projects that don't mesh well with other things, such as the community repo. The 'kdemod' project is a good example. If you want to contribute with your own builds, you can check page [[Custom local repository]].<br />
<br />
In the future, well-thought-out user repositories may be ideal for lots of supplementary things. Forming a "web of trust" is important in cases like this, so we may begin keeping a list of "recommended" repositories somewhere, in order to make it seem more official and trustworthy.<br />
<br />
[[User:Phrakture|Phrakture]] 12:50, 18 May 2007 (EDT)<br />
<br />
== The community repository, maintained by the TUs==<br />
The community repository is included in pacman's default configuration.<br />
<br />
[community]<br />
Include = /etc/pacman.d/mirrorlist<br />
<br />
==List of PUR (unofficial user repositories)==<br />
===Any===<br />
"Any" repos are architecture-independent, i.e. they can be used on both i686 and x86_64 systems.<br />
<pre><br />
[herecura-stable-any]<br />
# Just some stuff; a few java apps, wallpapers, small scripts, xbmc-skin<br />
Server = http://herecura.be/repo/herecura-stable/any<br />
<br />
[herecura-testing-any]<br />
# Some any testing stuff, xbmc-svn skin<br />
Server = http://herecura.be/repo/herecura-testing/any<br />
<br />
[xyne-any]<br />
# The home of Xyne's contributions.<br />
# More info including a package list can be found at http://xyne.archlinux.ca/repos<br />
Server = http://xyne.archlinux.ca/repos/xyne-any/<br />
<br />
</pre><br />
<br />
===Both i686 and x86_64===<br />
<!--Not exactly same as 'any' repositories, this section should probably be separate.--><br />
Repositories with both i686 and x86_64 versions. The $arch variable will be set automatically by pacman.<br />
<pre><br />
[archlinuxfr]<br />
# The french Arch Linux communities packages.<br />
Server = http://repo.archlinux.fr/$arch<br />
<br />
[archaudio-stable]<br />
# and/or *-testing, *-experimental<br />
# Pro-audio repo:<br />
# - http://archaudio.org<br />
# Replace "stable" with repo type (testing/experimental).<br />
Server = http://repos.archaudio.org/stable/$arch<br />
<br />
[archstuff]<br />
# AUR's most voted and many bin32-* and lib32-* packages.<br />
Server = http://archstuff.vs169092.vserver.de/$arch<br />
<br />
[arch-games]<br />
# The Arch Linux Gaming repository project.<br />
# Active mirrors listed in https://github.com/Arch-Games/arch-games/wiki/Mirrors<br />
Server = http://repo.exigen.org/arch/games/$arch<br />
Server = ftp://mirror.selfnet.de/arch-games/$arch<br />
# Currently inactive mirrors<br />
#Server = http://arch.twilightlair.net/games/$arch<br />
#Server = http://pseudoform.org/arch-games/games/$arch<br />
<br />
[burg]<br />
# Burg bootloader repo<br />
# More info : http://archydeb.wordpress.com/<br />
Server = http://dl.dropbox.com/u/11529444/$arch<br />
<br />
[cake]<br />
# Crapkit, dbus, hal, etc. stripped packages compatible with Arch Linux (from http://hereticlinux.org/).<br />
Server = http://hereticlinux.org/repo/cake/$arch<br />
<br />
[catalyst]<br />
# ATI Catalyst proprietary drivers.<br />
Server = http://catalyst.apocalypsus.net/repo/catalyst/$arch<br />
<br />
[englab]<br />
# Packages of englab (mathematical programs), its toolboxes and dependencies.<br />
Server = http://englab.bugfest.net/arch/$arch<br />
<br />
[kernel26-ck]<br />
# ARCH kernel with Brain Fuck Scheduler and all the goodies in the ck1 patch set<br />
Server = http://home.comcast.net/~repo-ck/$arch<br />
<br />
[pfkernel]<br />
# Kernel packages: generic i686 and x86_64, optimized P3, P4, K7, Atom, Pentium-M, K8, Core2<br />
# nvidia-pf, squid3, arora-git, nvidia-utils-beta<br />
Server = http://dl.dropbox.com/u/11734958/$arch<br />
<br />
[radeon]<br />
# ATI Radeon X.Org drivers, bleeding edge 'git' builds.<br />
Server = http://spiralinear.org/perry3d/$arch<br />
<br />
[sergej-repo]<br />
# ion3 and some other stuff.<br />
# http://code.google.com/p/archlinux-stuff/source/browse/trunk<br />
Server = http://repo.p5n.pp.ru/sergej-repo/$arch/<br />
<br />
[suckless]<br />
# suckless.org packages<br />
Server = http://dl.suckless.org/arch/$arch<br />
<br />
[unarch]<br />
# Offers support mainly against devel packages.<br />
# Contains stable packages that aren't in official repo.<br />
Server = http://us4all.info/unarch/arch/$arch<br />
<br />
[kittyserve]<br />
# Contains kittykatt's packages and packages from friends of kittykatt, as well as most mint-related packages<br />
Server = http://repo.kattz.tk/$arch<br />
</pre><br />
<br />
===i686 only===<br />
<pre><br />
[adslgr32]<br />
# The Hellenic (Greek) Arch Linux unofficial repository with many interesting packages.<br />
Server = http://archlinuxgr.tiven.org/archlinux/i686/<br />
<br />
[kde4-eyecandy-32]<br />
# Useful and beautiful plasmoids and themes for KDE4.<br />
Server = http://archlinuxgr.tiven.org/kde4-eyecandy/i686/<br />
<br />
[andrwe]<br />
# For a list of packages see: http://andrwe.org/doku.php/blog/linux/repository<br />
Server = http://repo.andrwe.org/i686<br />
<br />
[archlinux-es]<br />
# Repositorio Hispano (Spanish/Hispanic Respository).<br />
Server = http://repo.archlinux-es.org/i686<br />
<br />
[arch-graphics]<br />
# Repository aimed to provide applications mainly for 3D graphics.<br />
# For more info, look at http://arch-graphics.kx.cz/<br />
Server = http://arch-graphics.kx.cz/repo/i686<br />
<br />
[cgr-i686]<br />
# Packages for some ChicoGeek's PKGBUILDs.<br />
Server = http://cgr.i686.googlepages.com/<br />
<br />
[chaox-stable]<br />
# Pentesting packages and custom kernel patched for WIFI injection.<br />
Server = http://repo.chaox.net/stable<br />
<br />
[compiz-fusion]<br />
# compiz-fusion-git<br />
# Updated to June 2008.<br />
Server = http://compiz.dreamz-box.de/i686<br />
<br />
[cinan]<br />
# Contains packages which aren't in official repos.<br />
# Information at cinan.tk or cinan6.tk<br />
Server = http://cinan.yw.sk/i686<br />
<br />
[dragonlord]<br />
# Mixed packages, I don't want to move into [community],<br />
# but are worth having them or the build time is long.<br />
Server = http://repo.dragonlord.cz/arch/i686<br />
<br />
[esclinux]<br />
# Mostly games, interactive fiction and abc notation stuffs already on AUR.<br />
Server = http://download.tuxfamily.org/esclinuxcd/ressources/repo/i686/<br />
<br />
[fukawi]<br />
# Some Nagios Stuff; molly-guard; celtx and various networking tools.<br />
Server = http://repo.fukawi2.nl/i686/<br />
Server = ftp://repo.fukawi2.nl/i686/<br />
<br />
[jose1711repo]<br />
# Most of the packages I maintain in AUR (games, tools)<br />
Server = http://arch.l33t.in/i686/<br />
<br />
[kpiche]<br />
# Stable OpenSync packages.<br />
Server = http://kpiche.archlinux.ca/repo<br />
<br />
[pst]<br />
# Painters Studio and support packages (http://pst.brankovukelic.com/).<br />
Server = http://pst.brankovukelic.com/i686<br />
<br />
[rfad]<br />
# Repository made by haxit | Contact at: requiem [at] archlinux.us for package suggestions!<br />
Server = http://web.ncf.ca/ey723/archlinux/repo/<br />
<br />
[xdemon-repo]<br />
# madwimax, kismet-svn and aircrack-svn, etc...<br />
Server=http://repo.x-demon.org/archlinux/os/i686<br />
<br />
[nightly]<br />
# Nightly builds of some packages from the AUR.<br />
# Repo-Tracker: http://tracker.kromonos.net/projects/show/nightlyarch<br />
Server = http://nightly.uhuc.de/i686<br />
<br />
[pozitpoh]<br />
# Fresh psi-plus, kvirc4, urtconnector, xneur, etc.<br />
Server = http://pozitpoh.is-a-geek.org/repo/i686<br />
<br />
[herecura-stable]<br />
# Additional apps not found in community.<br />
Server = http://herecura.be/repo/herecura-stable/i686<br />
<br />
[herecura-testing]<br />
# Additional apps for testing build against stable Arch.<br />
Server = http://herecura.be/repo/herecura-testing/i686<br />
<br />
[studioidefix]<br />
# Precompiled boxee packages.<br />
Server = http://studioidefix.googlecode.com/hg/repo/i686<br />
<br />
[mingw32]<br />
# Libs & tools for crosscompiling for Win32, mainly taken from AUR.<br />
# Contact: Alexander 'hatred' Drozdov <adrozdoff [at] gmail (dot) com> (Russian-speaked guys can write on Russian :-)<br />
Server = http://hatred.homelinux.net/archlinux/mingw32/os/i686<br />
<br />
[jrepo]<br />
# Random pkgs for my friends low-end and old laptop.<br />
# These pkgs are optimzed for pentium-m (i686 + sse2).<br />
# All pks that support pulseaudio have been natively complied to include it.<br />
# http://dl.dropbox.com/u/3422289/README list of pkgs and info<br />
Server = http://dl.dropbox.com/u/3422289<br />
<br />
[kernel-panic]<br />
# A various set of useful packages, including (but not limited to) opera, falconpl and kpackagekit<br />
Server = http://kernel-panic.dnsdojo.net/arch/i686<br />
<br />
[ayatana]<br />
# Packages from Ubuntu (humanity-icon-theme, ttf-ubuntu, ubuntu-light-themes, ubuntuone-client, indicator-applet, notify-osd…),<br />
# packages from elementary project (dexter, elementary-icon-theme, gloobus-preview, gnome-theme-elementary, postler…),<br />
# packages from Linux Mint (gnome-theme-mint, mintbackup, mintdesktop, mint-icon-theme, mintmenu…) and<br />
# apps with ayatana support (audio-recorder, banshee-community-extensions, cloudsn, gwibber, pino, sbackup, smuxi…),<br />
# extra GNOME apps (conduit, eog-plugins, glabels, gnome-color-manager, gnome-globalmenu, gnome-subtitles, ontv, pdfmod, rygel, postr, tasque…),<br />
# mapping apps (bt747, emerillon, foxtrotgps, gpx-viewer, merkaartor, navit, prune…),<br />
# some other apps (backintime, connman, faenza-icon-theme, gdesklets, keepnote, kompozer, nautilus-terminal, openbve, pinta, textflow, uget…).<br />
# More info: http://arch.ballogyorgy.com/<br />
Server = http://repo.ayatana.info/<br />
</pre><br />
<br />
===x86_64 only===<br />
<pre><br />
[kde4-eyecandy-64]<br />
# Useful and beautiful plasmoids and themes for KDE4.<br />
Server = http://archlinuxgr.tiven.org/kde4-eyecandy/x86_64/<br />
<br />
[adslgr64]<br />
# The Hellenic (Greek) archlinux unofficial repository with many interesting packages.<br />
Server = http://archlinuxgr.tiven.org/archlinux/x86_64/<br />
<br />
[andrwe]<br />
# For a list of packages see: http://andrwe.dyndns.org/doku.php/blog/repository<br />
Server = http://repo.andrwe.org/x86_64<br />
<br />
[archlinux-es]<br />
# Repositorio Hispano (Spanish/Hispanic Respository).<br />
Server = http://repo.archlinux-es.org/x86_64<br />
<br />
[archlinuxve]<br />
# Home of the splashy packages.<br />
Server = http://repo.archlinux.com.ve/x86_64<br />
<br />
[archstudio]<br />
# ArchAudio Packages <br />
# Optimized for Intel Core {i3,i5,i7} CPU <br />
# Package Details: http://dl.dropbox.com/u/5977716/archstudio.html<br />
Server = http://dl.dropbox.com/u/5977716/x86_64<br />
<br />
[compiz-fusion]<br />
# compiz-fusion-git<br />
Server = http://compiz.dreamz-box.de/x86_64<br />
<br />
[cinan]<br />
# Contains packages which aren't in official repos.<br />
# Information at cinan.tk or cinan6.tk<br />
Server = http://cinan.yw.sk/x86_64<br />
<br />
[pst]<br />
# Painters Studio and support packages (http://pst.brankovukelic.com/)<br />
Server = http://pst.brankovukelic.com/x86_64<br />
<br />
[dstr-repo]<br />
# qutim, psi, kdevelop with plugins dev builds and other stuff.<br />
Server = http://dimon.homeftp.org/repo/x86_64<br />
<br />
[nightly]<br />
# Nightly builds of some packages from the AUR.<br />
# Repo-Tracker: http://tracker.kromonos.net/projects/show/nightlyarch<br />
Server = http://files.shadowice.org/nightly/x86_64<br />
<br />
[zen]<br />
# Various and zengeist' AUR packages.<br />
Server = http://zloduch.cz/archlinux/x86_64<br />
<br />
[digitalpioneer]<br />
# Recent GIT/SVN/whatever builds of selected AUR packages.<br />
# List of packages is at http://dl.getdropbox.com/u/453116/repo/pkglist and is subject to change.<br />
# x86_64 only.<br />
Server = http://dl.getdropbox.com/u/453116/repo<br />
<br />
[seiichiro]<br />
# VDR and some plugins, mms, foo2zjs-drivers<br />
Server = http://repo.seiichiro0185.org/x86_64<br />
<br />
[herecura-stable]<br />
# Additional apps not found in community.<br />
Server = http://herecura.be/repo/herecura-stable/x86_64<br />
<br />
[herecura-testing]<br />
# Additional apps for testing build against stable Arch.<br />
Server = http://herecura.be/repo/herecura-testing/x86_64<br />
<br />
[studioidefix]<br />
# Precompiled boxee packages.<br />
Server = http://studioidefix.googlecode.com/hg/repo/x86_64<br />
<br />
[pyropeter]<br />
# My AUR packages: http://aur.archlinux.org/packages.php?SeB=m&K=pyropeter<br />
Server = http://keks.selfip.org/arch/pyropeter<br />
</pre><br />
<br />
==Add your own repository to this list==<br />
If you have your own repository, please add this to this list, so that all other users knows where to find your packages.</div>Jnguyenhttps://wiki.archlinux.org/index.php?title=TOMOYO_Linux&diff=137112TOMOYO Linux2011-04-13T07:55:14Z<p>Jnguyen: /* Installation */</p>
<hr />
<div>[[Category:Security (English)]]<br />
[[Category:Kernel (English)]]<br />
[[Category:Networking (English)]]<br />
[[Category:HOWTOs (English)]]<br />
[http://tomoyo.sourceforge.jp/ TOMOYO Linux] is Mandatory Access Control (MAC) implementation for Linux. It was launched in March 2003 and is sponsored by [http://www.nttdata.co.jp/en/ NTT Data Corporation]. TOMOYO Linux focuses on the behaviour of a system, allowing each process to declare behaviours and resources needed to achieve its purpose. It can be used as a system analysis tool as well as an access restriction tool.<br />
<br />
The security goal of TOMOYO Linux is to provide "MAC that covers practical requirements for most users and keeps usable for most administrators". TOMOYO Linux is not a tool or security professional but for average users and administrators.<br />
{{Note|This article does not aim to be an exhaustive guide and should be used as a supplement to the extensive [http://tomoyo.sourceforge.jp/documentation.html user documentation] provided by the project.}}<br />
{{Tip|[[#TOMOYO Linux Repository|Pre-built binaries]] for all TOMOYO Linux packages are available, including patched versions of kernel26. AKARI is a Linux Kernel Module so is useful for custom kernels like kernel26-ck and kernel26-pf. TOMOYO Linux 2.x branch is already integrated into the mainline kernel and is the easiest of the three to set up, but it only offers a subset of functionality at the present time.}}<br />
<br />
==Introduction==<br />
TOMOYO Linux attempts to make the system where everything is prearranged in an easy to understand way:<br />
* Make all access requests that will occur at least once during the lifetime of the kernel known in advance<br />
* Allow the administrator to write a policy that only allows expected and desirable access requests<br />
Unlike AppArmor, TOMOYO Linux is intended to protect the whole system from attackers exploiting vulnerabilities in applications. TOMOYO Linux addresses this threat by recording the behaviour of all applications in the test environment and then forcing all applications to act within these recorded behaviours in the production environment.<br />
<br />
TOMOYO Linux is not for users wanting ready-made policy files supplied by others. It involves creating policy from scratch, aided by the "learning mode" which can automatically generate policy files with necessary and sufficient permissions for a specific system. TOMOYO Linux reports what is happening within the Linux system and can therefore be used as a system analysis tool. It resembles strace and reports what is being executed by each program and what files/networks are accessed.<br />
<br />
This [http://tomoyo.sourceforge.jp/wiki-e/?WhatIs#comparison table] provides a comprehensive comparison of TOMOYO Linux with [[AppArmor]], [[SELinux]] and [http://schaufler-ca.com/ SMACK].<br />
<br />
==Branches of development==<br />
[http://tomoyo.sourceforge.jp/1.8/index.html.en TOMOYO Linux 1.x] is the original branch of development. TOMOYO Linux was first released on 11th November 2005. It was implemented as a patch that can be applied to the Linux kernel and is still in active development. It can coexist with other security modules such as SELinux, SMACK and AppArmor.<br />
<br />
[http://tomoyo.sourceforge.jp/2.3/index.html.en TOMOYO Linux 2.x] is the Linux mainline kernel branch of development. In June 2009, TOMOYO was merged into the Linux kernel version 2.6.30 and it uses standard Linux Security Module (LSM) hooks. However, the LSM hooks must be extended further in order to port the full MAC functionality of TOMOYO Linux into the Linux kernel. Thus, it does not yet provide equal functionality with the 1.x branch of development. This [http://tomoyo.sourceforge.jp/comparison.html.en chart] compares the differences between each branch.<br />
<br />
[http://akari.sourceforge.jp/ AKARI] is based on the TOMOYO Linux 1.x branch and is implemented as a Loadable Kernel Module (LKM). It therefore has the advantage of not requiring the user to patch and recompile the kernel. This [http://akari.sourceforge.jp/comparison.html table] provides a comprehensive comparison of AKARI with the TOMOYO Linux 1.x and 2.x branches.<br />
<br />
==TOMOYO Linux Repository==<br />
'''This repository has temporarily been taken down for reasons listed [https://bbs.archlinux.org/viewtopic.php?pid=917720#p917720 here].'''<br />
<br />
<br />
An [[Unofficial_User_Repositories|unofficial user repository]] has been made available that has all the necessary packages, including patched versions of kernel26 for both i686 and x86_64. The repository can be browsed at [http://repo.tomoyolinux.co.uk repo.tomoyolinux.co.uk]. Add the following to the bottom of "/etc/pacman.conf":<br />
<br />
<pre><br />
[tomoyo]<br />
Server = http://repo.tomoyolinux.co.uk/archlinux/$arch<br />
</pre><br />
<br />
To view the packages in the repository, run the following:<br />
<br />
<pre><br />
pacman -Sl tomoyo<br />
</pre><br />
<br />
Forum thread can be found [https://bbs.archlinux.org/viewtopic.php?id=114075 here].<br />
<br />
==TOMOYO Linux 1.x==<br />
Implementing TOMOYO Linux 1.x using a kernel patched with ccs-patch provides the full functionality obtainable from the TOMOYO Linux project. However, implementation of this branch requires the most hurdles to be overcome, as the kernel must be patched with [http://sourceforge.jp/projects/tomoyo/ ccs-patch] and subsequently recompiled.<br />
<br />
Both kernel26-ccs and the userspace tools must be installed. A package for [http://aur.archlinux.org/packages.php?ID=44131 kernel-ccs] and a package for [http://aur.archlinux.org/packages.php?ID=42606 ccs-tools] are available on the AUR.<br />
<br />
Binary packages are available in the [[#TOMOYO Linux Repository|[tomoyo] repository]].<br />
<br />
===Initializing configuration===<br />
The policy must first be initialized:<br />
# /usr/lib/ccs/init_policy<br />
The policy files are saved in the /etc/css/ directory and can be edited by running:<br />
# ccs-editpolicy<br />
<br />
==AKARI==<br />
===Limitations of AKARI===<br />
AKARI has the advantage of not requiring kernel recompilation. If using the TOMOYO Linux project purely for system analysis, then AKARI is the easiest method of achieving this. If using the TOMOYO Linux project for system restriction, it is a minimal effort way to gain most of the functionality of the TOMOYO Linux 1.x branch. However, there are a few limitations that must be considered:<br />
* It depends on the kernel version and configuration provided by the distribution:<br />
<pre><br />
CONFIG_SECURITY=y [required]<br />
CONFIG_KALLSYMS=y [required]<br />
CONFIG_PROC_FS=y [required]<br />
CONFIG_MODULES=y [required]<br />
CONFIG_SECURITY_PATH=y [optional: for using absolute pathnames]<br />
CONFIG_SECURITY_NETWORK=y [optional: for providing network restriction]<br />
</pre><br />
* The restriction of a few advanced networking operations are limited or unavailable due to the absence of required LSM hooks<br />
* Restricting use of [http://en.wikipedia.org/wiki/Capability-based_security capabilities] is not possible<br />
* Looking up per-task variables is slower as they are managed outside "struct task_struct" in order to keep KABI unchanged. However, this should not be noticeable for the typical end-user as performance decrease by pathname based permission checking is dominant<br />
This [http://akari.sourceforge.jp/comparison.html table] provides a comprehensive comparison of AKARI with the TOMOYO Linux 1.x and 2.x branches.<br />
<br />
{{Note|The Arch Linux kernel from 2.6.36 onwards provides all of the configuration options required for full functionality.}}<br />
<br />
===Installation===<br />
Both AKARI and the userspace tools must be installed. A package for [http://aur.archlinux.org/packages.php?ID=42608 AKARI] and a package for [http://aur.archlinux.org/packages.php?ID=42606 ccs-tools] are available on the AUR.<br />
<br />
The bootloader configuration must be changed in order to activate AKARI:<br />
title Arch Linux<br />
root (hd0,0)<br />
kernel /boot/vmlinuz26 root=/dev/sda1 ro init=/sbin/ccs-init<br />
initrd /boot/kernel26.img<br />
<br />
Binary packages are available in the [[#TOMOYO Linux Repository|[tomoyo] repository]].<br />
<br />
===Initializing configuration===<br />
The policy must first be initialized:<br />
# /usr/lib/ccs/init_policy --module_name=akari<br />
The policy files are saved in the /etc/css/ directory and can be edited by running:<br />
# ccs-editpolicy<br />
<br />
==TOMOYO Linux 2.x==<br />
===Limitations of TOMOYO Linux 2.x===<br />
The implementation of TOMOYO Linux 2.x into the Linux mainline kernel is not yet complete but is still effective for MAC of files. It does not yet support the restriction of:<br />
* file attribute and namespace manipulation<br />
* capabilities<br />
* network<br />
* signal<br />
* environment variables<br />
* local port reservation<br />
This [http://tomoyo.sourceforge.jp/comparison.html.en chart] has a more comprehensive comparison of the differences between each branch of development.<br />
<br />
===Installation===<br />
TOMOYO Linux 2.x is part of the Linux mainline kernel and, in addition to those previously mentioned, requires the following kernel configuration:<br />
CONFIG_SECURITY_TOMOYO=y<br />
{{note|The Arch Linux kernel from 2.6.36 onwards provides all of the configuration options required for full functionality.}}<br />
<br />
If the kernel supports TOMOYO Linux 2.x, then only the userspace tools need to be installed:<br />
<br />
<pre><br />
pacman -S tomoyo-tools<br />
</pre><br />
<br />
For kernel versions between 2.6.30 and 2.6.35, tomoyo-tools 2.2.x should be installed. A package is available on the [http://aur.archlinux.org/packages.php?ID=42272 AUR]<br />
<br />
===Initializing configuration===<br />
The policy must first be initialized:<br />
# /usr/lib/tomoyo/init_policy<br />
The policy files are saved in the /etc/tomoyo/ directory and can be edited by running:<br />
# tomoyo-editpolicy<br />
<br />
==Usage==<br />
It is important to consult the relevant documentation in order to use TOMOYO Linux or AKARI effectively:<br />
* [http://tomoyo.sourceforge.jp/documentation.html.en TOMOYO Linux documentation]<br />
* [http://akari.sourceforge.jp/index.html.en AKARI documentation]<br />
Run the policy editor to begin editing. If using TOMOYO Linux 1.x or AKARI then ccs-tools should be used:<br />
# /usr/sbin/ccs-editpolicy<br />
If using TOMOYO Linux 2.x then tomoyo-tools should be used:<br />
# /usr/sbin/tomoyo-editpolicy<br />
As the system runs, TOMOYO Linux will create domains and add them to the tree. The access analysis/restriction in TOMOYO Linux is applied via domains. Every process belongs to a single domain and the process will transit to a different domain whenever it executes a program. The name of a domain is a concatenated string expression for the process execution history. For example, the name of the domain which the kernel belongs to is "<kernel>"; the name of domain which /sbin/init invoked by the kernel belongs to is "<kernel> /sbin/init"; if /sbin/init invokes /etc/rc.d/rc then the domain it belongs to is "<kernel> /sbin/init /etc/rc.d/rc". You can suppress or initialize domain transitions as needed.<br />
<br />
Profiles can be assigned to each domain. There are four default profiles:<br />
<br />
{| border="1"<br />
| Disabled || Works as if regular kernel.<br />
|-<br />
| Learning || Do not reject an access request if it violates policy. Append the request to policy.<br />
|-<br />
| Permissive || Do not reject an access request if it violates policy. Do not append the request to policy.<br />
|-<br />
| Enforcing || Reject an access request if it violates policy. Do not append the request to policy.<br />
|}<br />
The learning profile can be used to analyse the system or a specific application. Once all of the desired access requests of a domain have been identified, the policy for that domain can be edited as required before selecting the enforcing profile. This can be done for any and all domains from the start of system boot.<br />
<br />
==References==<br />
* [http://tomomyo.sourceforge.jp/ TOMOYO Linux SourceForge page]<br />
* [http://tomoyo.sourceforge.jp/wiki-e/ TOMOYO Linux Wiki]<br />
* [http://akari.sourceforge.jp/index.html.en AKARI SourceForge page]<br />
* [http://akari.sourceforge.jp/index.html.en AKARI documentation]<br />
* [http://tomoyo.sourceforge.jp/1.8/index.html.en TOMOYO Linux 1.8.x documentation]<br />
* [http://tomoyo.sourceforge.jp/2.3/index.html.en TOMOYO Linux 2.3.x documentation]<br />
* [http://lwn.net/Articles/263179/ TOMOYO Linux Security Goal]<br />
* [http://tomoyo.sourceforge.jp/cgi-bin/lxr/source/centos5.5/domain_policy.conf?v=policy-sample Policy sample]<br />
* [http://elinux.org/TomoyoLinux TOMOYO Linux on the Embedded Linux Wiki]<br />
* [http://sourceforge.jp/projects/tomoyo/document/PacSec2007-en-demo.pdf Presentation slides from PacSec 2007]<br />
<br />
==See also==<br />
* [[AppArmor]]<br />
* [[SELinux]]</div>Jnguyenhttps://wiki.archlinux.org/index.php?title=TOMOYO_Linux&diff=137078TOMOYO Linux2011-04-12T18:26:24Z<p>Jnguyen: /* TOMOYO Linux Repository */</p>
<hr />
<div>[[Category:Security (English)]]<br />
[[Category:Kernel (English)]]<br />
[[Category:Networking (English)]]<br />
[[Category:HOWTOs (English)]]<br />
[http://tomoyo.sourceforge.jp/ TOMOYO Linux] is Mandatory Access Control (MAC) implementation for Linux. It was launched in March 2003 and is sponsored by [http://www.nttdata.co.jp/en/ NTT Data Corporation]. TOMOYO Linux focuses on the behaviour of a system, allowing each process to declare behaviours and resources needed to achieve its purpose. It can be used as a system analysis tool as well as an access restriction tool.<br />
<br />
The security goal of TOMOYO Linux is to provide "MAC that covers practical requirements for most users and keeps usable for most administrators". TOMOYO Linux is not a tool or security professional but for average users and administrators.<br />
{{Note|This article does not aim to be an exhaustive guide and should be used as a supplement to the extensive [http://tomoyo.sourceforge.jp/documentation.html user documentation] provided by the project.}}<br />
{{Tip|[[#TOMOYO Linux Repository|Pre-built binaries]] for all TOMOYO Linux packages are available, including patched versions of kernel26. AKARI is a Linux Kernel Module so is useful for custom kernels like kernel26-ck and kernel26-pf. TOMOYO Linux 2.x branch is already integrated into the mainline kernel and is the easiest of the three to set up, but it only offers a subset of functionality at the present time.}}<br />
<br />
==Introduction==<br />
TOMOYO Linux attempts to make the system where everything is prearranged in an easy to understand way:<br />
* Make all access requests that will occur at least once during the lifetime of the kernel known in advance<br />
* Allow the administrator to write a policy that only allows expected and desirable access requests<br />
Unlike AppArmor, TOMOYO Linux is intended to protect the whole system from attackers exploiting vulnerabilities in applications. TOMOYO Linux addresses this threat by recording the behaviour of all applications in the test environment and then forcing all applications to act within these recorded behaviours in the production environment.<br />
<br />
TOMOYO Linux is not for users wanting ready-made policy files supplied by others. It involves creating policy from scratch, aided by the "learning mode" which can automatically generate policy files with necessary and sufficient permissions for a specific system. TOMOYO Linux reports what is happening within the Linux system and can therefore be used as a system analysis tool. It resembles strace and reports what is being executed by each program and what files/networks are accessed.<br />
<br />
This [http://tomoyo.sourceforge.jp/wiki-e/?WhatIs#comparison table] provides a comprehensive comparison of TOMOYO Linux with [[AppArmor]], [[SELinux]] and [http://schaufler-ca.com/ SMACK].<br />
<br />
==Branches of development==<br />
[http://tomoyo.sourceforge.jp/1.8/index.html.en TOMOYO Linux 1.x] is the original branch of development. TOMOYO Linux was first released on 11th November 2005. It was implemented as a patch that can be applied to the Linux kernel and is still in active development. It can coexist with other security modules such as SELinux, SMACK and AppArmor.<br />
<br />
[http://tomoyo.sourceforge.jp/2.3/index.html.en TOMOYO Linux 2.x] is the Linux mainline kernel branch of development. In June 2009, TOMOYO was merged into the Linux kernel version 2.6.30 and it uses standard Linux Security Module (LSM) hooks. However, the LSM hooks must be extended further in order to port the full MAC functionality of TOMOYO Linux into the Linux kernel. Thus, it does not yet provide equal functionality with the 1.x branch of development. This [http://tomoyo.sourceforge.jp/comparison.html.en chart] compares the differences between each branch.<br />
<br />
[http://akari.sourceforge.jp/ AKARI] is based on the TOMOYO Linux 1.x branch and is implemented as a Loadable Kernel Module (LKM). It therefore has the advantage of not requiring the user to patch and recompile the kernel. This [http://akari.sourceforge.jp/comparison.html table] provides a comprehensive comparison of AKARI with the TOMOYO Linux 1.x and 2.x branches.<br />
<br />
==TOMOYO Linux Repository==<br />
'''This repository has temporarily been taken down for reasons listed [https://bbs.archlinux.org/viewtopic.php?pid=917720#p917720 here].'''<br />
<br />
<br />
An [[Unofficial_User_Repositories|unofficial user repository]] has been made available that has all the necessary packages, including patched versions of kernel26 for both i686 and x86_64. The repository can be browsed at [http://repo.tomoyolinux.co.uk repo.tomoyolinux.co.uk]. Add the following to the bottom of "/etc/pacman.conf":<br />
<br />
<pre><br />
[tomoyo]<br />
Server = http://repo.tomoyolinux.co.uk/archlinux/$arch<br />
</pre><br />
<br />
To view the packages in the repository, run the following:<br />
<br />
<pre><br />
pacman -Sl tomoyo<br />
</pre><br />
<br />
Forum thread can be found [https://bbs.archlinux.org/viewtopic.php?id=114075 here].<br />
<br />
==TOMOYO Linux 1.x==<br />
Implementing TOMOYO Linux 1.x using a kernel patched with ccs-patch provides the full functionality obtainable from the TOMOYO Linux project. However, implementation of this branch requires the most hurdles to be overcome, as the kernel must be patched with [http://sourceforge.jp/projects/tomoyo/ ccs-patch] and subsequently recompiled.<br />
<br />
Both kernel26-ccs and the userspace tools must be installed. A package for [http://aur.archlinux.org/packages.php?ID=44131 kernel-ccs] and a package for [http://aur.archlinux.org/packages.php?ID=42606 ccs-tools] are available on the AUR.<br />
<br />
Binary packages are available in the [[#TOMOYO Linux Repository|[tomoyo] repository]].<br />
<br />
===Initializing configuration===<br />
The policy must first be initialized:<br />
# /usr/lib/ccs/init_policy<br />
The policy files are saved in the /etc/css/ directory and can be edited by running:<br />
# ccs-editpolicy<br />
<br />
==AKARI==<br />
===Limitations of AKARI===<br />
AKARI has the advantage of not requiring kernel recompilation. If using the TOMOYO Linux project purely for system analysis, then AKARI is the easiest method of achieving this. If using the TOMOYO Linux project for system restriction, it is a minimal effort way to gain most of the functionality of the TOMOYO Linux 1.x branch. However, there are a few limitations that must be considered:<br />
* It depends on the kernel version and configuration provided by the distribution:<br />
<pre><br />
CONFIG_SECURITY=y [required]<br />
CONFIG_KALLSYMS=y [required]<br />
CONFIG_PROC_FS=y [required]<br />
CONFIG_MODULES=y [required]<br />
CONFIG_SECURITY_PATH=y [optional: for using absolute pathnames]<br />
CONFIG_SECURITY_NETWORK=y [optional: for providing network restriction]<br />
</pre><br />
* The restriction of a few advanced networking operations are limited or unavailable due to the absence of required LSM hooks<br />
* Restricting use of [http://en.wikipedia.org/wiki/Capability-based_security capabilities] is not possible<br />
* Looking up per-task variables is slower as they are managed outside "struct task_struct" in order to keep KABI unchanged. However, this should not be noticeable for the typical end-user as performance decrease by pathname based permission checking is dominant<br />
This [http://akari.sourceforge.jp/comparison.html table] provides a comprehensive comparison of AKARI with the TOMOYO Linux 1.x and 2.x branches.<br />
<br />
{{Note|The Arch Linux kernel from 2.6.36 onwards provides all of the configuration options required for full functionality.}}<br />
<br />
===Installation===<br />
Both AKARI and the userspace tools must be installed. A package for [http://aur.archlinux.org/packages.php?ID=42608 AKARI] and a package for [http://aur.archlinux.org/packages.php?ID=42606 ccs-tools] are available on the AUR.<br />
<br />
The bootloader configuration must be changed in order to activate AKARI:<br />
title Arch Linux<br />
root (hd0,0)<br />
kernel /boot/vmlinuz26 root=/dev/sda1 ro init=/sbin/ccs-init<br />
initrd /boot/kernel26.img<br />
<br />
Binary packages are available in the [[#TOMOYO Linux Repository|[tomoyo] repository]].<br />
<br />
===Initializing configuration===<br />
The policy must first be initialized:<br />
# /usr/lib/ccs/init_policy --module_name=akari<br />
The policy files are saved in the /etc/css/ directory and can be edited by running:<br />
# ccs-editpolicy<br />
<br />
==TOMOYO Linux 2.x==<br />
===Limitations of TOMOYO Linux 2.x===<br />
The implementation of TOMOYO Linux 2.x into the Linux mainline kernel is not yet complete but is still effective for MAC of files. It does not yet support the restriction of:<br />
* file attribute and namespace manipulation<br />
* capabilities<br />
* network<br />
* signal<br />
* environment variables<br />
* local port reservation<br />
This [http://tomoyo.sourceforge.jp/comparison.html.en chart] has a more comprehensive comparison of the differences between each branch of development.<br />
<br />
===Installation===<br />
TOMOYO Linux 2.x is part of the Linux mainline kernel and, in addition to those previously mentioned, requires the following kernel configuration:<br />
CONFIG_SECURITY_TOMOYO=y<br />
{{note|The Arch Linux kernel from 2.6.36 onwards provides all of the configuration options required for full functionality.}}<br />
<br />
If the kernel supports TOMOYO Linux 2.x, then only the userspace tools need to be installed. <br />
* For kernel versions between 2.6.30 and 2.6.35, tomoyo-tools 2.2.x should be installed. A package is available on the [http://aur.archlinux.org/packages.php?ID=42272 AUR]<br />
* For kernel versions 2.6.36 and above, tomoyo-tools 2.3.x should be installed. A package is available on the [http://aur.archlinux.org/packages.php?ID=39931 AUR]<br />
<br />
Binary packages are available in the [[#TOMOYO Linux Repository|[tomoyo] repository]].<br />
<br />
===Initializing configuration===<br />
The policy must first be initialized:<br />
# /usr/lib/tomoyo/init_policy<br />
The policy files are saved in the /etc/tomoyo/ directory and can be edited by running:<br />
# tomoyo-editpolicy<br />
<br />
==Usage==<br />
It is important to consult the relevant documentation in order to use TOMOYO Linux or AKARI effectively:<br />
* [http://tomoyo.sourceforge.jp/documentation.html.en TOMOYO Linux documentation]<br />
* [http://akari.sourceforge.jp/index.html.en AKARI documentation]<br />
Run the policy editor to begin editing. If using TOMOYO Linux 1.x or AKARI then ccs-tools should be used:<br />
# /usr/sbin/ccs-editpolicy<br />
If using TOMOYO Linux 2.x then tomoyo-tools should be used:<br />
# /usr/sbin/tomoyo-editpolicy<br />
As the system runs, TOMOYO Linux will create domains and add them to the tree. The access analysis/restriction in TOMOYO Linux is applied via domains. Every process belongs to a single domain and the process will transit to a different domain whenever it executes a program. The name of a domain is a concatenated string expression for the process execution history. For example, the name of the domain which the kernel belongs to is "<kernel>"; the name of domain which /sbin/init invoked by the kernel belongs to is "<kernel> /sbin/init"; if /sbin/init invokes /etc/rc.d/rc then the domain it belongs to is "<kernel> /sbin/init /etc/rc.d/rc". You can suppress or initialize domain transitions as needed.<br />
<br />
Profiles can be assigned to each domain. There are four default profiles:<br />
<br />
{| border="1"<br />
| Disabled || Works as if regular kernel.<br />
|-<br />
| Learning || Do not reject an access request if it violates policy. Append the request to policy.<br />
|-<br />
| Permissive || Do not reject an access request if it violates policy. Do not append the request to policy.<br />
|-<br />
| Enforcing || Reject an access request if it violates policy. Do not append the request to policy.<br />
|}<br />
The learning profile can be used to analyse the system or a specific application. Once all of the desired access requests of a domain have been identified, the policy for that domain can be edited as required before selecting the enforcing profile. This can be done for any and all domains from the start of system boot.<br />
<br />
==References==<br />
* [http://tomomyo.sourceforge.jp/ TOMOYO Linux SourceForge page]<br />
* [http://tomoyo.sourceforge.jp/wiki-e/ TOMOYO Linux Wiki]<br />
* [http://akari.sourceforge.jp/index.html.en AKARI SourceForge page]<br />
* [http://akari.sourceforge.jp/index.html.en AKARI documentation]<br />
* [http://tomoyo.sourceforge.jp/1.8/index.html.en TOMOYO Linux 1.8.x documentation]<br />
* [http://tomoyo.sourceforge.jp/2.3/index.html.en TOMOYO Linux 2.3.x documentation]<br />
* [http://lwn.net/Articles/263179/ TOMOYO Linux Security Goal]<br />
* [http://tomoyo.sourceforge.jp/cgi-bin/lxr/source/centos5.5/domain_policy.conf?v=policy-sample Policy sample]<br />
* [http://elinux.org/TomoyoLinux TOMOYO Linux on the Embedded Linux Wiki]<br />
* [http://sourceforge.jp/projects/tomoyo/document/PacSec2007-en-demo.pdf Presentation slides from PacSec 2007]<br />
<br />
==See also==<br />
* [[AppArmor]]<br />
* [[SELinux]]</div>Jnguyenhttps://wiki.archlinux.org/index.php?title=TOMOYO_Linux&diff=137001TOMOYO Linux2011-04-12T06:23:51Z<p>Jnguyen: /* Usage */ amend documentation links</p>
<hr />
<div>[[Category:Security (English)]]<br />
[[Category:Kernel (English)]]<br />
[[Category:Networking (English)]]<br />
[[Category:HOWTOs (English)]]<br />
[http://tomoyo.sourceforge.jp/ TOMOYO Linux] is Mandatory Access Control (MAC) implementation for Linux. It was launched in March 2003 and is sponsored by [http://www.nttdata.co.jp/en/ NTT Data Corporation]. TOMOYO Linux focuses on the behaviour of a system, allowing each process to declare behaviours and resources needed to achieve its purpose. It can be used as a system analysis tool as well as an access restriction tool.<br />
<br />
The security goal of TOMOYO Linux is to provide "MAC that covers practical requirements for most users and keeps usable for most administrators". TOMOYO Linux is not a tool or security professional but for average users and administrators.<br />
{{Note|This article does not aim to be an exhaustive guide and should be used as a supplement to the extensive [http://tomoyo.sourceforge.jp/documentation.html user documentation] provided by the project.}}<br />
{{Tip|[[#TOMOYO Linux Repository|Pre-built binaries]] for all TOMOYO Linux packages are available, including patched versions of kernel26. AKARI is a Linux Kernel Module so is useful for custom kernels like kernel26-ck and kernel26-pf. TOMOYO Linux 2.x branch is already integrated into the mainline kernel and is the easiest of the three to set up, but it only offers a subset of functionality at the present time.}}<br />
<br />
==Introduction==<br />
TOMOYO Linux attempts to make the system where everything is prearranged in an easy to understand way:<br />
* Make all access requests that will occur at least once during the lifetime of the kernel known in advance<br />
* Allow the administrator to write a policy that only allows expected and desirable access requests<br />
Unlike AppArmor, TOMOYO Linux is intended to protect the whole system from attackers exploiting vulnerabilities in applications. TOMOYO Linux addresses this threat by recording the behaviour of all applications in the test environment and then forcing all applications to act within these recorded behaviours in the production environment.<br />
<br />
TOMOYO Linux is not for users wanting ready-made policy files supplied by others. It involves creating policy from scratch, aided by the "learning mode" which can automatically generate policy files with necessary and sufficient permissions for a specific system. TOMOYO Linux reports what is happening within the Linux system and can therefore be used as a system analysis tool. It resembles strace and reports what is being executed by each program and what files/networks are accessed.<br />
<br />
This [http://tomoyo.sourceforge.jp/wiki-e/?WhatIs#comparison table] provides a comprehensive comparison of TOMOYO Linux with [[AppArmor]], [[SELinux]] and [http://schaufler-ca.com/ SMACK].<br />
<br />
==Branches of development==<br />
[http://tomoyo.sourceforge.jp/1.8/index.html.en TOMOYO Linux 1.x] is the original branch of development. TOMOYO Linux was first released on 11th November 2005. It was implemented as a patch that can be applied to the Linux kernel and is still in active development. It can coexist with other security modules such as SELinux, SMACK and AppArmor.<br />
<br />
[http://tomoyo.sourceforge.jp/2.3/index.html.en TOMOYO Linux 2.x] is the Linux mainline kernel branch of development. In June 2009, TOMOYO was merged into the Linux kernel version 2.6.30 and it uses standard Linux Security Module (LSM) hooks. However, the LSM hooks must be extended further in order to port the full MAC functionality of TOMOYO Linux into the Linux kernel. Thus, it does not yet provide equal functionality with the 1.x branch of development. This [http://tomoyo.sourceforge.jp/comparison.html.en chart] compares the differences between each branch.<br />
<br />
[http://akari.sourceforge.jp/ AKARI] is based on the TOMOYO Linux 1.x branch and is implemented as a Loadable Kernel Module (LKM). It therefore has the advantage of not requiring the user to patch and recompile the kernel. This [http://akari.sourceforge.jp/comparison.html table] provides a comprehensive comparison of AKARI with the TOMOYO Linux 1.x and 2.x branches.<br />
<br />
==TOMOYO Linux Repository==<br />
An [[Unofficial_User_Repositories|unofficial user repository]] has been made available that has all the necessary packages, including patched versions of kernel26 for both i686 and x86_64. The repository can be browsed at [http://repo.tomoyolinux.co.uk repo.tomoyolinux.co.uk]. Add the following to the bottom of "/etc/pacman.conf":<br />
<br />
<pre><br />
[tomoyo]<br />
Server = http://repo.tomoyolinux.co.uk/archlinux/$arch<br />
</pre><br />
<br />
To view the packages in the repository, run the following:<br />
<br />
<pre><br />
pacman -Sl tomoyo<br />
</pre><br />
<br />
Forum thread can be found [https://bbs.archlinux.org/viewtopic.php?id=114075 here].<br />
<br />
==TOMOYO Linux 1.x==<br />
Implementing TOMOYO Linux 1.x using a kernel patched with ccs-patch provides the full functionality obtainable from the TOMOYO Linux project. However, implementation of this branch requires the most hurdles to be overcome, as the kernel must be patched with [http://sourceforge.jp/projects/tomoyo/ ccs-patch] and subsequently recompiled.<br />
<br />
Both kernel26-ccs and the userspace tools must be installed. A package for [http://aur.archlinux.org/packages.php?ID=44131 kernel-ccs] and a package for [http://aur.archlinux.org/packages.php?ID=42606 ccs-tools] are available on the AUR.<br />
<br />
Binary packages are available in the [[#TOMOYO Linux Repository|[tomoyo] repository]].<br />
<br />
===Initializing configuration===<br />
The policy must first be initialized:<br />
# /usr/lib/ccs/init_policy<br />
The policy files are saved in the /etc/css/ directory and can be edited by running:<br />
# ccs-editpolicy<br />
<br />
==AKARI==<br />
===Limitations of AKARI===<br />
AKARI has the advantage of not requiring kernel recompilation. If using the TOMOYO Linux project purely for system analysis, then AKARI is the easiest method of achieving this. If using the TOMOYO Linux project for system restriction, it is a minimal effort way to gain most of the functionality of the TOMOYO Linux 1.x branch. However, there are a few limitations that must be considered:<br />
* It depends on the kernel version and configuration provided by the distribution:<br />
<pre><br />
CONFIG_SECURITY=y [required]<br />
CONFIG_KALLSYMS=y [required]<br />
CONFIG_PROC_FS=y [required]<br />
CONFIG_MODULES=y [required]<br />
CONFIG_SECURITY_PATH=y [optional: for using absolute pathnames]<br />
CONFIG_SECURITY_NETWORK=y [optional: for providing network restriction]<br />
</pre><br />
* The restriction of a few advanced networking operations are limited or unavailable due to the absence of required LSM hooks<br />
* Restricting use of [http://en.wikipedia.org/wiki/Capability-based_security capabilities] is not possible<br />
* Looking up per-task variables is slower as they are managed outside "struct task_struct" in order to keep KABI unchanged. However, this should not be noticeable for the typical end-user as performance decrease by pathname based permission checking is dominant<br />
This [http://akari.sourceforge.jp/comparison.html table] provides a comprehensive comparison of AKARI with the TOMOYO Linux 1.x and 2.x branches.<br />
<br />
{{Note|The Arch Linux kernel from 2.6.36 onwards provides all of the configuration options required for full functionality.}}<br />
<br />
===Installation===<br />
Both AKARI and the userspace tools must be installed. A package for [http://aur.archlinux.org/packages.php?ID=42608 AKARI] and a package for [http://aur.archlinux.org/packages.php?ID=42606 ccs-tools] are available on the AUR.<br />
<br />
The bootloader configuration must be changed in order to activate AKARI:<br />
title Arch Linux<br />
root (hd0,0)<br />
kernel /boot/vmlinuz26 root=/dev/sda1 ro init=/sbin/ccs-init<br />
initrd /boot/kernel26.img<br />
<br />
Binary packages are available in the [[#TOMOYO Linux Repository|[tomoyo] repository]].<br />
<br />
===Initializing configuration===<br />
The policy must first be initialized:<br />
# /usr/lib/ccs/init_policy --module_name=akari<br />
The policy files are saved in the /etc/css/ directory and can be edited by running:<br />
# ccs-editpolicy<br />
<br />
==TOMOYO Linux 2.x==<br />
===Limitations of TOMOYO Linux 2.x===<br />
The implementation of TOMOYO Linux 2.x into the Linux mainline kernel is not yet complete but is still effective for MAC of files. It does not yet support the restriction of:<br />
* file attribute and namespace manipulation<br />
* capabilities<br />
* network<br />
* signal<br />
* environment variables<br />
* local port reservation<br />
This [http://tomoyo.sourceforge.jp/comparison.html.en chart] has a more comprehensive comparison of the differences between each branch of development.<br />
<br />
===Installation===<br />
TOMOYO Linux 2.x is part of the Linux mainline kernel and, in addition to those previously mentioned, requires the following kernel configuration:<br />
CONFIG_SECURITY_TOMOYO=y<br />
{{note|The Arch Linux kernel from 2.6.36 onwards provides all of the configuration options required for full functionality.}}<br />
<br />
If the kernel supports TOMOYO Linux 2.x, then only the userspace tools need to be installed. <br />
* For kernel versions between 2.6.30 and 2.6.35, tomoyo-tools 2.2.x should be installed. A package is available on the [http://aur.archlinux.org/packages.php?ID=42272 AUR]<br />
* For kernel versions 2.6.36 and above, tomoyo-tools 2.3.x should be installed. A package is available on the [http://aur.archlinux.org/packages.php?ID=39931 AUR]<br />
<br />
Binary packages are available in the [[#TOMOYO Linux Repository|[tomoyo] repository]].<br />
<br />
===Initializing configuration===<br />
The policy must first be initialized:<br />
# /usr/lib/tomoyo/init_policy<br />
The policy files are saved in the /etc/tomoyo/ directory and can be edited by running:<br />
# tomoyo-editpolicy<br />
<br />
==Usage==<br />
It is important to consult the relevant documentation in order to use TOMOYO Linux or AKARI effectively:<br />
* [http://tomoyo.sourceforge.jp/documentation.html.en TOMOYO Linux documentation]<br />
* [http://akari.sourceforge.jp/index.html.en AKARI documentation]<br />
Run the policy editor to begin editing. If using TOMOYO Linux 1.x or AKARI then ccs-tools should be used:<br />
# /usr/sbin/ccs-editpolicy<br />
If using TOMOYO Linux 2.x then tomoyo-tools should be used:<br />
# /usr/sbin/tomoyo-editpolicy<br />
As the system runs, TOMOYO Linux will create domains and add them to the tree. The access analysis/restriction in TOMOYO Linux is applied via domains. Every process belongs to a single domain and the process will transit to a different domain whenever it executes a program. The name of a domain is a concatenated string expression for the process execution history. For example, the name of the domain which the kernel belongs to is "<kernel>"; the name of domain which /sbin/init invoked by the kernel belongs to is "<kernel> /sbin/init"; if /sbin/init invokes /etc/rc.d/rc then the domain it belongs to is "<kernel> /sbin/init /etc/rc.d/rc". You can suppress or initialize domain transitions as needed.<br />
<br />
Profiles can be assigned to each domain. There are four default profiles:<br />
<br />
{| border="1"<br />
| Disabled || Works as if regular kernel.<br />
|-<br />
| Learning || Do not reject an access request if it violates policy. Append the request to policy.<br />
|-<br />
| Permissive || Do not reject an access request if it violates policy. Do not append the request to policy.<br />
|-<br />
| Enforcing || Reject an access request if it violates policy. Do not append the request to policy.<br />
|}<br />
The learning profile can be used to analyse the system or a specific application. Once all of the desired access requests of a domain have been identified, the policy for that domain can be edited as required before selecting the enforcing profile. This can be done for any and all domains from the start of system boot.<br />
<br />
==References==<br />
* [http://tomomyo.sourceforge.jp/ TOMOYO Linux SourceForge page]<br />
* [http://tomoyo.sourceforge.jp/wiki-e/ TOMOYO Linux Wiki]<br />
* [http://akari.sourceforge.jp/index.html.en AKARI SourceForge page]<br />
* [http://akari.sourceforge.jp/index.html.en AKARI documentation]<br />
* [http://tomoyo.sourceforge.jp/1.8/index.html.en TOMOYO Linux 1.8.x documentation]<br />
* [http://tomoyo.sourceforge.jp/2.3/index.html.en TOMOYO Linux 2.3.x documentation]<br />
* [http://lwn.net/Articles/263179/ TOMOYO Linux Security Goal]<br />
* [http://tomoyo.sourceforge.jp/cgi-bin/lxr/source/centos5.5/domain_policy.conf?v=policy-sample Policy sample]<br />
* [http://elinux.org/TomoyoLinux TOMOYO Linux on the Embedded Linux Wiki]<br />
* [http://sourceforge.jp/projects/tomoyo/document/PacSec2007-en-demo.pdf Presentation slides from PacSec 2007]<br />
<br />
==See also==<br />
* [[AppArmor]]<br />
* [[SELinux]]</div>Jnguyenhttps://wiki.archlinux.org/index.php?title=TOMOYO_Linux&diff=136978TOMOYO Linux2011-04-11T22:59:18Z<p>Jnguyen: Amend [tomoyo] repository information</p>
<hr />
<div>[[Category:Security (English)]]<br />
[[Category:Kernel (English)]]<br />
[[Category:Networking (English)]]<br />
[[Category:HOWTOs (English)]]<br />
[http://tomoyo.sourceforge.jp/ TOMOYO Linux] is Mandatory Access Control (MAC) implementation for Linux. It was launched in March 2003 and is sponsored by [http://www.nttdata.co.jp/en/ NTT Data Corporation]. TOMOYO Linux focuses on the behaviour of a system, allowing each process to declare behaviours and resources needed to achieve its purpose. It can be used as a system analysis tool as well as an access restriction tool.<br />
<br />
The security goal of TOMOYO Linux is to provide "MAC that covers practical requirements for most users and keeps usable for most administrators". TOMOYO Linux is not a tool or security professional but for average users and administrators.<br />
{{Note|This article does not aim to be an exhaustive guide and should be used as a supplement to the extensive [http://tomoyo.sourceforge.jp/documentation.html user documentation] provided by the project.}}<br />
{{Tip|[[#TOMOYO Linux Repository|Pre-built binaries]] for all TOMOYO Linux packages are available, including patched versions of kernel26. AKARI is a Linux Kernel Module so is useful for custom kernels like kernel26-ck and kernel26-pf. TOMOYO Linux 2.x branch is already integrated into the mainline kernel and is the easiest of the three to set up, but it only offers a subset of functionality at the present time.}}<br />
<br />
==Introduction==<br />
TOMOYO Linux attempts to make the system where everything is prearranged in an easy to understand way:<br />
* Make all access requests that will occur at least once during the lifetime of the kernel known in advance<br />
* Allow the administrator to write a policy that only allows expected and desirable access requests<br />
Unlike AppArmor, TOMOYO Linux is intended to protect the whole system from attackers exploiting vulnerabilities in applications. TOMOYO Linux addresses this threat by recording the behaviour of all applications in the test environment and then forcing all applications to act within these recorded behaviours in the production environment.<br />
<br />
TOMOYO Linux is not for users wanting ready-made policy files supplied by others. It involves creating policy from scratch, aided by the "learning mode" which can automatically generate policy files with necessary and sufficient permissions for a specific system. TOMOYO Linux reports what is happening within the Linux system and can therefore be used as a system analysis tool. It resembles strace and reports what is being executed by each program and what files/networks are accessed.<br />
<br />
This [http://tomoyo.sourceforge.jp/wiki-e/?WhatIs#comparison table] provides a comprehensive comparison of TOMOYO Linux with [[AppArmor]], [[SELinux]] and [http://schaufler-ca.com/ SMACK].<br />
<br />
==Branches of development==<br />
[http://tomoyo.sourceforge.jp/1.8/index.html.en TOMOYO Linux 1.x] is the original branch of development. TOMOYO Linux was first released on 11th November 2005. It was implemented as a patch that can be applied to the Linux kernel and is still in active development. It can coexist with other security modules such as SELinux, SMACK and AppArmor.<br />
<br />
[http://tomoyo.sourceforge.jp/2.3/index.html.en TOMOYO Linux 2.x] is the Linux mainline kernel branch of development. In June 2009, TOMOYO was merged into the Linux kernel version 2.6.30 and it uses standard Linux Security Module (LSM) hooks. However, the LSM hooks must be extended further in order to port the full MAC functionality of TOMOYO Linux into the Linux kernel. Thus, it does not yet provide equal functionality with the 1.x branch of development. This [http://tomoyo.sourceforge.jp/comparison.html.en chart] compares the differences between each branch.<br />
<br />
[http://akari.sourceforge.jp/ AKARI] is based on the TOMOYO Linux 1.x branch and is implemented as a Loadable Kernel Module (LKM). It therefore has the advantage of not requiring the user to patch and recompile the kernel. This [http://akari.sourceforge.jp/comparison.html table] provides a comprehensive comparison of AKARI with the TOMOYO Linux 1.x and 2.x branches.<br />
<br />
==TOMOYO Linux Repository==<br />
An [[Unofficial_User_Repositories|unofficial user repository]] has been made available that has all the necessary packages, including patched versions of kernel26 for both i686 and x86_64. The repository can be browsed at [http://repo.tomoyolinux.co.uk repo.tomoyolinux.co.uk]. Add the following to the bottom of "/etc/pacman.conf":<br />
<br />
<pre><br />
[tomoyo]<br />
Server = http://repo.tomoyolinux.co.uk/archlinux/$arch<br />
</pre><br />
<br />
To view the packages in the repository, run the following:<br />
<br />
<pre><br />
pacman -Sl tomoyo<br />
</pre><br />
<br />
Forum thread can be found [https://bbs.archlinux.org/viewtopic.php?id=114075 here].<br />
<br />
==TOMOYO Linux 1.x==<br />
Implementing TOMOYO Linux 1.x using a kernel patched with ccs-patch provides the full functionality obtainable from the TOMOYO Linux project. However, implementation of this branch requires the most hurdles to be overcome, as the kernel must be patched with [http://sourceforge.jp/projects/tomoyo/ ccs-patch] and subsequently recompiled.<br />
<br />
Both kernel26-ccs and the userspace tools must be installed. A package for [http://aur.archlinux.org/packages.php?ID=44131 kernel-ccs] and a package for [http://aur.archlinux.org/packages.php?ID=42606 ccs-tools] are available on the AUR.<br />
<br />
Binary packages are available in the [[#TOMOYO Linux Repository|[tomoyo] repository]].<br />
<br />
===Initializing configuration===<br />
The policy must first be initialized:<br />
# /usr/lib/ccs/init_policy<br />
The policy files are saved in the /etc/css/ directory and can be edited by running:<br />
# ccs-editpolicy<br />
<br />
==AKARI==<br />
===Limitations of AKARI===<br />
AKARI has the advantage of not requiring kernel recompilation. If using the TOMOYO Linux project purely for system analysis, then AKARI is the easiest method of achieving this. If using the TOMOYO Linux project for system restriction, it is a minimal effort way to gain most of the functionality of the TOMOYO Linux 1.x branch. However, there are a few limitations that must be considered:<br />
* It depends on the kernel version and configuration provided by the distribution:<br />
<pre><br />
CONFIG_SECURITY=y [required]<br />
CONFIG_KALLSYMS=y [required]<br />
CONFIG_PROC_FS=y [required]<br />
CONFIG_MODULES=y [required]<br />
CONFIG_SECURITY_PATH=y [optional: for using absolute pathnames]<br />
CONFIG_SECURITY_NETWORK=y [optional: for providing network restriction]<br />
</pre><br />
* The restriction of a few advanced networking operations are limited or unavailable due to the absence of required LSM hooks<br />
* Restricting use of [http://en.wikipedia.org/wiki/Capability-based_security capabilities] is not possible<br />
* Looking up per-task variables is slower as they are managed outside "struct task_struct" in order to keep KABI unchanged. However, this should not be noticeable for the typical end-user as performance decrease by pathname based permission checking is dominant<br />
This [http://akari.sourceforge.jp/comparison.html table] provides a comprehensive comparison of AKARI with the TOMOYO Linux 1.x and 2.x branches.<br />
<br />
{{Note|The Arch Linux kernel from 2.6.36 onwards provides all of the configuration options required for full functionality.}}<br />
<br />
===Installation===<br />
Both AKARI and the userspace tools must be installed. A package for [http://aur.archlinux.org/packages.php?ID=42608 AKARI] and a package for [http://aur.archlinux.org/packages.php?ID=42606 ccs-tools] are available on the AUR.<br />
<br />
The bootloader configuration must be changed in order to activate AKARI:<br />
title Arch Linux<br />
root (hd0,0)<br />
kernel /boot/vmlinuz26 root=/dev/sda1 ro init=/sbin/ccs-init<br />
initrd /boot/kernel26.img<br />
<br />
Binary packages are available in the [[#TOMOYO Linux Repository|[tomoyo] repository]].<br />
<br />
===Initializing configuration===<br />
The policy must first be initialized:<br />
# /usr/lib/ccs/init_policy --module_name=akari<br />
The policy files are saved in the /etc/css/ directory and can be edited by running:<br />
# ccs-editpolicy<br />
<br />
==TOMOYO Linux 2.x==<br />
===Limitations of TOMOYO Linux 2.x===<br />
The implementation of TOMOYO Linux 2.x into the Linux mainline kernel is not yet complete but is still effective for MAC of files. It does not yet support the restriction of:<br />
* file attribute and namespace manipulation<br />
* capabilities<br />
* network<br />
* signal<br />
* environment variables<br />
* local port reservation<br />
This [http://tomoyo.sourceforge.jp/comparison.html.en chart] has a more comprehensive comparison of the differences between each branch of development.<br />
<br />
===Installation===<br />
TOMOYO Linux 2.x is part of the Linux mainline kernel and, in addition to those previously mentioned, requires the following kernel configuration:<br />
CONFIG_SECURITY_TOMOYO=y<br />
{{note|The Arch Linux kernel from 2.6.36 onwards provides all of the configuration options required for full functionality.}}<br />
<br />
If the kernel supports TOMOYO Linux 2.x, then only the userspace tools need to be installed. <br />
* For kernel versions between 2.6.30 and 2.6.35, tomoyo-tools 2.2.x should be installed. A package is available on the [http://aur.archlinux.org/packages.php?ID=42272 AUR]<br />
* For kernel versions 2.6.36 and above, tomoyo-tools 2.3.x should be installed. A package is available on the [http://aur.archlinux.org/packages.php?ID=39931 AUR]<br />
<br />
Binary packages are available in the [[#TOMOYO Linux Repository|[tomoyo] repository]].<br />
<br />
===Initializing configuration===<br />
The policy must first be initialized:<br />
# /usr/lib/tomoyo/init_policy<br />
The policy files are saved in the /etc/tomoyo/ directory and can be edited by running:<br />
# tomoyo-editpolicy<br />
<br />
==Usage==<br />
It is important to consult the relevant documentation in order to use TOMOYO Linux or AKARI effectively:<br />
* [http://tomoyo.sourceforge.jp/documentation.html.en TOMOYO Linux documentation]<br />
* [http://tomoyo.sourceforge.jp/1.8-tmp 90% complete rewrite of 1.8.x documentation] (not yet officially announced)<br />
* [http://akari.sourceforge.jp/index.html.en AKARI documentation]<br />
Run the policy editor to begin editing. If using TOMOYO Linux 1.x or AKARI then ccs-tools should be used:<br />
# /usr/sbin/ccs-editpolicy<br />
If using TOMOYO Linux 2.x then tomoyo-tools should be used:<br />
# /usr/sbin/tomoyo-editpolicy<br />
As the system runs, TOMOYO Linux will create domains and add them to the tree. The access analysis/restriction in TOMOYO Linux is applied via domains. Every process belongs to a single domain and the process will transit to a different domain whenever it executes a program. The name of a domain is a concatenated string expression for the process execution history. For example, the name of the domain which the kernel belongs to is "<kernel>"; the name of domain which /sbin/init invoked by the kernel belongs to is "<kernel> /sbin/init"; if /sbin/init invokes /etc/rc.d/rc then the domain it belongs to is "<kernel> /sbin/init /etc/rc.d/rc". You can suppress or initialize domain transitions as needed.<br />
<br />
Profiles can be assigned to each domain. There are four default profiles:<br />
<br />
{| border="1"<br />
| Disabled || Works as if regular kernel.<br />
|-<br />
| Learning || Do not reject an access request if it violates policy. Append the request to policy.<br />
|-<br />
| Permissive || Do not reject an access request if it violates policy. Do not append the request to policy.<br />
|-<br />
| Enforcing || Reject an access request if it violates policy. Do not append the request to policy.<br />
|}<br />
The learning profile can be used to analyse the system or a specific application. Once all of the desired access requests of a domain have been identified, the policy for that domain can be edited as required before selecting the enforcing profile. This can be done for any and all domains from the start of system boot.<br />
<br />
==References==<br />
* [http://tomomyo.sourceforge.jp/ TOMOYO Linux SourceForge page]<br />
* [http://tomoyo.sourceforge.jp/wiki-e/ TOMOYO Linux Wiki]<br />
* [http://akari.sourceforge.jp/index.html.en AKARI SourceForge page]<br />
* [http://akari.sourceforge.jp/index.html.en AKARI documentation]<br />
* [http://tomoyo.sourceforge.jp/1.8/index.html.en TOMOYO Linux 1.8.x documentation]<br />
* [http://tomoyo.sourceforge.jp/2.3/index.html.en TOMOYO Linux 2.3.x documentation]<br />
* [http://lwn.net/Articles/263179/ TOMOYO Linux Security Goal]<br />
* [http://tomoyo.sourceforge.jp/cgi-bin/lxr/source/centos5.5/domain_policy.conf?v=policy-sample Policy sample]<br />
* [http://elinux.org/TomoyoLinux TOMOYO Linux on the Embedded Linux Wiki]<br />
* [http://sourceforge.jp/projects/tomoyo/document/PacSec2007-en-demo.pdf Presentation slides from PacSec 2007]<br />
<br />
==See also==<br />
* [[AppArmor]]<br />
* [[SELinux]]</div>Jnguyenhttps://wiki.archlinux.org/index.php?title=TOMOYO_Linux&diff=135692TOMOYO Linux2011-04-02T17:46:03Z<p>Jnguyen: /* TOMOYO Linux Repository */ correction of instructions for pacman.conf</p>
<hr />
<div>[[Category:Security (English)]]<br />
[[Category:Kernel (English)]]<br />
[[Category:Networking (English)]]<br />
[[Category:HOWTOs (English)]]<br />
[http://tomoyo.sourceforge.jp/ TOMOYO Linux] is Mandatory Access Control (MAC) implementation for Linux. It was launched in March 2003 and is sponsored by [http://www.nttdata.co.jp/en/ NTT Data Corporation]. TOMOYO Linux focuses on the behaviour of a system, allowing each process to declare behaviours and resources needed to achieve its purpose. It can be used as a system analysis tool as well as an access restriction tool.<br />
<br />
The security goal of TOMOYO Linux is to provide "MAC that covers practical requirements for most users and keeps usable for most administrators". TOMOYO Linux is not a tool or security professional but for average users and administrators.<br />
{{Note|This article does not aim to be an exhaustive guide and should be used as a supplement to the extensive [http://tomoyo.sourceforge.jp/documentation.html user documentation] provided by the project.}}<br />
{{Tip|[[#TOMOYO Linux Repository|Pre-built binaries]] for all TOMOYO Linux packages are available, including patched versions of kernel26 and kernel26-lts. AKARI is a Linux Kernel Module so is useful for custom kernels like kernel26-ck and kernel26-pf. TOMOYO Linux 2.x branch is already integrated into the mainline kernel and is the easiest of the three to set up, but it only offers a subset of functionality at the present time.}}<br />
<br />
==Introduction==<br />
TOMOYO Linux attempts to make the system where everything is prearranged in an easy to understand way:<br />
* Make all access requests that will occur at least once during the lifetime of the kernel known in advance<br />
* Allow the administrator to write a policy that only allows expected and desirable access requests<br />
Unlike AppArmor, TOMOYO Linux is intended to protect the whole system from attackers exploiting vulnerabilities in applications. TOMOYO Linux addresses this threat by recording the behaviour of all applications in the test environment and then forcing all applications to act within these recorded behaviours in the production environment.<br />
<br />
TOMOYO Linux is not for users wanting ready-made policy files supplied by others. It involves creating policy from scratch, aided by the "learning mode" which can automatically generate policy files with necessary and sufficient permissions for a specific system. TOMOYO Linux reports what is happening within the Linux system and can therefore be used as a system analysis tool. It resembles strace and reports what is being executed by each program and what files/networks are accessed.<br />
<br />
This [http://tomoyo.sourceforge.jp/wiki-e/?WhatIs#comparison table] provides a comprehensive comparison of TOMOYO Linux with [[AppArmor]], [[SELinux]] and [http://schaufler-ca.com/ SMACK].<br />
<br />
==Branches of development==<br />
[http://tomoyo.sourceforge.jp/1.8/index.html.en TOMOYO Linux 1.x] is the original branch of development. TOMOYO Linux was first released on 11th November 2005. It was implemented as a patch that can be applied to the Linux kernel and is still in active development. It can coexist with other security modules such as SELinux, SMACK and AppArmor.<br />
<br />
[http://tomoyo.sourceforge.jp/2.3/index.html.en TOMOYO Linux 2.x] is the Linux mainline kernel branch of development. In June 2009, TOMOYO was merged into the Linux kernel version 2.6.30 and it uses standard Linux Security Module (LSM) hooks. However, the LSM hooks must be extended further in order to port the full MAC functionality of TOMOYO Linux into the Linux kernel. Thus, it does not yet provide equal functionality with the 1.x branch of development. This [http://tomoyo.sourceforge.jp/comparison.html.en chart] compares the differences between each branch.<br />
<br />
[http://akari.sourceforge.jp/ AKARI] is based on the TOMOYO Linux 1.x branch and is implemented as a Loadable Kernel Module (LKM). It therefore has the advantage of not requiring the user to patch and recompile the kernel. This [http://akari.sourceforge.jp/comparison.html table] provides a comprehensive comparison of AKARI with the TOMOYO Linux 1.x and 2.x branches.<br />
<br />
==TOMOYO Linux Repository==<br />
An [[Unofficial_User_Repositories|unofficial user repository]] has been made available that has all the necessary packages, including patched versions of kernel26 and kernel26-lts for both i686 and x86_64. The repository can be browsed at [http://repo.tomoyolinux.co.uk repo.tomoyolinux.co.uk]. Add the following to the bottom of "/etc/pacman.conf":<br />
<br />
<pre><br />
[tomoyo]<br />
Server = http://repo.tomoyolinux.co.uk/archlinux/$arch<br />
</pre><br />
<br />
To view the packages in the repository, run the following:<br />
<br />
<pre><br />
pacman -Sl tomoyo<br />
</pre><br />
<br />
Forum thread can be found [https://bbs.archlinux.org/viewtopic.php?id=114075 here].<br />
<br />
==TOMOYO Linux 1.x==<br />
Implementing TOMOYO Linux 1.x using a kernel patched with ccs-patch provides the full functionality obtainable from the TOMOYO Linux project. However, implementation of this branch requires the most hurdles to be overcome, as the kernel must be patched with [http://sourceforge.jp/projects/tomoyo/ ccs-patch] and subsequently recompiled.<br />
<br />
Both kernel26-ccs and the userspace tools must be installed. A package for [http://aur.archlinux.org/packages.php?ID=44131 kernel-ccs] and a package for [http://aur.archlinux.org/packages.php?ID=42606 ccs-tools] are available on the AUR.<br />
<br />
Binary packages are available in the [[#TOMOYO Linux Repository|[tomoyo] repository]].<br />
<br />
===Initializing configuration===<br />
The policy must first be initialized:<br />
# /usr/lib/ccs/init_policy<br />
The policy files are saved in the /etc/css/ directory and can be edited by running:<br />
# ccs-editpolicy<br />
<br />
==AKARI==<br />
===Limitations of AKARI===<br />
AKARI has the advantage of not requiring kernel recompilation. If using the TOMOYO Linux project purely for system analysis, then AKARI is the easiest method of achieving this. If using the TOMOYO Linux project for system restriction, it is a minimal effort way to gain most of the functionality of the TOMOYO Linux 1.x branch. However, there are a few limitations that must be considered:<br />
* It depends on the kernel version and configuration provided by the distribution:<br />
<pre><br />
CONFIG_SECURITY=y [required]<br />
CONFIG_KALLSYMS=y [required]<br />
CONFIG_PROC_FS=y [required]<br />
CONFIG_MODULES=y [required]<br />
CONFIG_SECURITY_PATH=y [optional: for using absolute pathnames]<br />
CONFIG_SECURITY_NETWORK=y [optional: for providing network restriction]<br />
</pre><br />
* The restriction of a few advanced networking operations are limited or unavailable due to the absence of required LSM hooks<br />
* Restricting use of [http://en.wikipedia.org/wiki/Capability-based_security capabilities] is not possible<br />
* Looking up per-task variables is slower as they are managed outside "struct task_struct" in order to keep KABI unchanged. However, this should not be noticeable for the typical end-user as performance decrease by pathname based permission checking is dominant<br />
This [http://akari.sourceforge.jp/comparison.html table] provides a comprehensive comparison of AKARI with the TOMOYO Linux 1.x and 2.x branches.<br />
<br />
{{Note|The Arch Linux kernel from 2.6.36 onwards provides all of the configuration options required for full functionality.}}<br />
<br />
===Installation===<br />
Both AKARI and the userspace tools must be installed. A package for [http://aur.archlinux.org/packages.php?ID=42608 AKARI] and a package for [http://aur.archlinux.org/packages.php?ID=42606 ccs-tools] are available on the AUR.<br />
<br />
The bootloader configuration must be changed in order to activate AKARI:<br />
title Arch Linux<br />
root (hd0,0)<br />
kernel /boot/vmlinuz26 root=/dev/sda1 ro init=/sbin/ccs-init<br />
initrd /boot/kernel26.img<br />
<br />
Binary packages are available in the [[#TOMOYO Linux Repository|[tomoyo] repository]].<br />
<br />
===Initializing configuration===<br />
The policy must first be initialized:<br />
# /usr/lib/ccs/init_policy --module_name=akari<br />
The policy files are saved in the /etc/css/ directory and can be edited by running:<br />
# ccs-editpolicy<br />
<br />
==TOMOYO Linux 2.x==<br />
===Limitations of TOMOYO Linux 2.x===<br />
The implementation of TOMOYO Linux 2.x into the Linux mainline kernel is not yet complete but is still effective for MAC of files. It does not yet support the restriction of:<br />
* file attribute and namespace manipulation<br />
* capabilities<br />
* network<br />
* signal<br />
* environment variables<br />
* local port reservation<br />
This [http://tomoyo.sourceforge.jp/comparison.html.en chart] has a more comprehensive comparison of the differences between each branch of development.<br />
<br />
===Installation===<br />
TOMOYO Linux 2.x is part of the Linux mainline kernel and, in addition to those previously mentioned, requires the following kernel configuration:<br />
CONFIG_SECURITY_TOMOYO=y<br />
{{note|The Arch Linux kernel from 2.6.36 onwards provides all of the configuration options required for full functionality.}}<br />
<br />
If the kernel supports TOMOYO Linux 2.x, then only the userspace tools need to be installed. <br />
* For kernel versions between 2.6.30 and 2.6.35, tomoyo-tools 2.2.x should be installed. A package is available on the [http://aur.archlinux.org/packages.php?ID=42272 AUR]<br />
* For kernel versions 2.6.36 and above, tomoyo-tools 2.3.x should be installed. A package is available on the [http://aur.archlinux.org/packages.php?ID=39931 AUR]<br />
<br />
Binary packages are available in the [[#TOMOYO Linux Repository|[tomoyo] repository]].<br />
<br />
===Initializing configuration===<br />
The policy must first be initialized:<br />
# /usr/lib/tomoyo/init_policy<br />
The policy files are saved in the /etc/tomoyo/ directory and can be edited by running:<br />
# tomoyo-editpolicy<br />
<br />
==Usage==<br />
It is important to consult the relevant documentation in order to use TOMOYO Linux or AKARI effectively:<br />
* [http://tomoyo.sourceforge.jp/documentation.html.en TOMOYO Linux documentation]<br />
* [http://tomoyo.sourceforge.jp/1.8-tmp 90% complete rewrite of 1.8.x documentation] (not yet officially announced)<br />
* [http://akari.sourceforge.jp/index.html.en AKARI documentation]<br />
Run the policy editor to begin editing. If using TOMOYO Linux 1.x or AKARI then ccs-tools should be used:<br />
# /usr/sbin/ccs-editpolicy<br />
If using TOMOYO Linux 2.x then tomoyo-tools should be used:<br />
# /usr/sbin/tomoyo-editpolicy<br />
As the system runs, TOMOYO Linux will create domains and add them to the tree. The access analysis/restriction in TOMOYO Linux is applied via domains. Every process belongs to a single domain and the process will transit to a different domain whenever it executes a program. The name of a domain is a concatenated string expression for the process execution history. For example, the name of the domain which the kernel belongs to is "<kernel>"; the name of domain which /sbin/init invoked by the kernel belongs to is "<kernel> /sbin/init"; if /sbin/init invokes /etc/rc.d/rc then the domain it belongs to is "<kernel> /sbin/init /etc/rc.d/rc". You can suppress or initialize domain transitions as needed.<br />
<br />
Profiles can be assigned to each domain. There are four default profiles:<br />
<br />
{| border="1"<br />
| Disabled || Works as if regular kernel.<br />
|-<br />
| Learning || Do not reject an access request if it violates policy. Append the request to policy.<br />
|-<br />
| Permissive || Do not reject an access request if it violates policy. Do not append the request to policy.<br />
|-<br />
| Enforcing || Reject an access request if it violates policy. Do not append the request to policy.<br />
|}<br />
The learning profile can be used to analyse the system or a specific application. Once all of the desired access requests of a domain have been identified, the policy for that domain can be edited as required before selecting the enforcing profile. This can be done for any and all domains from the start of system boot.<br />
<br />
==References==<br />
* [http://tomomyo.sourceforge.jp/ TOMOYO Linux SourceForge page]<br />
* [http://tomoyo.sourceforge.jp/wiki-e/ TOMOYO Linux Wiki]<br />
* [http://akari.sourceforge.jp/index.html.en AKARI SourceForge page]<br />
* [http://akari.sourceforge.jp/index.html.en AKARI documentation]<br />
* [http://tomoyo.sourceforge.jp/1.8/index.html.en TOMOYO Linux 1.8.x documentation]<br />
* [http://tomoyo.sourceforge.jp/2.3/index.html.en TOMOYO Linux 2.3.x documentation]<br />
* [http://lwn.net/Articles/263179/ TOMOYO Linux Security Goal]<br />
* [http://tomoyo.sourceforge.jp/cgi-bin/lxr/source/centos5.5/domain_policy.conf?v=policy-sample Policy sample]<br />
* [http://elinux.org/TomoyoLinux TOMOYO Linux on the Embedded Linux Wiki]<br />
* [http://sourceforge.jp/projects/tomoyo/document/PacSec2007-en-demo.pdf Presentation slides from PacSec 2007]<br />
<br />
==See also==<br />
* [[AppArmor]]<br />
* [[SELinux]]</div>Jnguyenhttps://wiki.archlinux.org/index.php?title=Udiskie&diff=135067Udiskie2011-03-27T20:17:34Z<p>Jnguyen: /* Storage group */ policykit/consolekit authentication</p>
<hr />
<div>[[Category:Auto-mounting (English)]]<br />
Udiskie is an automatic disk mounting service using [http://www.archlinux.org/packages/?q=udisks udisks]. It can be used for mounting CDs, flash drives, and other media. It is simple to use and requires no configuration.<br />
<br />
==Installation==<br />
You can install Udiskie by using the [http://aur.archlinux.org/packages.php?ID=37279 udiskie] package that is found in the [[AUR]].<br />
<br />
Start the Udiskie service by adding<br />
<br />
udiskie &<br />
<br />
to your [[xinitrc]] file, before the [[window manager]] is loaded.<br />
<br />
Once Udiskie is running, all removable media will automatically be mounted under <code>/media</code> under a new directory that matches the device name.<br />
<br />
===Permissions===<br />
udiskie requires permission for the <code>org.freedesktop.udisks.filesystem-mount</code> action to be granted through PolicyKit. If you use a display manager that supports ConsoleKit this will be taken care of for you automatically. If you don't, you'll need to set up consolekit to work with startx/xinit or use the old storage group method.<br />
<br />
====Consolekit (recommended)====<br />
{{Note|You may have to start udiskie after your window manager is started. You may have to use the storage group method if your WM doesn't provide this functionality.}}<br />
<!-- if someone has a way to start udiskie after the wm is started as a child process, (sub-shell + sleep) won't work, put it here---><br />
<br />
Start your window manager or desktop environment with ck-launch-session, for example, an exec line in ~/.xinitrc:<br />
exec ck-launch-session awesome<br />
<br />
====Storage group====<br />
If it doesn't already exist, create the file <code>/etc/polkit-1/localauthority/50-local.d/10-udiskie.pkla</code> with these contents:<br />
[Local Users]<br />
Identity=unix-group:storage<br />
Action=org.freedesktop.udisks.*<br />
ResultAny=yes<br />
ResultInactive=no<br />
ResultActive=yes[/code]<br />
<br />
This example configuration allows any member of the <code>storage</code> group to mount and unmount disks with udiskie.<br />
<br />
== Unmounting ==<br />
Use the <code>udiskie-umount</code> command to unmount media. For example, for a device named "MY_USB_DRIVE":<br />
<br />
udiskie-umount /media/MY_USB_DRIVE<br />
<br />
Or, you can unmount all media with the command:<br />
<br />
udiskie-umount -a<br />
<br />
== Window Manager Menu Scripts ==<br />
<br />
For convenience, you can add a script to the menu in some window managers to allow for easy access and control of removable media.<br />
<br />
===Openbox===<br />
Here's an openbox menu script that offers a slight variation on the WindowMaker example below:<br />
<br />
<pre><br />
#!/bin/bash<br />
<br />
# An openbox menu for removable media (requires udiskie).<br />
#<br />
# This script will generate sub-menus for any device mounted<br />
# under /media. You can browse the device in a file manager or<br />
# unmount it.<br />
#<br />
# It will ignore the "cd", "dvd", and "fl" directories and the U3<br />
# containers found on some windows formatted drives<br />
#<br />
# By default, this script uses the rox file manager to browse the<br />
# media.<br />
<br />
DIR=$(cd $(dirname "$0") && pwd)<br />
SCRIPT=$(basename "$0")<br />
NOTIFY="notify-send"<br />
FM_CMD="rox"<br />
<br />
pipemenu() {<br />
<br />
cd /media<br />
echo '<openbox_pipe_menu>'<br />
<br />
for i in *<br />
do<br />
if [ "$i" != "*" ] && [[ ! "$i" =~ ^U3|cd|dvd|fl ]]; then<br />
echo "<item label=\"Browse $i\">"<br />
echo "<action name=\"Execute\">"<br />
echo "<execute>$FM_CMD /media/$i</execute>"<br />
echo "</action></item>"<br />
echo "<item label=\"Unmount $i\">"<br />
echo "<action name=\"Execute\">"<br />
echo "<execute>$DIR/$SCRIPT unmount /media/$i</execute>"<br />
echo "</action></item>"<br />
echo "<separator/>"<br />
fi<br />
done<br />
<br />
echo "<item label=\"Eject CD/DVD\">"<br />
echo "<action name=\"Execute\">"<br />
echo "<execute>eject -T</execute>"<br />
echo "</action></item>"<br />
<br />
echo "<item label=\"Remount all\">"<br />
echo "<action name=\"Execute\">"<br />
echo "<execute>$DIR/$SCRIPT remount</execute>"<br />
echo "</action></item>"<br />
<br />
echo "</openbox_pipe_menu>"<br />
}<br />
<br />
case $1 in <br />
unmount)<br />
udiskie-umount $2<br />
if mountpoint -q $2; then<br />
$NOTIFY "Failed to unmount $2"<br />
else<br />
$NOTIFY "Unmounted $2"<br />
fi<br />
;;<br />
remount)<br />
killall udiskie<br />
udiskie &<br />
$NOTIFY "Mounting removable media..."<br />
;;<br />
*)<br />
pipemenu<br />
;;<br />
esac<br />
</pre><br />
<br />
===Window Maker===<br />
Create a "Generated Submenu" entry in the root menu.<br />
<br />
<pre><br />
#!/bin/bash<br />
<br />
# For a Window Maker menu for removable media.<br />
#<br />
# This script will generate sub-menus for any device mounted<br />
# under /media. You can browse the device in a file manager or<br />
# unmount it.<br />
#<br />
# It will ignore the "cd", "dvd", and "fl" directories.<br />
#<br />
# It uses "emelFM2" file manager to browse the media.<br />
<br />
cd /media<br />
<br />
echo \"Media\" MENU<br />
<br />
for i in *<br />
do<br />
if ["$i" != "*" ] && [ "$i" != "cd" ] && [ "$i" != "dvd" ] && [ "$i" != "fl" ]<br />
then<br />
echo \"Browse $i\" EXEC \"emelfm2 -1 \'/media/$i\'\"<br />
fi<br />
done<br />
<br />
for i in *<br />
do<br />
if ["$i" != "*" ] && [ "$i" != "cd" ] && [ "$i" != "dvd" ] && [ "$i" != "fl" ]<br />
then<br />
echo \"Unmount $i\" EXEC \"udiskie-umount \'/media/$i\'\"<br />
fi<br />
done<br />
<br />
echo \"Eject Disc\" EXEC \"eject --traytoggle\"<br />
<br />
echo \"Media\" END<br />
</pre><br />
<br />
== Links ==<br />
* [http://bitbucket.org/byronclark/udiskie Udiskie Homepage]<br />
* [http://aur.archlinux.org/packages.php?ID=37279 Udiskie AUR package]</div>Jnguyenhttps://wiki.archlinux.org/index.php?title=Openbox&diff=133537Openbox2011-03-12T14:27:24Z<p>Jnguyen: /* Pipe menus */ obdevicemenu</p>
<hr />
<div>[[Category:Stacking WMs (English)]]<br />
[[Category:HOWTOs (English)]]<br />
{{i18n|Openbox}}<br />
<br />
Openbox is a lightweight and highly configurable window manager with extensive standards support. Its features are documented at the [http://openbox.org/ official website]. This article pertains to installing Openbox under Arch Linux.<br />
<br />
== Installation ==<br />
<br />
Openbox is available from the standard repositories:<br />
# pacman -S openbox<br />
<br />
After installation, you should copy the default configuration files '''{{Filename|rc.xml}}''', '''{{Filename|menu.xml}}''', and '''{{Filename|autostart.sh}}''' to ''{{Filename|~/.config/openbox}}'' :<br />
<br />
$ mkdir -p ~/.config/openbox<br />
$ cp /etc/xdg/openbox/{rc.xml,menu.xml,autostart.sh} ~/.config/openbox<br />
<br />
{{Note | Do this as a regular user, not as root.}}<br />
<br />
File '''{{Filename|rc.xml}}''' is the configuration file. It defines keyboard shortcuts, themes, virtual desktops, and more.<br />
<br />
File '''{{Filename|menu.xml}}''' defines the menu that appears when you click on the desktop. The default menu items are sparse and some are for applications you probably have not even installed. It's easy to modify your menu to suit your needs; see the [[#Menus|menus]] section below or visit the [http://openbox.org Openbox website].<br />
<br />
The default '''{{Filename|autostart.sh}}''' file defines several environment variables. You may wish to append commands to this script to launch a panel, install wallpaper, or something else. Details are in the [http://openbox.org/wiki/Help:Autostart Openbox Wiki].<br />
<br />
== Openbox as a stand-alone WM ==<br />
<br />
Openbox can be used as a stand-alone window manager (WM). This is usually simpler to install and configure than using Openbox with desktop environments. Running openbox alone may reduce your system's CPU and memory load.<br />
<br />
To run Openbox as a stand-alone window manager, append the following to '''{{Filename|~/.xinitrc}}''':<br />
exec openbox-session<br />
<br />
You may also start Openbox from the command shell (aka: text prompt) using '''xinit''':<br />
$ xinit /usr/bin/openbox-session<br />
<br />
If you used another window manager previously (such as Xfwm) and now Openbox won't start after logging out of X, try moving the autostart folder:<br />
mv ~/.config/autostart ~/.config/autostart-bak<br />
<br />
Using D-Bus or similar, use this instead:<br />
exec ck-launch-session openbox-session<br />
<br />
If you also use '''polkit''' and '''D-Bus''' (e.g. for auto-mount drivers in Nautilus/Gnome) use:<br />
exec ck-launch-session dbus-launch openbox-session<br />
<br />
{{Note | [http://www.archlinux.org/packages/extra/any/pyxdg/ pyxdg] is required for Openbox's xdg-autostart}}<br />
<br />
== Openbox as a WM for desktop environments ==<br />
<br />
Openbox can be used as a replacement window manager for full-fledged desktop environments. The method for deploying Openbox depends on the desktop environment.<br />
<br />
=== GNOME 2.24 and 2.26 ===<br />
Create {{Filename|/usr/share/applications/openbox.desktop}} with the following lines:<br />
[Desktop Entry]<br />
Type=Application<br />
Encoding=UTF-8<br />
Name=OpenBox<br />
Exec=openbox<br />
NoDisplay=true<br />
# name of loadable control center module<br />
X-GNOME-WMSettingsModule=openbox<br />
# name we put on the WM spec check window<br />
X-GNOME-WMName=OpenBox<br />
In gconf, set '''{{Codeline|/desktop/gnome/session/required_components/windowmanager}}''' to '''{{Codeline|openbox}}:'''<br />
$ gconftool-2 -s -t string /desktop/gnome/session/required_components/windowmanager openbox<br />
Finally, choose '''GNOME''' session from the GDM sessions menu.<br />
<br />
=== GNOME 2.26 Redux ===<br />
'''''If the previous guide for GNOME 2.24 fails:'''''<br />
<br />
If, when attempting to log into a "Gnome/Openbox" session -- and it consistently fails to start, try the following. This is one way of achieving your goal of using Openbox as the WM anytime you open a Gnome session:<br />
<br />
#Log into your Gnome-only session (it should still be using Metacity as its window manager).<br />
#Install Openbox if you have not done so already<br />
#Navigate your menus to ''System &rarr; Preferences &rarr; Startup Applications'' (possibly named 'Session' in older Gnome versions)<br />
#Open Startup Application, select '+ Add' and enter the text shown below. Omit the text after #.<br />
#Click the 'Add' button for the data entry window. Make sure the checkbox beside your new entry is selected.<br />
#Log out from your Gnome session and log back in<br />
#You should now be running openbox as your window manager.<br />
<br />
Name: Openbox Windox Manager # Can be changed<br />
Command: openbox --replace # Text should not be removed from this line, but possibly added to it<br />
Comment: Replaces metacity with openbox # Can be changed<br />
<br />
This creates a startup list entry which is executed by Gnome each time the user's session is started.<br />
<br />
=== GNOME 2.22 and prior ===<br />
# If you use GDM, select the "GNOME/Openbox" login option<br />
# If you use {{Codeline|startx}}, add {{Codeline|exec openbox-gnome-session}} to {{Filename|~/.xinitrc}}<br />
# From the shell:<br />
$ xinit /usr/bin/openbox-gnome-session<br />
<br />
=== KDE ===<br />
# If you use KDM, select the "KDE/Openbox" login option<br />
# If you use startx, add {{Codeline|exec openbox-kde-session}} to {{Filename|~/.xinitrc}}<br />
# From the shell:<br />
$ xinit /usr/bin/openbox-kde-session<br />
<br />
=== Xfce4 ===<br />
Log into a normal Xfce4 session. From your terminal, type:<br />
$ killall xfwm4 ; openbox & exit<br />
<br />
This kills xfwm4, runs Openbox, and closes the terminal. Log out, being sure to check the ''"Save session for future logins"'' box. On your next login, Xfce4 should use '''Openbox''' as its WM.<br />
<br />
To enable exiting from a session using ''xfce4-session,'' edit '''{{Filename|~/.config/openbox/menu.xml}}'''. If the file isn't there, copy it from {{Filename|/etc/xdg/openbox/}}. Look for the following entry:<br />
<item label="Exit Openbox"><br />
<action name="Exit"><br />
<prompt>yes</prompt><br />
</action><br />
</item><br />
<br />
Change it to:<br />
<item label="Exit Openbox"><br />
<action name="Execute"><br />
<prompt>yes</prompt><br />
<command>xfce4-session-logout</command><br />
</action><br />
</item><br />
<br />
Otherwise, choosing "Exit" from the root-menu causes Openbox to terminate its execution, leaving you with no window manager.<br />
<br />
If you have a problem changing virtual desktops with the mouse wheel skipping over desktops, edit '''{{Filename|~/.config/openbox/rc.xml}}'''. Move the ''mouse binds with...'' actions "DesktopPrevious" and "DesktopNext" from context ''Desktop'' to the context ''Root''. (You may need to create a definition for the ''Root'' context as well.)<br />
<br />
When using the Openbox root-menu instead of Xfce's menu, you may exit the Xfdesktop with this terminal command:<br />
$ xfdesktop --quit<br />
Xfdesktop manages the wallpaper and desktop icons, requiring you to use other utilities such as ROX for these functions.<br />
<br />
(When terminating Xfdesktop, the above issue with the virtual desktops is no longer a problem.)<br />
<br />
== Preferences ==<br />
<br />
There are two options for configuring Openbox preferences:<br />
<br />
=== Manual configuration ===<br />
To configure Openbox manually, edit '''{{Filename|~/.config/openbox/rc.xml}}''' with a text editor. The config file has comments throughout. More documentation is found in the [http://openbox.org/wiki/Help:Configuration Help:Configuration] article at the Openbox website.<br />
<br />
=== ObConf ===<br />
[http://openbox.org/wiki/ObConf:About ObConf] is an Openbox configuration tool. It is used to set most preferences such as themes, virtual desktops, window properties, and desktop margins.<br />
<br />
# pacman -S obconf<br />
<br />
ObConf cannot configure keyboard shortcuts and certain other features. For these features edit '''{{Filename|rc.xml}}''' manually.<br />
<br />
An alternative is [http://code.google.com/p/obkey/ ObKey], available in the [[AUR]].<br />
<br />
=== Application customization ===<br />
<br />
Openbox allows per-application customizations. This lets you define rules for a given program. For example:<br />
* Start your web browser on a specific virtual desktop.<br />
* Open your terminal program with no window decorations (window chrome).<br />
* Make your bit-torrent client open at a given screen position.<br />
<br />
Per-application settings are defined in '''{{Filename|~/.config/openbox/rc.xml}}.''' Instructions are in the file's comments. Details are found in the [http://openbox.org/wiki/Help:Applications Help:Applications] article at the official Openbox web site.<br />
<br />
== Menus ==<br />
<br />
The default Openbox menu includes a variety of menu items to get you started. Many of these items launch applications you don't want, haven't installed yet, or never intend to install. You'll surely want to customize '''{{Filename|menu.xml}}''' at some point. There are a number of ways to do so.<br />
<br />
=== Manual configuration of menus ===<br />
<br />
You can edit {{Filename|~/.config/openbox/menu.xml}} with a text editor. Many of the settings are self-explanatory. The article [http://openbox.org/wiki/Help:Menus Help:Menus] has extensive details.<br />
<br />
=== MenuMaker ===<br />
<br />
[http://menumaker.sourceforge.net/ MenuMaker] creates XML menus for several window managers including Openbox. MenuMaker searchs your computer for executable programs and creates a menu file from the result. It can be configured to exclude certain application types (GNOME, KDE, etc) if you desire.<br />
# pacman -S menumaker # Install MenuMaker from the repository<br />
<br />
Once installed, generate a menu file (named {{Filename|menu.xml}}) by running the program.<br />
$ mmaker -v OpenBox3 # Will not overwrite an existing menu file.<br />
$ mmaker -vf OpenBox3 # Force option permits overwriting the menu file.<br />
$ mmaker --help # See the full set of options for MenuMaker.<br />
<br />
MenuMaker creates a comprehensive {{Filename|menu.xml}}. You may edit this file by hand or regenerate it after installing software.<br />
<br />
=== Obmenu ===<br />
<br />
Obmenu is a menu editor for Openbox. This GUI application is the best choice for those who dislike editing XML code. Obmenu is available in the community repository:<br />
# pacman -S obmenu<br />
<br />
Once installed, run {{Codeline|obmenu}} then add and remove applications as desired.<br />
<br />
==== Obm-xdg ====<br />
<br />
<tt>obm-xdg</tt> is a command-line tool that comes with Obmenu. It generates a categorized sub-menu of installed GTK/GNOME applications.<br />
<br />
To use obm-xdg with other menus, add the following line to '''{{Filename|~/.config/openbox/menu.xml}}''':<br />
<menu execute="obm-xdg" id="xdg-menu" label="xdg"/><br />
<br />
Then add the following line under your 'root-menu' entry where you want to have the menu appear:<br />
<menu id="xdg-menu"/><br />
<br />
To use obm-xdg by itself create '''{{Filename|~/.config/openbox/menu.xml}}''' and add these lines:<br />
<openbox_menu><br />
<menu execute="obm-xdg" id="root-menu" label="apps"/><br />
</openbox_menu><br />
<br />
<br />
Then run {{Codeline|openbox --reconfigure}} to refresh the Openbox menu. You should now see a sub-menu labeled '''xdg''' in your menu.<br />
<br />
{{Note|If you do not have GNOME installed, you need to install package '''gnome-menus''' for obm-xdg.}}<br />
<br />
=== Python-based xdg menu script ===<br />
<br />
This script is found in Fedora's Openbox package. You have only to put the script somewhere and create a menu entry.<br />
<br />
Here is one submission: [http://pastebin.com/f2f827625 script]<br />
<br />
Here is the head: [http://pkgs.fedoraproject.org/gitweb/?p=openbox.git;f=xdg-menu;hb=HEAD latest script]<br />
<br />
Download the one you like (you'll likely want the head version). Place the file somewhere. I used ~/Documents/build/xdg-menu. Modify the menu entry later according to your file path.<br />
<br />
Open '''{{Filename|menu.xml}}''' with your text editor and add the following entry. Of course, you can modify the label as you see fit.<br />
<menu id="apps-menu" label="xdgmenu" execute="python /home/shiki/Documents/build/xdg-menu"/><br />
<br />
Save the file and run '''{{Codeline|openbox --reconfigure}}'''.<br />
<br />
=== Openbox menu generator ===<br />
<br />
Residing in the AUR as [http://aur.archlinux.org/packages.php?ID=27300 obmenugen-bin,] Openbox menu generator creates the menu file from *.desktop files. Obmenugen provides a text file which filters (hides) menu items using basic regex.<br />
$ obmenugen # Create a menu file<br />
$ openbox --reconfigure # To see the menu you generated<br />
<br />
=== Pipe menus ===<br />
<br />
Like other window managers, Openbox allows for scripts to dynamically build menus (menus on-the-fly). Examples are system monitors, media player controls, or weather monitors. Pipe menu script examples are found in the [http://openbox.org/wiki/Openbox:Pipemenus Openbox:Pipemenus] page at Openbox's site.<br />
<br />
User ''Xyne'' created a pipe menu file browser and user ''brisbin33'' created a pipe menu for scanning and connecting to wireless hot spots (using netcfg). Forum posts for these utilities are here: [http://bbs.archlinux.org/viewtopic.php?id=77197&p=1 file browser] and here: [http://bbs.archlinux.org/viewtopic.php?id=78290 wifi].<br />
<br />
User ''jnguyen'' created a pipe menu for managing removable devices using Udisks. The forum post is here: [https://bbs.archlinux.org/viewtopic.php?id=114702 obdevicemenu].<br />
<br />
== Startup programs ==<br />
<br />
Openbox supports running programs at startup. This is provided by command '''openbox-session'''.<br />
<br />
=== Enabling autostart ===<br />
<br />
There are two ways to enable autostart:<br />
# When using startx or xinit to begin a session, edit {{Filename|~/.xinitrc}}. Change the line that executes '''''openbox''''' to '''openbox-session'''.<br />
# When using GDM or KDM, selecting an ''Openbox'' session automatically runs the autostart script.<br />
<br />
=== Autostart script ===<br />
<br />
Openbox executes a user startup script located at {{Filename|~/.config/openbox/autostart.sh}}. This script is ''not'' created by default. In the absence of a user startup script, openbox executes the system startup script {{Filename|/etc/xdg/openbox/autostart.sh}}. The system script does not run when the user script is present.<br />
<br />
To create a personal startup script, copy the system script to your settings directory {{Filename|~/.config/openbox/}} and append your commands. This ensures your environment is properly configured.<br />
<br />
Full instructions are available from the [http://openbox.org/wiki/Help:Autostart Help:Autostart] article at the Openbox site.<br />
<br />
== Themes and appearance ==<br />
<br />
:{{Box YELLOW||The supplemental article '''[[Openbox_Themes_and_Apps|Openbox Themes and Apps]]''' has detailed information about changing Openbox's GUI.}}<br />
<br />
You probably installed a selection of Linux programs that were developed using different toolkits. Configuration settings for a given program may reside in an unexpected location.<br />
<br />
For example, the double-click setting used by [http://www.geany.org/ Geany] (an editor/IDE) is set within the file '''{{Filename|~/.gtkrc-2.0,}}''' not where you might expect in '''{{Filename|~/.config/openbox/rc.xml}}'''. Some visual aspects of Geany are set by .gtkrc-2.0 as well.<br />
<br />
Refer to the supplemental [[Openbox_Themes_and_Apps#Themes_and_appearance|Openbox Themes and Apps]] for visual theming information.<br />
<br />
=== Openbox themes ===<br />
<br />
Themes control the appearance of windows, titlebars, and buttons. They also control menu appearance and on-screen display (OSD). Additional themes are available from the standard repositories.<br />
# pacman -S openbox-themes<br />
<br />
=== Cursors, icons, wallpaper ===<br />
<br />
Please see [[Openbox_Themes_and_Apps#X11_Mouse_cursors|Openbox Themes and Apps]] for information on these GUI customizations.<br />
<br />
== Recommended programs ==<br />
:{{Box YELLOW||The supplemental wiki article '''[[Openbox_Themes_and_Apps#Recommended_programs|Openbox Themes and Apps]]''' has information on applications you may use with Openbox.<br>The article gives details about panels, trays, mixer controls, and other widgets used on a desktop interface.}}<br />
<br />
There is a list of [[Lightweight_Applications|Lightweight Applications]] in the wiki. Most of these work nicely with Openbox.<br />
<br />
=== Login managers ===<br />
<br />
[http://slim.berlios.de/ SLiM] is a graphical login manager. It works for standalone Openbox configurations. Refer to the [[SLiM]] wiki article for instructions.<br />
<br />
[http://qingy.sourceforge.net/ Qingy] is a light, highly-configurable graphical login manager. It supports login to either text console or X session. Qingy uses [http://www.directfb.org DirectFB]. Qingy does not start an X session unless you choose a session that uses X Windows. Read the Arch wiki article about [[Qingy|Qingy.]]<br />
<br />
=== Compositing the desktop view ===<br />
<br />
[[Xcompmgr]] is a compositing window manager capable of rendering drop shadows, fading, and window transparency for Openbox and other window managers.<br />
Note that xcompmgr is no longer being developed. Any problems are unlikely to be fixed. (For example, Xcompmgr has shown a problem with ''tint2 0.9'': systray icons have a tendency to become corrupted.)<br />
<br />
[[Cairo Compmgr]] is a versatile compositing window manager that uses [http://en.wikipedia.org/wiki/Cairo_(software) Cairo] for rendering. It is usually the better choice.<br />
<br />
=== Panels, trays, pagers ===<br />
<br />
Refer to the supplemental [[Openbox_Themes_and_Apps#Panels.2C_trays.2C_and_pagers|Openbox Themes and Apps]] to learn about these GUI embellishments for Openbox.<br />
<br />
=== File managers ===<br />
<br />
Two popular lightweight file managers are:<br />
* [[Thunar]]. Thunar supports auto-mount features and other plugins. <br />
* [http://rox.sourceforge.net ROX] (ROX provides desktop icons)<br />
# pacman -S thunar<br />
# pacman -S rox<br />
* [http://pcmanfm.sourceforge.net PCManFM]<br />
# pacman -S pcmanfm # PcManFM package also provides desktop icons.<br />
# pacman -S ntfs-3g # Allows PCManFM to access NTFS drives.<br />
<br />
More information is found at [[Openbox_Themes_and_Apps#File_managers|Openbox Themes and Apps]]. The supplemental article has further information about application launchers such as [http://sourceforge.net/projects/gmrun gmrun], clipboard managers, volume mixers, and more.<br />
<br />
== Tips and tricks ==<br />
<br />
=== File associations ===<br />
Because Openbox and the applications you use with it are not well-integrated you might run into the issues with your browser. Your browser may not know which program it is supposed to use for certain types of files.<br />
<br />
A package in the AUR called [http://aur.archlinux.org/packages.php?ID=23170 gnome-defaults-list] contains a list of file-types and programs specific to the Gnome desktop. The list is installed to {{Filename|/etc/gnome/defaults.list.}}<br />
<br />
Open this file with your text-editor. Now you can replace a given application with the name of the program of your choosing. For example, totem <=> vlc or eog <=> mirage. Save the file to {{Filename|~/.local/share/applications/defaults.list}}.<br />
<br />
Another way of setting file associations is to install package ''perl-file-mimeinfo'' from the repository and invoke '''mimeopen''' like this:<br />
mimeopen -d /path/to/file<br />
You are asked which application to use when opening /path/to/file:<br />
Please choose a default application for files of type text/plain<br />
1) notepad (wine-extension-txt)<br />
2) Leafpad (leafpad)<br />
3) OpenOffice.org Writer (writer)<br />
4) gVim (gvim)<br />
5) Other...<br />
Your answer becomes the default handler for that type of file. Mimeopen is installed as {{Filename|/usr/bin/perlbin/vendor/mimetype}}.<br />
<br />
=== Copy and paste ===<br />
<br />
From a terminal '''Ctrl+Insert''' for copy and '''Shift+Insert''' for paste.<br />
<br />
Also '''Ctrl+Shift+C''' for copy and '''mouse middle-click''' for paste (in terminals).<br />
<br />
Other applications most likely use the conventional keyboard shortcuts for copy and paste.<br />
<br />
=== Window transparency ===<br />
<br />
The program transset-df (virtually the same as ''transset'') is installed with pacman -S transset-df. With transset-df you can enable window-transparency on-the-fly.<br />
<br />
For instance by placing the following in {{Filename|~/.config/openbox/rc.xml}} you can have your mouse adjust window transparency by scrolling while hovering over the title bar (it is in the <mouse> section):<br />
<br />
<context name="Titlebar"><br />
. . .<br />
<mousebind button="Up" action="Click"><br />
<action name= "Execute" ><br />
<execute>transset-df -p .2 --inc </execute><br />
</action><br />
</mousebind><br />
<mousebind button="Down" action="Click"><br />
<action name= "Execute" ><br />
<execute>transset-df -p .2 --dec </execute><br />
</action><br />
</mousebind><br />
. . .<br />
</context><br />
It appears to work only when no additional actions are defined within the action group.<br />
<br />
=== Xprop values for applications ===<br />
If you use per-application settings frequently, you might find this bash alias handy:<br />
<br />
alias xp='xprop | grep "WM_WINDOW_ROLE\|WM_CLASS" && echo "WM_CLASS(STRING) = \"NAME\", \"CLASS\""'<br />
<br />
To use, run '''{{Codeline|xp}}''' and click on the running program that you'd like to define with per-app settings. The result displays only the info that Openbox requires, namely the WM_WINDOW_ROLE and WM_CLASS (name and class) values:<br />
<br />
[thayer@dublin:~] $ xp<br />
WM_WINDOW_ROLE(STRING) = "roster"<br />
WM_CLASS(STRING) = "gajim.py", "Gajim.py"<br />
WM_CLASS(STRING) = "NAME", "CLASS"<br />
<br />
==== Xprop for Firefox ====<br />
<br />
For whatever reason, Firefox and like-minded equivalents ignore application rules (e.g. <desktop>) unless {{Codeline|class&#61;"Firefox*"}} is used. This applies irrespective of whatever values xprop may report for the program's WM_CLASS.<br />
<br />
=== Linking the menu to a button ===<br />
<br />
Some people want to link the Openbox menu (or any menu) to an object. This is useful for creating a panel button to pop up a menu. Although Openbox does not provide this, a program called '''xdotool''' simulates a keypress. Openbox can be configured to bind that keypress to the ''ShowMenu'' action.<br />
<br />
Package [http://aur.archlinux.org/packages.php?do_Details=1&ID=14789&O=0&L=0&C=0&K=xdotool&SB=n&SO=a&PP=25&do_MyPackages=0&do_Orphans=0&SeB=nd xdotool] is available in the AUR. After installing ''xdotool'', add the following to the <keyboard> section of your '''{{Filename|rc.xml}}''':<br />
<keybind key="A-C-q"><br />
<action name="ShowMenu"><br />
<menu>root-menu</menu><br />
</action><br />
</keybind><br />
Restart/reconfigure Openbox. The following command summons a menu at your cursor position. The command may given as-is, linked to an object, or placed in a script.<br />
$ xdotool key ctrl+alt+q<br />
<br />
Of course, change the key shortcut to your liking. Here's a snippet from a '''tint2''' (a taskbar-like panel) configuration file which pops up a menu when the clock area is clicked. Each key combination is set to open a menu within openbox's '''{{Filename|rc.xml}}''' configuration file. The right‑click menu is different from the left‑click menu:<br />
clock_rclick_command = xdotool key --clearmodifiers "ctrl+XF86PowerOff"<br />
clock_lclick_command = xdotool key --clearmodifiers "alt+XF86PowerOff"<br />
<br />
=== Urxvt in the background ===<br />
<br />
With Openbox, running a terminal as desktop background is easy. You won't need '''devilspie''' here.<br />
<br />
First you must enable transparency, open your {{Filename|.Xdefaults}} file (if it doesn't exist yet, create it in your home folder).<br />
URxvt*transparent:true<br />
URxvt*scrollBar:false<br />
URxvt*geometry:124x24 #I don't use the whole screen, if you want a full screen term don't bother with this and see below.<br />
URxvt*borderLess:true<br />
URxvt*foreground:Black #Font color. My wallpaper is White, you may wish to change this to White.<br />
<br />
Then edit your {{Filename|.config/openbox/rc.xml}} file:<br />
<application name="URxvt"><br />
<decor>no</decor><br />
<focus>yes</focus><br />
<position><br />
<x>center</x><br />
<y>20</y><br />
</position><br />
<layer>below</layer><br />
<desktop>all</desktop><br />
<maximized>true</maximized> #Only if you want a full size terminal.<br />
</application><br />
<br />
The ''magic'' comes from the {{Codeline|<layer>below</layer>}} line, which place the application under all others. Here Urxvt is displayed on all desktops, change it to your convenience.<br />
<br />
Note: Instead of using <application name="URxvt">, you can use another name ("URxvt-bg" for example), and use the -name option when starting uxrvt. That way, only the urxvt terminals which you choose to name URxvt-bg would be captured and modified by the application rule in rc.xml. For example: urxvt -name URxvt-bg (case sensitive)<br />
<br />
====ToggleShowDesktop exception====<br />
<br />
Above method still minimizes Urxvt when using the ToggleShowDesktop command. A method for avoiding this is explained in this [https://bbs.archlinux.org/viewtopic.php?pid=865844#p865844 forum post]. This involves editing Urxvt's source code.<br />
<br />
=== Keyboard volume control ===<br />
<br />
If you use ALSA for sound, you can use the amixer program to adjust the volume of sound. You can use Openbox's keybindings to act like multimedia keys. (Alternatively, you can probably find out the names of your real multimedia keys and map them.) For example, in the <keyboard> section of rc.xml:<br />
<br />
<keybind key="W-Up"><br />
<action name="Execute"><br />
<command>amixer set Master 5%+</command><br />
</action><br />
</keybind><br />
<br />
This binds Windows key + Up arrow to increase your master ALSA volume by 5%. Corresponding binding for volume down:<br />
<br />
<keybind key="W-Down"><br />
<action name="Execute"><br />
<command>amixer set Master 5%-</command><br />
</action><br />
</keybind><br />
<br />
As another example you can also use the XF86Audio keybindings:<br />
<br />
<keybind key="XF86AudioRaiseVolume"><br />
<action name="Execute"><br />
<command>amixer set Master 5%+ unmute</command><br />
</action><br />
</keybind><br />
<keybind key="XF86AudioLowerVolume"><br />
<action name="Execute"><br />
<command>amixer set Master 5%- unmute</command><br />
</action><br />
</keybind><br />
<keybind key="XF86AudioMute"><br />
<action name="Execute"><br />
<command>amixer set Master toggle</command><br />
</action><br />
</keybind><br />
<br />
The above example should work for the majority of multimedia keyboards. It should enable to raise, lower and mute the Master control of your audio device by using the respective multimedia keyboard keys. Notice also that in this example:<br />
<br />
* The "Mute" key should unmute the Master control if it is already in mute mode.<br />
* The "Raise" and "Lower" keys should unmute the Master control if it is in mute mode.<br />
<br />
== Resources ==<br />
<br />
* [http://openbox.org/ Openbox Website] &ndash; The official website<br />
* [http://planetob.openmonkey.com/ Planet Openbox] &ndash; Openbox news portal<br />
* [http://www.box-look.org/ Box-Look.org] &ndash; A good resource for themes and related artwork<br />
* [https://bbs.archlinux.org/viewtopic.php?id=93126 Openbox Hacks and Configs Thread] @ Arch Linux Forums<br />
* [https://bbs.archlinux.org/viewtopic.php?id=45692 Openbox Screenshots Thread] @ Arch Linux Forums<br />
<!-- vim: set ft=Wikipedia: --></div>Jnguyenhttps://wiki.archlinux.org/index.php?title=TOMOYO_Linux&diff=133245TOMOYO Linux2011-03-09T14:46:39Z<p>Jnguyen: /* TOMOYO Linux Repository */ add command to show packages in tomoyo repository</p>
<hr />
<div>[[Category:Security (English)]]<br />
[[Category:Kernel (English)]]<br />
[[Category:Networking (English)]]<br />
[[Category:HOWTOs (English)]]<br />
[http://tomoyo.sourceforge.jp/ TOMOYO Linux] is Mandatory Access Control (MAC) implementation for Linux. It was launched in March 2003 and is sponsored by [http://www.nttdata.co.jp/en/ NTT Data Corporation]. TOMOYO Linux focuses on the behaviour of a system, allowing each process to declare behaviours and resources needed to achieve its purpose. It can be used as a system analysis tool as well as an access restriction tool.<br />
<br />
The security goal of TOMOYO Linux is to provide "MAC that covers practical requirements for most users and keeps usable for most administrators". TOMOYO Linux is not a tool or security professional but for average users and administrators.<br />
{{Note|This article does not aim to be an exhaustive guide and should be used as a supplement to the extensive [http://tomoyo.sourceforge.jp/documentation.html user documentation] provided by the project.}}<br />
{{Tip|[[#TOMOYO Linux Repository|Pre-built binaries]] for all TOMOYO Linux packages are available, including patched versions of kernel26 and kernel26-lts. AKARI is a Linux Kernel Module so is useful for custom kernels like kernel26-ck and kernel26-pf. TOMOYO Linux 2.x branch is already integrated into the mainline kernel and is the easiest of the three to set up, but it only offers a subset of functionality at the present time.}}<br />
<br />
==Introduction==<br />
TOMOYO Linux attempts to make the system where everything is prearranged in an easy to understand way:<br />
* Make all access requests that will occur at least once during the lifetime of the kernel known in advance<br />
* Allow the administrator to write a policy that only allows expected and desirable access requests<br />
Unlike AppArmor, TOMOYO Linux is intended to protect the whole system from attackers exploiting vulnerabilities in applications. TOMOYO Linux addresses this threat by recording the behaviour of all applications in the test environment and then forcing all applications to act within these recorded behaviours in the production environment.<br />
<br />
TOMOYO Linux is not for users wanting ready-made policy files supplied by others. It involves creating policy from scratch, aided by the "learning mode" which can automatically generate policy files with necessary and sufficient permissions for a specific system. TOMOYO Linux reports what is happening within the Linux system and can therefore be used as a system analysis tool. It resembles strace and reports what is being executed by each program and what files/networks are accessed.<br />
<br />
This [http://tomoyo.sourceforge.jp/wiki-e/?WhatIs#comparison table] provides a comprehensive comparison of TOMOYO Linux with [[AppArmor]], [[SELinux]] and [http://schaufler-ca.com/ SMACK].<br />
<br />
==Branches of development==<br />
[http://tomoyo.sourceforge.jp/1.8/index.html.en TOMOYO Linux 1.x] is the original branch of development. TOMOYO Linux was first released on 11th November 2005. It was implemented as a patch that can be applied to the Linux kernel and is still in active development. It can coexist with other security modules such as SELinux, SMACK and AppArmor.<br />
<br />
[http://tomoyo.sourceforge.jp/2.3/index.html.en TOMOYO Linux 2.x] is the Linux mainline kernel branch of development. In June 2009, TOMOYO was merged into the Linux kernel version 2.6.30 and it uses standard Linux Security Module (LSM) hooks. However, the LSM hooks must be extended further in order to port the full MAC functionality of TOMOYO Linux into the Linux kernel. Thus, it does not yet provide equal functionality with the 1.x branch of development. This [http://tomoyo.sourceforge.jp/comparison.html.en chart] compares the differences between each branch.<br />
<br />
[http://akari.sourceforge.jp/ AKARI] is based on the TOMOYO Linux 1.x branch and is implemented as a Loadable Kernel Module (LKM). It therefore has the advantage of not requiring the user to patch and recompile the kernel. This [http://akari.sourceforge.jp/comparison.html table] provides a comprehensive comparison of AKARI with the TOMOYO Linux 1.x and 2.x branches.<br />
<br />
==TOMOYO Linux Repository==<br />
An [[Unofficial_User_Repositories|unofficial user repository]] has been made available that has all the necessary packages, including patched versions of kernel26 and kernel26-lts for both i686 and x86_64. The repository can be browsed at [http://repo.tomoyolinux.co.uk repo.tomoyolinux.co.uk]. Add the following to the top of "/etc/pacman.conf":<br />
<br />
<pre><br />
[tomoyo]<br />
Server = http://repo.tomoyolinux.co.uk/archlinux/$arch<br />
</pre><br />
<br />
To view the packages in the repository, run the following:<br />
<br />
<pre><br />
pacman -Sl tomoyo<br />
</pre><br />
<br />
Forum thread can be found [https://bbs.archlinux.org/viewtopic.php?id=114075 here].<br />
<br />
==TOMOYO Linux 1.x==<br />
Implementing TOMOYO Linux 1.x using a kernel patched with ccs-patch provides the full functionality obtainable from the TOMOYO Linux project. However, implementation of this branch requires the most hurdles to be overcome, as the kernel must be patched with [http://sourceforge.jp/projects/tomoyo/ ccs-patch] and subsequently recompiled.<br />
<br />
Both kernel26-ccs and the userspace tools must be installed. A package for [http://aur.archlinux.org/packages.php?ID=44131 kernel-ccs] and a package for [http://aur.archlinux.org/packages.php?ID=42606 ccs-tools] are available on the AUR.<br />
<br />
Binary packages are available in the [[#TOMOYO Linux Repository|[tomoyo] repository]].<br />
<br />
===Initializing configuration===<br />
The policy must first be initialized:<br />
# /usr/lib/ccs/init_policy<br />
The policy files are saved in the /etc/css/ directory and can be edited by running:<br />
# ccs-editpolicy<br />
<br />
==AKARI==<br />
===Limitations of AKARI===<br />
AKARI has the advantage of not requiring kernel recompilation. If using the TOMOYO Linux project purely for system analysis, then AKARI is the easiest method of achieving this. If using the TOMOYO Linux project for system restriction, it is a minimal effort way to gain most of the functionality of the TOMOYO Linux 1.x branch. However, there are a few limitations that must be considered:<br />
* It depends on the kernel version and configuration provided by the distribution:<br />
<pre><br />
CONFIG_SECURITY=y [required]<br />
CONFIG_KALLSYMS=y [required]<br />
CONFIG_PROC_FS=y [required]<br />
CONFIG_MODULES=y [required]<br />
CONFIG_SECURITY_PATH=y [optional: for using absolute pathnames]<br />
CONFIG_SECURITY_NETWORK=y [optional: for providing network restriction]<br />
</pre><br />
* The restriction of a few advanced networking operations are limited or unavailable due to the absence of required LSM hooks<br />
* Restricting use of [http://en.wikipedia.org/wiki/Capability-based_security capabilities] is not possible<br />
* Looking up per-task variables is slower as they are managed outside "struct task_struct" in order to keep KABI unchanged. However, this should not be noticeable for the typical end-user as performance decrease by pathname based permission checking is dominant<br />
This [http://akari.sourceforge.jp/comparison.html table] provides a comprehensive comparison of AKARI with the TOMOYO Linux 1.x and 2.x branches.<br />
<br />
{{Note|The Arch Linux kernel from 2.6.36 onwards provides all of the configuration options required for full functionality.}}<br />
<br />
===Installation===<br />
Both AKARI and the userspace tools must be installed. A package for [http://aur.archlinux.org/packages.php?ID=42608 AKARI] and a package for [http://aur.archlinux.org/packages.php?ID=42606 ccs-tools] are available on the AUR.<br />
<br />
The bootloader configuration must be changed in order to activate AKARI:<br />
title Arch Linux<br />
root (hd0,0)<br />
kernel /boot/vmlinuz26 root=/dev/sda1 ro init=/sbin/ccs-init<br />
initrd /boot/kernel26.img<br />
<br />
Binary packages are available in the [[#TOMOYO Linux Repository|[tomoyo] repository]].<br />
<br />
===Initializing configuration===<br />
The policy must first be initialized:<br />
# /usr/lib/ccs/init_policy --module_name=akari<br />
The policy files are saved in the /etc/css/ directory and can be edited by running:<br />
# ccs-editpolicy<br />
<br />
==TOMOYO Linux 2.x==<br />
===Limitations of TOMOYO Linux 2.x===<br />
The implementation of TOMOYO Linux 2.x into the Linux mainline kernel is not yet complete but is still effective for MAC of files. It does not yet support the restriction of:<br />
* file attribute and namespace manipulation<br />
* capabilities<br />
* network<br />
* signal<br />
* environment variables<br />
* local port reservation<br />
This [http://tomoyo.sourceforge.jp/comparison.html.en chart] has a more comprehensive comparison of the differences between each branch of development.<br />
<br />
===Installation===<br />
TOMOYO Linux 2.x is part of the Linux mainline kernel and, in addition to those previously mentioned, requires the following kernel configuration:<br />
CONFIG_SECURITY_TOMOYO=y<br />
{{note|The Arch Linux kernel from 2.6.36 onwards provides all of the configuration options required for full functionality.}}<br />
<br />
If the kernel supports TOMOYO Linux 2.x, then only the userspace tools need to be installed. <br />
* For kernel versions between 2.6.30 and 2.6.35, tomoyo-tools 2.2.x should be installed. A package is available on the [http://aur.archlinux.org/packages.php?ID=42272 AUR]<br />
* For kernel versions 2.6.36 and above, tomoyo-tools 2.3.x should be installed. A package is available on the [http://aur.archlinux.org/packages.php?ID=39931 AUR]<br />
<br />
Binary packages are available in the [[#TOMOYO Linux Repository|[tomoyo] repository]].<br />
<br />
===Initializing configuration===<br />
The policy must first be initialized:<br />
# /usr/lib/tomoyo/init_policy<br />
The policy files are saved in the /etc/tomoyo/ directory and can be edited by running:<br />
# tomoyo-editpolicy<br />
<br />
==Usage==<br />
It is important to consult the relevant documentation in order to use TOMOYO Linux or AKARI effectively:<br />
* [http://tomoyo.sourceforge.jp/documentation.html.en TOMOYO Linux documentation]<br />
* [http://tomoyo.sourceforge.jp/1.8-tmp 90% complete rewrite of 1.8.x documentation] (not yet officially announced)<br />
* [http://akari.sourceforge.jp/index.html.en AKARI documentation]<br />
Run the policy editor to begin editing. If using TOMOYO Linux 1.x or AKARI then ccs-tools should be used:<br />
# /usr/sbin/ccs-editpolicy<br />
If using TOMOYO Linux 2.x then tomoyo-tools should be used:<br />
# /usr/sbin/tomoyo-editpolicy<br />
As the system runs, TOMOYO Linux will create domains and add them to the tree. The access analysis/restriction in TOMOYO Linux is applied via domains. Every process belongs to a single domain and the process will transit to a different domain whenever it executes a program. The name of a domain is a concatenated string expression for the process execution history. For example, the name of the domain which the kernel belongs to is "<kernel>"; the name of domain which /sbin/init invoked by the kernel belongs to is "<kernel> /sbin/init"; if /sbin/init invokes /etc/rc.d/rc then the domain it belongs to is "<kernel> /sbin/init /etc/rc.d/rc". You can suppress or initialize domain transitions as needed.<br />
<br />
Profiles can be assigned to each domain. There are four default profiles:<br />
<br />
{| border="1"<br />
| Disabled || Works as if regular kernel.<br />
|-<br />
| Learning || Do not reject an access request if it violates policy. Append the request to policy.<br />
|-<br />
| Permissive || Do not reject an access request if it violates policy. Do not append the request to policy.<br />
|-<br />
| Enforcing || Reject an access request if it violates policy. Do not append the request to policy.<br />
|}<br />
The learning profile can be used to analyse the system or a specific application. Once all of the desired access requests of a domain have been identified, the policy for that domain can be edited as required before selecting the enforcing profile. This can be done for any and all domains from the start of system boot.<br />
<br />
==References==<br />
* [http://tomomyo.sourceforge.jp/ TOMOYO Linux SourceForge page]<br />
* [http://tomoyo.sourceforge.jp/wiki-e/ TOMOYO Linux Wiki]<br />
* [http://akari.sourceforge.jp/index.html.en AKARI SourceForge page]<br />
* [http://akari.sourceforge.jp/index.html.en AKARI documentation]<br />
* [http://tomoyo.sourceforge.jp/1.8/index.html.en TOMOYO Linux 1.8.x documentation]<br />
* [http://tomoyo.sourceforge.jp/2.3/index.html.en TOMOYO Linux 2.3.x documentation]<br />
* [http://lwn.net/Articles/263179/ TOMOYO Linux Security Goal]<br />
* [http://tomoyo.sourceforge.jp/cgi-bin/lxr/source/centos5.5/domain_policy.conf?v=policy-sample Policy sample]<br />
* [http://elinux.org/TomoyoLinux TOMOYO Linux on the Embedded Linux Wiki]<br />
* [http://sourceforge.jp/projects/tomoyo/document/PacSec2007-en-demo.pdf Presentation slides from PacSec 2007]<br />
<br />
==See also==<br />
* [[AppArmor]]<br />
* [[SELinux]]</div>Jnguyenhttps://wiki.archlinux.org/index.php?title=TOMOYO_Linux&diff=133244TOMOYO Linux2011-03-09T14:45:41Z<p>Jnguyen: /* TOMOYO Linux Repository */ packages from [testing] no longer required for tomoyo repository</p>
<hr />
<div>[[Category:Security (English)]]<br />
[[Category:Kernel (English)]]<br />
[[Category:Networking (English)]]<br />
[[Category:HOWTOs (English)]]<br />
[http://tomoyo.sourceforge.jp/ TOMOYO Linux] is Mandatory Access Control (MAC) implementation for Linux. It was launched in March 2003 and is sponsored by [http://www.nttdata.co.jp/en/ NTT Data Corporation]. TOMOYO Linux focuses on the behaviour of a system, allowing each process to declare behaviours and resources needed to achieve its purpose. It can be used as a system analysis tool as well as an access restriction tool.<br />
<br />
The security goal of TOMOYO Linux is to provide "MAC that covers practical requirements for most users and keeps usable for most administrators". TOMOYO Linux is not a tool or security professional but for average users and administrators.<br />
{{Note|This article does not aim to be an exhaustive guide and should be used as a supplement to the extensive [http://tomoyo.sourceforge.jp/documentation.html user documentation] provided by the project.}}<br />
{{Tip|[[#TOMOYO Linux Repository|Pre-built binaries]] for all TOMOYO Linux packages are available, including patched versions of kernel26 and kernel26-lts. AKARI is a Linux Kernel Module so is useful for custom kernels like kernel26-ck and kernel26-pf. TOMOYO Linux 2.x branch is already integrated into the mainline kernel and is the easiest of the three to set up, but it only offers a subset of functionality at the present time.}}<br />
<br />
==Introduction==<br />
TOMOYO Linux attempts to make the system where everything is prearranged in an easy to understand way:<br />
* Make all access requests that will occur at least once during the lifetime of the kernel known in advance<br />
* Allow the administrator to write a policy that only allows expected and desirable access requests<br />
Unlike AppArmor, TOMOYO Linux is intended to protect the whole system from attackers exploiting vulnerabilities in applications. TOMOYO Linux addresses this threat by recording the behaviour of all applications in the test environment and then forcing all applications to act within these recorded behaviours in the production environment.<br />
<br />
TOMOYO Linux is not for users wanting ready-made policy files supplied by others. It involves creating policy from scratch, aided by the "learning mode" which can automatically generate policy files with necessary and sufficient permissions for a specific system. TOMOYO Linux reports what is happening within the Linux system and can therefore be used as a system analysis tool. It resembles strace and reports what is being executed by each program and what files/networks are accessed.<br />
<br />
This [http://tomoyo.sourceforge.jp/wiki-e/?WhatIs#comparison table] provides a comprehensive comparison of TOMOYO Linux with [[AppArmor]], [[SELinux]] and [http://schaufler-ca.com/ SMACK].<br />
<br />
==Branches of development==<br />
[http://tomoyo.sourceforge.jp/1.8/index.html.en TOMOYO Linux 1.x] is the original branch of development. TOMOYO Linux was first released on 11th November 2005. It was implemented as a patch that can be applied to the Linux kernel and is still in active development. It can coexist with other security modules such as SELinux, SMACK and AppArmor.<br />
<br />
[http://tomoyo.sourceforge.jp/2.3/index.html.en TOMOYO Linux 2.x] is the Linux mainline kernel branch of development. In June 2009, TOMOYO was merged into the Linux kernel version 2.6.30 and it uses standard Linux Security Module (LSM) hooks. However, the LSM hooks must be extended further in order to port the full MAC functionality of TOMOYO Linux into the Linux kernel. Thus, it does not yet provide equal functionality with the 1.x branch of development. This [http://tomoyo.sourceforge.jp/comparison.html.en chart] compares the differences between each branch.<br />
<br />
[http://akari.sourceforge.jp/ AKARI] is based on the TOMOYO Linux 1.x branch and is implemented as a Loadable Kernel Module (LKM). It therefore has the advantage of not requiring the user to patch and recompile the kernel. This [http://akari.sourceforge.jp/comparison.html table] provides a comprehensive comparison of AKARI with the TOMOYO Linux 1.x and 2.x branches.<br />
<br />
==TOMOYO Linux Repository==<br />
An [[Unofficial_User_Repositories|unofficial user repository]] has been made available that has all the necessary packages, including patched versions of kernel26 and kernel26-lts for both i686 and x86_64. The repository can be browsed at [http://repo.tomoyolinux.co.uk repo.tomoyolinux.co.uk]. Add the following to the top of "/etc/pacman.conf":<br />
<br />
<pre><br />
[tomoyo]<br />
Server = http://repo.tomoyolinux.co.uk/archlinux/$arch<br />
</pre><br />
<br />
Forum thread can be found [https://bbs.archlinux.org/viewtopic.php?id=114075 here].<br />
<br />
==TOMOYO Linux 1.x==<br />
Implementing TOMOYO Linux 1.x using a kernel patched with ccs-patch provides the full functionality obtainable from the TOMOYO Linux project. However, implementation of this branch requires the most hurdles to be overcome, as the kernel must be patched with [http://sourceforge.jp/projects/tomoyo/ ccs-patch] and subsequently recompiled.<br />
<br />
Both kernel26-ccs and the userspace tools must be installed. A package for [http://aur.archlinux.org/packages.php?ID=44131 kernel-ccs] and a package for [http://aur.archlinux.org/packages.php?ID=42606 ccs-tools] are available on the AUR.<br />
<br />
Binary packages are available in the [[#TOMOYO Linux Repository|[tomoyo] repository]].<br />
<br />
===Initializing configuration===<br />
The policy must first be initialized:<br />
# /usr/lib/ccs/init_policy<br />
The policy files are saved in the /etc/css/ directory and can be edited by running:<br />
# ccs-editpolicy<br />
<br />
==AKARI==<br />
===Limitations of AKARI===<br />
AKARI has the advantage of not requiring kernel recompilation. If using the TOMOYO Linux project purely for system analysis, then AKARI is the easiest method of achieving this. If using the TOMOYO Linux project for system restriction, it is a minimal effort way to gain most of the functionality of the TOMOYO Linux 1.x branch. However, there are a few limitations that must be considered:<br />
* It depends on the kernel version and configuration provided by the distribution:<br />
<pre><br />
CONFIG_SECURITY=y [required]<br />
CONFIG_KALLSYMS=y [required]<br />
CONFIG_PROC_FS=y [required]<br />
CONFIG_MODULES=y [required]<br />
CONFIG_SECURITY_PATH=y [optional: for using absolute pathnames]<br />
CONFIG_SECURITY_NETWORK=y [optional: for providing network restriction]<br />
</pre><br />
* The restriction of a few advanced networking operations are limited or unavailable due to the absence of required LSM hooks<br />
* Restricting use of [http://en.wikipedia.org/wiki/Capability-based_security capabilities] is not possible<br />
* Looking up per-task variables is slower as they are managed outside "struct task_struct" in order to keep KABI unchanged. However, this should not be noticeable for the typical end-user as performance decrease by pathname based permission checking is dominant<br />
This [http://akari.sourceforge.jp/comparison.html table] provides a comprehensive comparison of AKARI with the TOMOYO Linux 1.x and 2.x branches.<br />
<br />
{{Note|The Arch Linux kernel from 2.6.36 onwards provides all of the configuration options required for full functionality.}}<br />
<br />
===Installation===<br />
Both AKARI and the userspace tools must be installed. A package for [http://aur.archlinux.org/packages.php?ID=42608 AKARI] and a package for [http://aur.archlinux.org/packages.php?ID=42606 ccs-tools] are available on the AUR.<br />
<br />
The bootloader configuration must be changed in order to activate AKARI:<br />
title Arch Linux<br />
root (hd0,0)<br />
kernel /boot/vmlinuz26 root=/dev/sda1 ro init=/sbin/ccs-init<br />
initrd /boot/kernel26.img<br />
<br />
Binary packages are available in the [[#TOMOYO Linux Repository|[tomoyo] repository]].<br />
<br />
===Initializing configuration===<br />
The policy must first be initialized:<br />
# /usr/lib/ccs/init_policy --module_name=akari<br />
The policy files are saved in the /etc/css/ directory and can be edited by running:<br />
# ccs-editpolicy<br />
<br />
==TOMOYO Linux 2.x==<br />
===Limitations of TOMOYO Linux 2.x===<br />
The implementation of TOMOYO Linux 2.x into the Linux mainline kernel is not yet complete but is still effective for MAC of files. It does not yet support the restriction of:<br />
* file attribute and namespace manipulation<br />
* capabilities<br />
* network<br />
* signal<br />
* environment variables<br />
* local port reservation<br />
This [http://tomoyo.sourceforge.jp/comparison.html.en chart] has a more comprehensive comparison of the differences between each branch of development.<br />
<br />
===Installation===<br />
TOMOYO Linux 2.x is part of the Linux mainline kernel and, in addition to those previously mentioned, requires the following kernel configuration:<br />
CONFIG_SECURITY_TOMOYO=y<br />
{{note|The Arch Linux kernel from 2.6.36 onwards provides all of the configuration options required for full functionality.}}<br />
<br />
If the kernel supports TOMOYO Linux 2.x, then only the userspace tools need to be installed. <br />
* For kernel versions between 2.6.30 and 2.6.35, tomoyo-tools 2.2.x should be installed. A package is available on the [http://aur.archlinux.org/packages.php?ID=42272 AUR]<br />
* For kernel versions 2.6.36 and above, tomoyo-tools 2.3.x should be installed. A package is available on the [http://aur.archlinux.org/packages.php?ID=39931 AUR]<br />
<br />
Binary packages are available in the [[#TOMOYO Linux Repository|[tomoyo] repository]].<br />
<br />
===Initializing configuration===<br />
The policy must first be initialized:<br />
# /usr/lib/tomoyo/init_policy<br />
The policy files are saved in the /etc/tomoyo/ directory and can be edited by running:<br />
# tomoyo-editpolicy<br />
<br />
==Usage==<br />
It is important to consult the relevant documentation in order to use TOMOYO Linux or AKARI effectively:<br />
* [http://tomoyo.sourceforge.jp/documentation.html.en TOMOYO Linux documentation]<br />
* [http://tomoyo.sourceforge.jp/1.8-tmp 90% complete rewrite of 1.8.x documentation] (not yet officially announced)<br />
* [http://akari.sourceforge.jp/index.html.en AKARI documentation]<br />
Run the policy editor to begin editing. If using TOMOYO Linux 1.x or AKARI then ccs-tools should be used:<br />
# /usr/sbin/ccs-editpolicy<br />
If using TOMOYO Linux 2.x then tomoyo-tools should be used:<br />
# /usr/sbin/tomoyo-editpolicy<br />
As the system runs, TOMOYO Linux will create domains and add them to the tree. The access analysis/restriction in TOMOYO Linux is applied via domains. Every process belongs to a single domain and the process will transit to a different domain whenever it executes a program. The name of a domain is a concatenated string expression for the process execution history. For example, the name of the domain which the kernel belongs to is "<kernel>"; the name of domain which /sbin/init invoked by the kernel belongs to is "<kernel> /sbin/init"; if /sbin/init invokes /etc/rc.d/rc then the domain it belongs to is "<kernel> /sbin/init /etc/rc.d/rc". You can suppress or initialize domain transitions as needed.<br />
<br />
Profiles can be assigned to each domain. There are four default profiles:<br />
<br />
{| border="1"<br />
| Disabled || Works as if regular kernel.<br />
|-<br />
| Learning || Do not reject an access request if it violates policy. Append the request to policy.<br />
|-<br />
| Permissive || Do not reject an access request if it violates policy. Do not append the request to policy.<br />
|-<br />
| Enforcing || Reject an access request if it violates policy. Do not append the request to policy.<br />
|}<br />
The learning profile can be used to analyse the system or a specific application. Once all of the desired access requests of a domain have been identified, the policy for that domain can be edited as required before selecting the enforcing profile. This can be done for any and all domains from the start of system boot.<br />
<br />
==References==<br />
* [http://tomomyo.sourceforge.jp/ TOMOYO Linux SourceForge page]<br />
* [http://tomoyo.sourceforge.jp/wiki-e/ TOMOYO Linux Wiki]<br />
* [http://akari.sourceforge.jp/index.html.en AKARI SourceForge page]<br />
* [http://akari.sourceforge.jp/index.html.en AKARI documentation]<br />
* [http://tomoyo.sourceforge.jp/1.8/index.html.en TOMOYO Linux 1.8.x documentation]<br />
* [http://tomoyo.sourceforge.jp/2.3/index.html.en TOMOYO Linux 2.3.x documentation]<br />
* [http://lwn.net/Articles/263179/ TOMOYO Linux Security Goal]<br />
* [http://tomoyo.sourceforge.jp/cgi-bin/lxr/source/centos5.5/domain_policy.conf?v=policy-sample Policy sample]<br />
* [http://elinux.org/TomoyoLinux TOMOYO Linux on the Embedded Linux Wiki]<br />
* [http://sourceforge.jp/projects/tomoyo/document/PacSec2007-en-demo.pdf Presentation slides from PacSec 2007]<br />
<br />
==See also==<br />
* [[AppArmor]]<br />
* [[SELinux]]</div>Jnguyenhttps://wiki.archlinux.org/index.php?title=Firefox&diff=133049Firefox2011-03-06T23:33:28Z<p>Jnguyen: /* Method for root user */ apparently someone thought it was good advice to run firefox as root user</p>
<hr />
<div>[[Category:Internet and Email (English)]]<br />
[[Category:HOWTOs (English)]]<br />
{{i18n|Firefox}}<br />
{{Article summary start}}<br />
{{Article summary text|Installing and troubleshooting the Firefox browser and plugins}}<br />
{{Article summary heading|Related}}<br />
{{Article summary wiki|Browser Plugins}}: Acquiring and installing plugins such as [[Flash]]<br />
{{Article summary wiki|Firefox Tips and Tweaks}}: Configuration and modifications<br />
{{Article summary end}}<br />
<br />
[http://www.firefox.com Firefox] is an open-source graphical web browser from [http://www.mozilla.com Mozilla]. The Firefox package in Arch Linux is compiled without official branding, which means that when Firefox is started it will use an alternate icon and will be named after its release series' codename. This has to be done because a distribution may use the name "Firefox" and its artwork only if there are no unofficial modifications, including security patches.<br />
<br />
== Installing ==<br />
A non-branded version of Firefox is available through the repositories:<br />
# pacman -S firefox<br />
<br />
And the branded version is in the [[AUR]] under the name of {{package AUR|firefox-branded}}.<br />
<br />
== Add-ons ==<br />
*[https://addons.mozilla.org/firefox/1865/ Adblock Plus]<br />
:Highly effective ad and popup blocker with lots of options and a simplistic UI.<br />
<br />
*[https://addons.mozilla.org/en-US/firefox/addon/video-downloadhelper/ DownloadHelper]<br />
:DownloadHelper is a tool for web content extraction. Its purpose is to capture video and image files from many sites.<br />
<br />
*[https://addons.mozilla.org/firefox/2553/ CCK Wizard]<br />
:Allows customizing every aspect of Firefox. Title bar, user agent, icons, about graphic, and more. <br />
<br />
*[https://addons.mozilla.org/en-US/firefox/addon/9622 FirefoxNotify]<br />
:Integrate Firefox download complete messages with Linux notifications.<br />
<br />
*[https://addons.mozilla.org/en-US/firefox/addon/433 FlashBlock]<br />
:Blocks Flash animations from playing, can be disabled or enabled on a case-by-case basis. Very powerful.<br />
<br />
*[https://addons.mozilla.org/en-US/firefox/addon/220 FlashGot]<br />
:Download all the links, movies and audio clips of a page at the maximum speed with a single click. Very powerful, lightweight and reliable external download manager.<br />
<br />
*[https://addons.mozilla.org/en-US/firefox/addon/9609 Ghostery]<br />
:Protect your privacy. Blocks tracking scripts such as Google Analytics.<br />
<br />
*[https://addons.mozilla.org/firefox/446/ MediaPlayerConnectivity]<br />
:Allows launching an embedded video from a website in an external application. Good for those who have problems with media plugins.<br />
<br />
*[https://addons.mozilla.org/en-US/firefox/addon/722 NoScript]<br />
:Selectively blocks javascript, flash, and other types of content. Allows active content to run only from trusted sites, and protects the system against XSS and Clickjacking attacks.<br />
<br />
*[https://addons.mozilla.org/en-US/firefox/addon/1557 QuickProxy]<br />
:Adds a button to the browser UI to quickly toggle proxies on and off. Simple, clean, convenient.<br />
<br />
*[https://addons.mozilla.org/firefox/59/ User Agent Switcher]<br />
:Adds a menu and a toolbar button to switch the user agent of the browser.<br />
<br />
== Plugins ==<br />
''See: [[Browser Plugins]]''<br />
<br />
To find out what plugins are installed/enabled, enter:<br />
about:plugins<br />
in the Firefox address bar. Or go to ''Addons'' from the main bar drop downs <!-- I use vimperator so I don't know what's the name --> and select the ''Plugins'' tab.<br />
<br />
=== Gnome integration ===<br />
Install {{package AUR|firefox-extension-gnome-keyring-git}} from [[AUR]] to integrate Firefox 3.6.x with Gnome-keyring.<br />
<br />
You can also install {{package AUR|firefox-extension-firefoxnotify-git}} to get libnotify/notifyOSD integration.<br />
<br />
=== Dictionaries for spell checking ===<br />
Right click in any text entry field and add the dictionary for the solicited language. Restart firefox, and click in a text entry field again to enable spell checking.<br />
<br />
Or get it from pacman:<br />
pacman -Ss hunspell<br />
<br />
=== Adding Firefox search engines ===<br />
<br />
==== Newer method ====<br />
<br />
Visit https://addons.mozilla.org/en-US/firefox/browse/type:4/ and install.<br />
<br />
If you want to custom one, take a look at : ~/.mozilla/firefox/xxx.default/searchplugins/ where xxx is you profile id).<br />
<br />
==== Method for root user ====<br />
Firefox writes search engine files to {{filename|/opt/mozilla/lib/firefox/searchplugins}}, which is, by default, readable only by root. This means users cannot add search engines. You can <code>chmod o+w</code> this folder to install a search engine.<br />
<br />
To remove search engines, remove the appropriate search engine files in {{filename|/opt/mozilla/lib/firefox/searchplugins}}. Next time you start Firefox the engine won't be in the list.<br />
<br />
== Projects related to Firefox ==<br />
=== Firefox derivatives ===<br />
*[http://en.wikipedia.org/wiki/Iceweasel Iceweasel] - The name of '''two''' different Firefox forks. One was a GNU project; the name of this project has since changed to [http://en.wikipedia.org/wiki/GNU_IceCat Icecat]. The [http://wiki.debian.org/Iceweasel second] is being developed by Debian and is based on 2.0. At the time of writing the [[AUR]] only has Icecat.<br />
<br />
*[http://en.wikipedia.org/wiki/GNU_IceCat GNU/IceCat] - formerly known as GNU IceWeasel, is a web browser distributed by the GNU Project. IceCat, which is made entirely of free software, is a fork of Mozilla Firefox. It is compatible with the GNU/Linux operating system and almost all of Firefox's addons. GNU/IceCat really can fully replace Firefox.<br />
<br />
*[http://getswiftfox.com/ Swiftfox] - An optimized and processor-specific build of Firefox. Currently available via AUR. It should be noted that, considering Arch Linux has ABS, you could build your own optimized build of Firefox.<br />
<br />
*[http://swiftweasel.sourceforge.net/ Swiftweasel] - Mostly like Swiftfox, but the binaries aren't under proprietary license. Some PKGBUILDs are available in AUR.<br />
<br />
=== Firefox customized for speed ===<br />
Building with [https://developer.mozilla.org/en/Building_with_Profile-Guided_Optimization Profile-Guided Optimization (PGO)] is now available with GCC 4 or newer. A PGO build consists of two passes: a first pass to build instrumented binaries, then a second pass to re-build optimized binaries using profile information gleaned from running the instrumented binaries. The Mozilla build system will run both passes for you, you simply need to provide a script to run the application through some profiling scenarios in between the build passes. [https://wiki.mozilla.org/JavaScript:TraceMonkey TraceMonkey] adds native‐code compilation to Mozilla’s JavaScript engine (known as “SpiderMonkey”). It is based on a technique developed at UC Irvine called “trace trees”, and building on code and ideas shared with the Tamarin Tracing project. The net result is a massive speed increase both in the browser chrome and Web‐page content. <br />
<br />
*{{package AUR|firefox-pgo}}<br />
:XULRunner independent, PGO optimized, 64-bit TraceMonkey<br />
<br />
*{{package AUR|firefox-pgo-beta}}<br />
:XULRunner independent, PGO optimized, 64-bit TraceMonkey, beta<br />
<br />
====Experimental versions====<br />
*{{package AUR|firefox-pgo-minefield}}<br />
:Mozilla Firefox customizable web browser (XULRunner independent, PGO optimized, 64-bit TraceMonkey, Dev tree<br />
This package is similar to firefox-pgo and firefox-pgo-beta. The difference is that it will track mozilla-current, the Firefox trunk, via Mercurial.<br />
<br />
*{{package AUR|firefox-pgo-minefield-smp}}<br />
:Mozilla Firefox customizable web browser (XULRunner independent, PGO optimized, 64-bit TraceMonkey, Dev tree, Multithreaded<br />
See [https://wiki.mozilla.org/Electrolysis Mozilla Electrolysis project] Read instructions given by the .install file to enable SMP, and enjoy!<br />
Expect this to be very unstable for quite a while<br />
<br />
=== Firefox with better KDE integration ===<br />
*{{package AUR|firefox-kde-opensuse}}<br />
:with OpenSUSE patch, integrates better with KDE. OpenSUSE's patch and integration of Firefox with KDE is considered the best by many users.<br />
<br />
*{{package AUR|firefox-branded-kde}}<br />
:similar to firefox-kde-opensuse and projects are seeing into merging into one package. If it uses the OpenSUSE patch is unknown but it has other features that make Firefox integrate better with KDE<br />
<br />
== Troubleshooting ==<br />
<br />
=== Add-on installation fails ===<br />
Before you try to install add-ons, make sure that your {{filename|/tmp}} directory was created with the right permissions. If addons won't install, {{codeline|chmod 1777 /tmp}} should fix it.<br />
<br />
=== Open containing folder problems ===<br />
Some versions of Firefox insists on using Cervisia (CVS manager) or Gwenview (Image viewer) to open folders using the "Open Containing Folder" option in the Downloads manager while in KDE. An effective fix for this was posted on the Mandriva forums: [http://forum.mandriva.com/viewtopic.php?t=119723 firefox 'open containing folder' in Gwenview not Dolphin]. From the post:<br />
<br />
In:<br />
/home/your-user-name/.local/share/applications<br />
, create a text file and name it:<br />
defaults.list<br />
and put this text in it:<br />
x-directory/normal=kde4-dolphin.desktop;kde4-kfmclient_dir.desktop;<br />
<br />
(leave a blank line at the end). This should make "open containing folder" open in Dolphin or your default file manager. Restart Firefox.<br />
<br />
=== Firefox keeps creating ~/Desktop even when I don't want it! ===<br />
See [http://support.mozilla.com/tiki-view_forum_thread.php?comments_parentId=428359&forumId=1 this] forum post.<br />
<br />
=== Small fonts after upgrade ===<br />
After upgrading to xorg7 some users have had fonts become too small in Firefox. Edit > Preferences > Content > Fonts & Colors > Advanced > Display resolution > System setting fixes the problem. Just changing the default fonts around doesn't.<br />
<br />
=== Firefox hangs when trying to download files or images ===<br />
{{note|This issue no longer applies to simple_firewall.rules since recent updates.}}<br />
If you use the default supplied simple_firewall.rules with iptables for your firewall and you have gnome-vfs installed you might be in trouble. Quoting Jan De Groot: "gnome-vfs calls FAM. To find out if FAM is reachable, it tries to contact portmap... which will take ages when your localhost interface is firewalled." So add something like<br />
<pre><br />
-A INPUT -i lo -j ACCEPT<br />
</pre><br />
to your rules. This is due to the "famous GNOME/KDE loopback issue" which slows down all your GNOME and KDE activity.<br />
<br />
=== If Thunderbird is open, Firefox refuses to open ===<br />
This is a problem with the way that Firefox is packaged. Open {{codeline|/usr/bin/mozilla-firefox}} in your favourite text editor and comment out all lines of code. Add the following line instead:<br />
exec /opt/mozilla-firefox/bin/firefox ${1+"$@"}<br />
<br />
=== How to prevent plugins from allowing popups? ===<br />
Ever wondered why popups appear even though you've blocked them? It seems that Flash plugin can bypass default settings and annoy us with those pesky popups. Fear not, for we can prevent it from doing that.<br />
<br />
To get around it:<br />
# Type about:config into the Firefox location bar.<br />
# Right-click on the page and select New and then Integer.<br />
# Name it privacy.popups.disable_from_plugins<br />
# Set the value to 2.<br />
<br />
The possible values are:<br />
* 0: Allow all popups from plugins.<br />
* 1: Allow popups, but limit them to dom.popup_maximum.<br />
* 2: Block popups from plugins.<br />
* 3: Block popups from plugins, even on whitelisted sites. <br />
<br />
=== Middle-click errors ===<br />
! The URL is not valid and cannot be loaded.<br />
Another symptom is that middle-clicking results in unexpected behavior, like accessing a random webpage.<br />
<br />
The reason stems from the use of the middle mouse buttons in UNIX-like operating systems. The middle mouse button is used to paste whatever text has been highlighted/added to the clipboard. Then there is the possibly conflicting feature in Firefox, which defaults to loading the url of the corresponding text when the button is depressed. This can be disabled like so:<br />
<br />
Open the browser, and type the following into the address bar:<br />
about:config<br />
Search for '''middlemouse.contentLoadURL''' and set it to false.<br />
<br />
Alternatively, having the traditional scroll cursor on middle-click (default behaviour on Windows browsers) can be achieved by searching for '''general.autoScroll''' and setting it to true.<br />
<br />
=== Backspace does not work as the 'Back' button ===<br />
As per [http://ubuntu.wordpress.com/2006/12/21/fix-firefox-backspace-to-take-you-to-the-previous-page/ this article], the feature has been removed in order to fix a bug. Follow the next steps to retain the original behaviour.<br />
<br />
Open the browser and type the following address:<br />
about:config<br />
Search for '''browser.backspace_action''' and set it to 0 (zero).<br />
<br />
=== Firefox does not remember login information ===<br />
It may be cause of a corrupted {{Codeline|cookies.sqlite}} file in [http://support.mozilla.com/en-US/kb/Profiles#How_to_find_your_profile Firefox's profile] folder. In order to fix this, just rename or remove the cookie.sqlite while Firefox is not running.<br />
<br />
Open a terminal of choice and type the following:<br />
$ cd ~/.mozilla/firefox/xxxxxxxx.default/<br />
$ rm -f cookies.sqlite<br />
{{Note|xxxxxxxx represents a random string of 8 characters.}}<br />
<br />
Restart Firefox and see if it solved the problem.<br />
<br />
=== Broken websites / input fields with dark Gtk Themes ===<br />
When using a dark [[GTK]] theme, one might encounter Internet pages with unreadable input and text fields (p.e. Amazon - white text on white background). This can happen because the site only sets either background or text color, and Firefox takes the other one from the theme.<br />
<br />
A work around is to explicitly setting standard colours for all web pages in {{Filename|~/.mozilla/firefox/.../chrome/userContent.css}}.<br />
<br />
The following sets input fields to standard black text / white background; both can be overridden by the displayed site, so that colors are seen as intended:<br />
<pre><br />
input {<br />
background-color: white;<br />
color: black;<br />
}<br />
<br />
textarea {<br />
background-color: white;<br />
color: black;<br />
}<br />
</pre><br />
This will force the colours ("Allow paged to choose their own colors [..]" setting, in the '''Preferences > Content > Color''' dialog):<br />
<pre><br />
input {<br />
background-color: pink !important;<br />
color: green !important;<br />
}<br />
<br />
textarea {<br />
background-color: pink !important;<br />
color: green !important;<br />
}<br />
</pre><br />
Change color values to suit, or use an add-on like [https://addons.mozilla.org/en-US/firefox/addon/2108 Stylish].<br />
<br />
=== Preferences window appears blank ===<br />
This seems to be caused by files used by an older version of Firefox. Removing the <tt>~/.mozilla/firefox/[profile]/chrome</tt> directory fixes it. See the [http://support.mozilla.com/tiki-view_forum_thread.php?locale=fy-NL&comments_parentId=379718&forumId=1#threadId391374 Mozilla Support] page.<br />
<br />
=== File association problems ===<br />
For non-[[GNOME]] users, Firefox may not associate file types (in the "Open With" part of the download dialog). Installing {{Package Official|libgnome}} ammends the problem:<br />
pacman -S libgnome<br />
<br />
=== "Pop-in" Facebook chat won't work ===<br />
Facebook only enables the pop-in chat feature for specific browsers, your browser is most likely not one of those. You can change your user agent string to mimic a specific browser version. A user agent string is the piece of information your browser sends to the webserver to let it know what kind of browser you are using to visit the website. This helps the server provider the content from the site in a format supported by your browser.<br />
<br />
If you are using Firefox, read below.<br />
<br />
The current Firefox provided from pacman (pacman -S firefox) is Namoroka 3.6.3 (however version number/codename is subject to change).<br />
<br />
Facebook has to know that you are using Firefox, and not a unsupported browser.<br />
<br />
To edit the Firefox user agent string:<br />
<br />
Open up a new tab in firefox, and visit the page below<br />
about:config<br />
Once the page is loaded there is a Filter bar where you need to type<br />
general.useragent.extra.firefox<br />
when the result has returned it will most likely read "Namoroka/3.6.3" under value.<br />
<br />
If your value is something else, that's alright too. Just double click the value, and change the word BEFORE the slash<br />
to "Firefox" and leave the version number the same.<br />
<br />
To test your new user agent string go to "about:" in a new tab and your new agent string will be listed at the bottom.<br />
<br />
=== Funky colors of images ===<br />
<br />
Firefox's color management is somehow buggy, so depending on your hardware and drivers, you may encounter images with apparently wrong colours.<br />
Before you complain to your friends about the poor quality of their photos you have seen on Facebook, try the following (see the [https://bbs.archlinux.org/viewtopic.php?pid=604656 forum thread] for more)<br />
<br />
# Enter '''about:config''' into your address bar (and accept the warning that follows)<br />
# Change the value of the '''gfx.color_management.mode''' preference to '''0'''<br />
# Restart Firefox<br />
<br />
=== "I'm Feeling Lucky" Mode ===<br />
"I'm Feeling Lucky" mode lets the user harness the power of Google's "I'm Feeling Lucky" search engine feature via the Firefox address bar. <br />
<br />
To activate this mode, do the following (solution from [http://superuser.com/questions/76530/default-to-im-feeling-lucky-for-non-url-search-terms-in-firefox-address-bar this forum post]):<br />
<br />
# Type "'''about:config'''" in the address bar.<br />
# Search for the string '''keyword.url'''<br />
# Modify its value (if any) to<br />
<nowiki>http://www.google.com/search?btnI=I%27m+Feeling+Lucky&q=</nowiki><br />
<br />
=== "Do you want Firefox to save your tabs for the next time it starts?" dialog does not appear ===<br />
From the [http://support.mozilla.com/en-US/questions/767751 Mozilla Support] site:<br />
<br />
# Type "'''about:config'''" in the address bar.<br />
# Set '''browser.warnOnQuit''' to '''true'''.<br />
<br />
== Resources ==<br />
*[http://web.glandium.org/blog/?p=97 Facts about Debian and Mozilla® Firefox]<br />
:An account of the trademark issues from the Firefox package maintainer for Debian.<br />
*[http://www.gnu.org/software/gnuzilla/ Gnuzilla and IceWeasel]<br />
:Official website for the GNU Mozilla forks.</div>Jnguyenhttps://wiki.archlinux.org/index.php?title=TOMOYO_Linux&diff=132554TOMOYO Linux2011-03-02T22:21:14Z<p>Jnguyen: /* References */ fix policy sample link</p>
<hr />
<div>[[Category:Security (English)]]<br />
[[Category:Kernel (English)]]<br />
[[Category:Networking (English)]]<br />
[[Category:HOWTOs (English)]]<br />
[http://tomoyo.sourceforge.jp/ TOMOYO Linux] is Mandatory Access Control (MAC) implementation for Linux. It was launched in March 2003 and is sponsored by [http://www.nttdata.co.jp/en/ NTT Data Corporation]. TOMOYO Linux focuses on the behaviour of a system, allowing each process to declare behaviours and resources needed to achieve its purpose. It can be used as a system analysis tool as well as an access restriction tool.<br />
<br />
The security goal of TOMOYO Linux is to provide "MAC that covers practical requirements for most users and keeps usable for most administrators". TOMOYO Linux is not a tool or security professional but for average users and administrators.<br />
{{Note|This article does not aim to be an exhaustive guide and should be used as a supplement to the extensive [http://tomoyo.sourceforge.jp/documentation.html user documentation] provided by the project.}}<br />
{{Tip|[[#TOMOYO Linux Repository|Pre-built binaries]] for all TOMOYO Linux packages are available, including patched versions of kernel26 and kernel26-lts. AKARI is a Linux Kernel Module so is useful for custom kernels like kernel26-ck and kernel26-pf. TOMOYO Linux 2.x branch is already integrated into the mainline kernel and is the easiest of the three to set up, but it only offers a subset of functionality at the present time.}}<br />
<br />
==Introduction==<br />
TOMOYO Linux attempts to make the system where everything is prearranged in an easy to understand way:<br />
* Make all access requests that will occur at least once during the lifetime of the kernel known in advance<br />
* Allow the administrator to write a policy that only allows expected and desirable access requests<br />
Unlike AppArmor, TOMOYO Linux is intended to protect the whole system from attackers exploiting vulnerabilities in applications. TOMOYO Linux addresses this threat by recording the behaviour of all applications in the test environment and then forcing all applications to act within these recorded behaviours in the production environment.<br />
<br />
TOMOYO Linux is not for users wanting ready-made policy files supplied by others. It involves creating policy from scratch, aided by the "learning mode" which can automatically generate policy files with necessary and sufficient permissions for a specific system. TOMOYO Linux reports what is happening within the Linux system and can therefore be used as a system analysis tool. It resembles strace and reports what is being executed by each program and what files/networks are accessed.<br />
<br />
This [http://tomoyo.sourceforge.jp/wiki-e/?WhatIs#comparison table] provides a comprehensive comparison of TOMOYO Linux with [[AppArmor]], [[SELinux]] and [http://schaufler-ca.com/ SMACK].<br />
<br />
==Branches of development==<br />
[http://tomoyo.sourceforge.jp/1.8/index.html.en TOMOYO Linux 1.x] is the original branch of development. TOMOYO Linux was first released on 11th November 2005. It was implemented as a patch that can be applied to the Linux kernel and is still in active development. It can coexist with other security modules such as SELinux, SMACK and AppArmor.<br />
<br />
[http://tomoyo.sourceforge.jp/2.3/index.html.en TOMOYO Linux 2.x] is the Linux mainline kernel branch of development. In June 2009, TOMOYO was merged into the Linux kernel version 2.6.30 and it uses standard Linux Security Module (LSM) hooks. However, the LSM hooks must be extended further in order to port the full MAC functionality of TOMOYO Linux into the Linux kernel. Thus, it does not yet provide equal functionality with the 1.x branch of development. This [http://tomoyo.sourceforge.jp/comparison.html.en chart] compares the differences between each branch.<br />
<br />
[http://akari.sourceforge.jp/ AKARI] is based on the TOMOYO Linux 1.x branch and is implemented as a Loadable Kernel Module (LKM). It therefore has the advantage of not requiring the user to patch and recompile the kernel. This [http://akari.sourceforge.jp/comparison.html table] provides a comprehensive comparison of AKARI with the TOMOYO Linux 1.x and 2.x branches.<br />
<br />
==TOMOYO Linux Repository==<br />
An [[Unofficial_User_Repositories|unofficial user repository]] has been made available that has all the necessary packages, including patched versions of kernel26 and kernel26-lts for both i686 and x86_64. The repository can be browsed at [http://repo.tomoyolinux.co.uk repo.tomoyolinux.co.uk]. Add the following to the top of "/etc/pacman.conf":<br />
<br />
<pre><br />
[tomoyo]<br />
Server = http://repo.tomoyolinux.co.uk/archlinux/$arch<br />
</pre><br />
<br />
Currently this repository includes versions of util-linux and mkinitcpio that are in [testing] which are required for the kernel packages, so the entry must precede all other repositories in your "/etc/pacman.conf". Once these packages have been pushed to [core] then the tomoyo entry can be moved to the bottom.<br />
<br />
Forum thread can be found [https://bbs.archlinux.org/viewtopic.php?id=114075 here].<br />
<br />
==TOMOYO Linux 1.x==<br />
Implementing TOMOYO Linux 1.x using a kernel patched with ccs-patch provides the full functionality obtainable from the TOMOYO Linux project. However, implementation of this branch requires the most hurdles to be overcome, as the kernel must be patched with [http://sourceforge.jp/projects/tomoyo/ ccs-patch] and subsequently recompiled.<br />
<br />
Both kernel26-ccs and the userspace tools must be installed. A package for [http://aur.archlinux.org/packages.php?ID=44131 kernel-ccs] and a package for [http://aur.archlinux.org/packages.php?ID=42606 ccs-tools] are available on the AUR.<br />
<br />
Binary packages are available in the [[#TOMOYO Linux Repository|[tomoyo] repository]].<br />
<br />
===Initializing configuration===<br />
The policy must first be initialized:<br />
# /usr/lib/ccs/init_policy<br />
The policy files are saved in the /etc/css/ directory and can be edited by running:<br />
# ccs-editpolicy<br />
<br />
==AKARI==<br />
===Limitations of AKARI===<br />
AKARI has the advantage of not requiring kernel recompilation. If using the TOMOYO Linux project purely for system analysis, then AKARI is the easiest method of achieving this. If using the TOMOYO Linux project for system restriction, it is a minimal effort way to gain most of the functionality of the TOMOYO Linux 1.x branch. However, there are a few limitations that must be considered:<br />
* It depends on the kernel version and configuration provided by the distribution:<br />
<pre><br />
CONFIG_SECURITY=y [required]<br />
CONFIG_KALLSYMS=y [required]<br />
CONFIG_PROC_FS=y [required]<br />
CONFIG_MODULES=y [required]<br />
CONFIG_SECURITY_PATH=y [optional: for using absolute pathnames]<br />
CONFIG_SECURITY_NETWORK=y [optional: for providing network restriction]<br />
</pre><br />
* The restriction of a few advanced networking operations are limited or unavailable due to the absence of required LSM hooks<br />
* Restricting use of [http://en.wikipedia.org/wiki/Capability-based_security capabilities] is not possible<br />
* Looking up per-task variables is slower as they are managed outside "struct task_struct" in order to keep KABI unchanged. However, this should not be noticeable for the typical end-user as performance decrease by pathname based permission checking is dominant<br />
This [http://akari.sourceforge.jp/comparison.html table] provides a comprehensive comparison of AKARI with the TOMOYO Linux 1.x and 2.x branches.<br />
<br />
{{Note|The Arch Linux kernel from 2.6.36 onwards provides all of the configuration options required for full functionality.}}<br />
<br />
===Installation===<br />
Both AKARI and the userspace tools must be installed. A package for [http://aur.archlinux.org/packages.php?ID=42608 AKARI] and a package for [http://aur.archlinux.org/packages.php?ID=42606 ccs-tools] are available on the AUR.<br />
<br />
The bootloader configuration must be changed in order to activate AKARI:<br />
title Arch Linux<br />
root (hd0,0)<br />
kernel /boot/vmlinuz26 root=/dev/sda1 ro init=/sbin/ccs-init<br />
initrd /boot/kernel26.img<br />
<br />
Binary packages are available in the [[#TOMOYO Linux Repository|[tomoyo] repository]].<br />
<br />
===Initializing configuration===<br />
The policy must first be initialized:<br />
# /usr/lib/ccs/init_policy --module_name=akari<br />
The policy files are saved in the /etc/css/ directory and can be edited by running:<br />
# ccs-editpolicy<br />
<br />
==TOMOYO Linux 2.x==<br />
===Limitations of TOMOYO Linux 2.x===<br />
The implementation of TOMOYO Linux 2.x into the Linux mainline kernel is not yet complete but is still effective for MAC of files. It does not yet support the restriction of:<br />
* file attribute and namespace manipulation<br />
* capabilities<br />
* network<br />
* signal<br />
* environment variables<br />
* local port reservation<br />
This [http://tomoyo.sourceforge.jp/comparison.html.en chart] has a more comprehensive comparison of the differences between each branch of development.<br />
<br />
===Installation===<br />
TOMOYO Linux 2.x is part of the Linux mainline kernel and, in addition to those previously mentioned, requires the following kernel configuration:<br />
CONFIG_SECURITY_TOMOYO=y<br />
{{note|The Arch Linux kernel from 2.6.36 onwards provides all of the configuration options required for full functionality.}}<br />
<br />
If the kernel supports TOMOYO Linux 2.x, then only the userspace tools need to be installed. <br />
* For kernel versions between 2.6.30 and 2.6.35, tomoyo-tools 2.2.x should be installed. A package is available on the [http://aur.archlinux.org/packages.php?ID=42272 AUR]<br />
* For kernel versions 2.6.36 and above, tomoyo-tools 2.3.x should be installed. A package is available on the [http://aur.archlinux.org/packages.php?ID=39931 AUR]<br />
<br />
Binary packages are available in the [[#TOMOYO Linux Repository|[tomoyo] repository]].<br />
<br />
===Initializing configuration===<br />
The policy must first be initialized:<br />
# /usr/lib/tomoyo/init_policy<br />
The policy files are saved in the /etc/tomoyo/ directory and can be edited by running:<br />
# tomoyo-editpolicy<br />
<br />
==Usage==<br />
It is important to consult the relevant documentation in order to use TOMOYO Linux or AKARI effectively:<br />
* [http://tomoyo.sourceforge.jp/documentation.html.en TOMOYO Linux documentation]<br />
* [http://tomoyo.sourceforge.jp/1.8-tmp 90% complete rewrite of 1.8.x documentation] (not yet officially announced)<br />
* [http://akari.sourceforge.jp/index.html.en AKARI documentation]<br />
Run the policy editor to begin editing. If using TOMOYO Linux 1.x or AKARI then ccs-tools should be used:<br />
# /usr/sbin/ccs-editpolicy<br />
If using TOMOYO Linux 2.x then tomoyo-tools should be used:<br />
# /usr/sbin/tomoyo-editpolicy<br />
As the system runs, TOMOYO Linux will create domains and add them to the tree. The access analysis/restriction in TOMOYO Linux is applied via domains. Every process belongs to a single domain and the process will transit to a different domain whenever it executes a program. The name of a domain is a concatenated string expression for the process execution history. For example, the name of the domain which the kernel belongs to is "<kernel>"; the name of domain which /sbin/init invoked by the kernel belongs to is "<kernel> /sbin/init"; if /sbin/init invokes /etc/rc.d/rc then the domain it belongs to is "<kernel> /sbin/init /etc/rc.d/rc". You can suppress or initialize domain transitions as needed.<br />
<br />
Profiles can be assigned to each domain. There are four default profiles:<br />
<br />
{| border="1"<br />
| Disabled || Works as if regular kernel.<br />
|-<br />
| Learning || Do not reject an access request if it violates policy. Append the request to policy.<br />
|-<br />
| Permissive || Do not reject an access request if it violates policy. Do not append the request to policy.<br />
|-<br />
| Enforcing || Reject an access request if it violates policy. Do not append the request to policy.<br />
|}<br />
The learning profile can be used to analyse the system or a specific application. Once all of the desired access requests of a domain have been identified, the policy for that domain can be edited as required before selecting the enforcing profile. This can be done for any and all domains from the start of system boot.<br />
<br />
==References==<br />
* [http://tomomyo.sourceforge.jp/ TOMOYO Linux SourceForge page]<br />
* [http://tomoyo.sourceforge.jp/wiki-e/ TOMOYO Linux Wiki]<br />
* [http://akari.sourceforge.jp/index.html.en AKARI SourceForge page]<br />
* [http://akari.sourceforge.jp/index.html.en AKARI documentation]<br />
* [http://tomoyo.sourceforge.jp/1.8/index.html.en TOMOYO Linux 1.8.x documentation]<br />
* [http://tomoyo.sourceforge.jp/2.3/index.html.en TOMOYO Linux 2.3.x documentation]<br />
* [http://lwn.net/Articles/263179/ TOMOYO Linux Security Goal]<br />
* [http://tomoyo.sourceforge.jp/cgi-bin/lxr/source/centos5.5/domain_policy.conf?v=policy-sample Policy sample]<br />
* [http://elinux.org/TomoyoLinux TOMOYO Linux on the Embedded Linux Wiki]<br />
* [http://sourceforge.jp/projects/tomoyo/document/PacSec2007-en-demo.pdf Presentation slides from PacSec 2007]<br />
<br />
==See also==<br />
* [[AppArmor]]<br />
* [[SELinux]]</div>Jnguyenhttps://wiki.archlinux.org/index.php?title=TOMOYO_Linux&diff=131931TOMOYO Linux2011-02-24T16:35:13Z<p>Jnguyen: /* TOMOYO Linux Repository */</p>
<hr />
<div>[[Category:Security (English)]]<br />
[[Category:Kernel (English)]]<br />
[[Category:Networking (English)]]<br />
[[Category:HOWTOs (English)]]<br />
[http://tomoyo.sourceforge.jp/ TOMOYO Linux] is Mandatory Access Control (MAC) implementation for Linux. It was launched in March 2003 and is sponsored by [http://www.nttdata.co.jp/en/ NTT Data Corporation]. TOMOYO Linux focuses on the behaviour of a system, allowing each process to declare behaviours and resources needed to achieve its purpose. It can be used as a system analysis tool as well as an access restriction tool.<br />
<br />
The security goal of TOMOYO Linux is to provide "MAC that covers practical requirements for most users and keeps usable for most administrators". TOMOYO Linux is not a tool or security professional but for average users and administrators.<br />
{{Note|This article does not aim to be an exhaustive guide and should be used as a supplement to the extensive [http://tomoyo.sourceforge.jp/documentation.html user documentation] provided by the project.}}<br />
{{Tip|[[#TOMOYO Linux Repository|Pre-built binaries]] for all TOMOYO Linux packages are available, including patched versions of kernel26 and kernel26-lts. AKARI is a Linux Kernel Module so is useful for custom kernels like kernel26-ck and kernel26-pf. TOMOYO Linux 2.x branch is already integrated into the mainline kernel and is the easiest of the three to set up, but it only offers a subset of functionality at the present time.}}<br />
<br />
==Introduction==<br />
TOMOYO Linux attempts to make the system where everything is prearranged in an easy to understand way:<br />
* Make all access requests that will occur at least once during the lifetime of the kernel known in advance<br />
* Allow the administrator to write a policy that only allows expected and desirable access requests<br />
Unlike AppArmor, TOMOYO Linux is intended to protect the whole system from attackers exploiting vulnerabilities in applications. TOMOYO Linux addresses this threat by recording the behaviour of all applications in the test environment and then forcing all applications to act within these recorded behaviours in the production environment.<br />
<br />
TOMOYO Linux is not for users wanting ready-made policy files supplied by others. It involves creating policy from scratch, aided by the "learning mode" which can automatically generate policy files with necessary and sufficient permissions for a specific system. TOMOYO Linux reports what is happening within the Linux system and can therefore be used as a system analysis tool. It resembles strace and reports what is being executed by each program and what files/networks are accessed.<br />
<br />
This [http://tomoyo.sourceforge.jp/wiki-e/?WhatIs#comparison table] provides a comprehensive comparison of TOMOYO Linux with [[AppArmor]], [[SELinux]] and [http://schaufler-ca.com/ SMACK].<br />
<br />
==Branches of development==<br />
[http://tomoyo.sourceforge.jp/1.8/index.html.en TOMOYO Linux 1.x] is the original branch of development. TOMOYO Linux was first released on 11th November 2005. It was implemented as a patch that can be applied to the Linux kernel and is still in active development. It can coexist with other security modules such as SELinux, SMACK and AppArmor.<br />
<br />
[http://tomoyo.sourceforge.jp/2.3/index.html.en TOMOYO Linux 2.x] is the Linux mainline kernel branch of development. In June 2009, TOMOYO was merged into the Linux kernel version 2.6.30 and it uses standard Linux Security Module (LSM) hooks. However, the LSM hooks must be extended further in order to port the full MAC functionality of TOMOYO Linux into the Linux kernel. Thus, it does not yet provide equal functionality with the 1.x branch of development. This [http://tomoyo.sourceforge.jp/comparison.html.en chart] compares the differences between each branch.<br />
<br />
[http://akari.sourceforge.jp/ AKARI] is based on the TOMOYO Linux 1.x branch and is implemented as a Loadable Kernel Module (LKM). It therefore has the advantage of not requiring the user to patch and recompile the kernel. This [http://akari.sourceforge.jp/comparison.html table] provides a comprehensive comparison of AKARI with the TOMOYO Linux 1.x and 2.x branches.<br />
<br />
==TOMOYO Linux Repository==<br />
An [[Unofficial_User_Repositories|unofficial user repository]] has been made available that has all the necessary packages, including patched versions of kernel26 and kernel26-lts for both i686 and x86_64. The repository can be browsed at [http://repo.tomoyolinux.co.uk repo.tomoyolinux.co.uk]. Add the following to the top of "/etc/pacman.conf":<br />
<br />
<pre><br />
[tomoyo]<br />
Server = http://repo.tomoyolinux.co.uk/archlinux/$arch<br />
</pre><br />
<br />
Currently this repository includes versions of util-linux and mkinitcpio that are in [testing] which are required for the kernel packages, so the entry must precede all other repositories in your "/etc/pacman.conf". Once these packages have been pushed to [core] then the tomoyo entry can be moved to the bottom.<br />
<br />
Forum thread can be found [https://bbs.archlinux.org/viewtopic.php?id=114075 here].<br />
<br />
==TOMOYO Linux 1.x==<br />
Implementing TOMOYO Linux 1.x using a kernel patched with ccs-patch provides the full functionality obtainable from the TOMOYO Linux project. However, implementation of this branch requires the most hurdles to be overcome, as the kernel must be patched with [http://sourceforge.jp/projects/tomoyo/ ccs-patch] and subsequently recompiled.<br />
<br />
Both kernel26-ccs and the userspace tools must be installed. A package for [http://aur.archlinux.org/packages.php?ID=44131 kernel-ccs] and a package for [http://aur.archlinux.org/packages.php?ID=42606 ccs-tools] are available on the AUR.<br />
<br />
Binary packages are available in the [[#TOMOYO Linux Repository|[tomoyo] repository]].<br />
<br />
===Initializing configuration===<br />
The policy must first be initialized:<br />
# /usr/lib/ccs/init_policy<br />
The policy files are saved in the /etc/css/ directory and can be edited by running:<br />
# ccs-editpolicy<br />
<br />
==AKARI==<br />
===Limitations of AKARI===<br />
AKARI has the advantage of not requiring kernel recompilation. If using the TOMOYO Linux project purely for system analysis, then AKARI is the easiest method of achieving this. If using the TOMOYO Linux project for system restriction, it is a minimal effort way to gain most of the functionality of the TOMOYO Linux 1.x branch. However, there are a few limitations that must be considered:<br />
* It depends on the kernel version and configuration provided by the distribution:<br />
<pre><br />
CONFIG_SECURITY=y [required]<br />
CONFIG_KALLSYMS=y [required]<br />
CONFIG_PROC_FS=y [required]<br />
CONFIG_MODULES=y [required]<br />
CONFIG_SECURITY_PATH=y [optional: for using absolute pathnames]<br />
CONFIG_SECURITY_NETWORK=y [optional: for providing network restriction]<br />
</pre><br />
* The restriction of a few advanced networking operations are limited or unavailable due to the absence of required LSM hooks<br />
* Restricting use of [http://en.wikipedia.org/wiki/Capability-based_security capabilities] is not possible<br />
* Looking up per-task variables is slower as they are managed outside "struct task_struct" in order to keep KABI unchanged. However, this should not be noticeable for the typical end-user as performance decrease by pathname based permission checking is dominant<br />
This [http://akari.sourceforge.jp/comparison.html table] provides a comprehensive comparison of AKARI with the TOMOYO Linux 1.x and 2.x branches.<br />
<br />
{{Note|The Arch Linux kernel from 2.6.36 onwards provides all of the configuration options required for full functionality.}}<br />
<br />
===Installation===<br />
Both AKARI and the userspace tools must be installed. A package for [http://aur.archlinux.org/packages.php?ID=42608 AKARI] and a package for [http://aur.archlinux.org/packages.php?ID=42606 ccs-tools] are available on the AUR.<br />
<br />
The bootloader configuration must be changed in order to activate AKARI:<br />
title Arch Linux<br />
root (hd0,0)<br />
kernel /boot/vmlinuz26 root=/dev/sda1 ro init=/sbin/ccs-init<br />
initrd /boot/kernel26.img<br />
<br />
Binary packages are available in the [[#TOMOYO Linux Repository|[tomoyo] repository]].<br />
<br />
===Initializing configuration===<br />
The policy must first be initialized:<br />
# /usr/lib/ccs/init_policy --module_name=akari<br />
The policy files are saved in the /etc/css/ directory and can be edited by running:<br />
# ccs-editpolicy<br />
<br />
==TOMOYO Linux 2.x==<br />
===Limitations of TOMOYO Linux 2.x===<br />
The implementation of TOMOYO Linux 2.x into the Linux mainline kernel is not yet complete but is still effective for MAC of files. It does not yet support the restriction of:<br />
* file attribute and namespace manipulation<br />
* capabilities<br />
* network<br />
* signal<br />
* environment variables<br />
* local port reservation<br />
This [http://tomoyo.sourceforge.jp/comparison.html.en chart] has a more comprehensive comparison of the differences between each branch of development.<br />
<br />
===Installation===<br />
TOMOYO Linux 2.x is part of the Linux mainline kernel and, in addition to those previously mentioned, requires the following kernel configuration:<br />
CONFIG_SECURITY_TOMOYO=y<br />
{{note|The Arch Linux kernel from 2.6.36 onwards provides all of the configuration options required for full functionality.}}<br />
<br />
If the kernel supports TOMOYO Linux 2.x, then only the userspace tools need to be installed. <br />
* For kernel versions between 2.6.30 and 2.6.35, tomoyo-tools 2.2.x should be installed. A package is available on the [http://aur.archlinux.org/packages.php?ID=42272 AUR]<br />
* For kernel versions 2.6.36 and above, tomoyo-tools 2.3.x should be installed. A package is available on the [http://aur.archlinux.org/packages.php?ID=39931 AUR]<br />
<br />
Binary packages are available in the [[#TOMOYO Linux Repository|[tomoyo] repository]].<br />
<br />
===Initializing configuration===<br />
The policy must first be initialized:<br />
# /usr/lib/tomoyo/init_policy<br />
The policy files are saved in the /etc/tomoyo/ directory and can be edited by running:<br />
# tomoyo-editpolicy<br />
<br />
==Usage==<br />
It is important to consult the relevant documentation in order to use TOMOYO Linux or AKARI effectively:<br />
* [http://tomoyo.sourceforge.jp/documentation.html.en TOMOYO Linux documentation]<br />
* [http://tomoyo.sourceforge.jp/1.8-tmp 90% complete rewrite of 1.8.x documentation] (not yet officially announced)<br />
* [http://akari.sourceforge.jp/index.html.en AKARI documentation]<br />
Run the policy editor to begin editing. If using TOMOYO Linux 1.x or AKARI then ccs-tools should be used:<br />
# /usr/sbin/ccs-editpolicy<br />
If using TOMOYO Linux 2.x then tomoyo-tools should be used:<br />
# /usr/sbin/tomoyo-editpolicy<br />
As the system runs, TOMOYO Linux will create domains and add them to the tree. The access analysis/restriction in TOMOYO Linux is applied via domains. Every process belongs to a single domain and the process will transit to a different domain whenever it executes a program. The name of a domain is a concatenated string expression for the process execution history. For example, the name of the domain which the kernel belongs to is "<kernel>"; the name of domain which /sbin/init invoked by the kernel belongs to is "<kernel> /sbin/init"; if /sbin/init invokes /etc/rc.d/rc then the domain it belongs to is "<kernel> /sbin/init /etc/rc.d/rc". You can suppress or initialize domain transitions as needed.<br />
<br />
Profiles can be assigned to each domain. There are four default profiles:<br />
<br />
{| border="1"<br />
| Disabled || Works as if regular kernel.<br />
|-<br />
| Learning || Do not reject an access request if it violates policy. Append the request to policy.<br />
|-<br />
| Permissive || Do not reject an access request if it violates policy. Do not append the request to policy.<br />
|-<br />
| Enforcing || Reject an access request if it violates policy. Do not append the request to policy.<br />
|}<br />
The learning profile can be used to analyse the system or a specific application. Once all of the desired access requests of a domain have been identified, the policy for that domain can be edited as required before selecting the enforcing profile. This can be done for any and all domains from the start of system boot.<br />
<br />
==References==<br />
* [http://tomomyo.sourceforge.jp/ TOMOYO Linux SourceForge page]<br />
* [http://tomoyo.sourceforge.jp/wiki-e/ TOMOYO Linux Wiki]<br />
* [http://akari.sourceforge.jp/index.html.en AKARI SourceForge page]<br />
* [http://akari.sourceforge.jp/index.html.en AKARI documentation]<br />
* [http://tomoyo.sourceforge.jp/1.8/index.html.en TOMOYO Linux 1.8.x documentation]<br />
* [http://tomoyo.sourceforge.jp/2.3/index.html.en TOMOYO Linux 2.3.x documentation]<br />
* [http://lwn.net/Articles/263179/ TOMOYO Linux Security Goal]<br />
* [http://tomoyo.sourceforge.jp/cgi-bin/lxr/source/etch/domain_policy.conf?v=policy-sample Policy sample]<br />
* [http://elinux.org/TomoyoLinux TOMOYO Linux on the Embedded Linux Wiki]<br />
* [http://sourceforge.jp/projects/tomoyo/document/PacSec2007-en-demo.pdf Presentation slides from PacSec 2007]<br />
<br />
==See also==<br />
* [[AppArmor]]<br />
* [[SELinux]]</div>Jnguyenhttps://wiki.archlinux.org/index.php?title=TOMOYO_Linux&diff=131929TOMOYO Linux2011-02-24T15:06:48Z<p>Jnguyen: forum thread link</p>
<hr />
<div>[[Category:Security (English)]]<br />
[[Category:Kernel (English)]]<br />
[[Category:Networking (English)]]<br />
[[Category:HOWTOs (English)]]<br />
[http://tomoyo.sourceforge.jp/ TOMOYO Linux] is Mandatory Access Control (MAC) implementation for Linux. It was launched in March 2003 and is sponsored by [http://www.nttdata.co.jp/en/ NTT Data Corporation]. TOMOYO Linux focuses on the behaviour of a system, allowing each process to declare behaviours and resources needed to achieve its purpose. It can be used as a system analysis tool as well as an access restriction tool.<br />
<br />
The security goal of TOMOYO Linux is to provide "MAC that covers practical requirements for most users and keeps usable for most administrators". TOMOYO Linux is not a tool or security professional but for average users and administrators.<br />
{{Note|This article does not aim to be an exhaustive guide and should be used as a supplement to the extensive [http://tomoyo.sourceforge.jp/documentation.html user documentation] provided by the project.}}<br />
{{Tip|[[#TOMOYO Linux Repository|Pre-built binaries]] for all TOMOYO Linux packages are available, including patched versions of kernel26 and kernel26-lts. AKARI is a Linux Kernel Module so is useful for custom kernels like kernel26-ck and kernel26-pf. TOMOYO Linux 2.x branch is already integrated into the mainline kernel and is the easiest of the three to set up, but it only offers a subset of functionality at the present time.}}<br />
<br />
==Introduction==<br />
TOMOYO Linux attempts to make the system where everything is prearranged in an easy to understand way:<br />
* Make all access requests that will occur at least once during the lifetime of the kernel known in advance<br />
* Allow the administrator to write a policy that only allows expected and desirable access requests<br />
Unlike AppArmor, TOMOYO Linux is intended to protect the whole system from attackers exploiting vulnerabilities in applications. TOMOYO Linux addresses this threat by recording the behaviour of all applications in the test environment and then forcing all applications to act within these recorded behaviours in the production environment.<br />
<br />
TOMOYO Linux is not for users wanting ready-made policy files supplied by others. It involves creating policy from scratch, aided by the "learning mode" which can automatically generate policy files with necessary and sufficient permissions for a specific system. TOMOYO Linux reports what is happening within the Linux system and can therefore be used as a system analysis tool. It resembles strace and reports what is being executed by each program and what files/networks are accessed.<br />
<br />
This [http://tomoyo.sourceforge.jp/wiki-e/?WhatIs#comparison table] provides a comprehensive comparison of TOMOYO Linux with [[AppArmor]], [[SELinux]] and [http://schaufler-ca.com/ SMACK].<br />
<br />
==Branches of development==<br />
[http://tomoyo.sourceforge.jp/1.8/index.html.en TOMOYO Linux 1.x] is the original branch of development. TOMOYO Linux was first released on 11th November 2005. It was implemented as a patch that can be applied to the Linux kernel and is still in active development. It can coexist with other security modules such as SELinux, SMACK and AppArmor.<br />
<br />
[http://tomoyo.sourceforge.jp/2.3/index.html.en TOMOYO Linux 2.x] is the Linux mainline kernel branch of development. In June 2009, TOMOYO was merged into the Linux kernel version 2.6.30 and it uses standard Linux Security Module (LSM) hooks. However, the LSM hooks must be extended further in order to port the full MAC functionality of TOMOYO Linux into the Linux kernel. Thus, it does not yet provide equal functionality with the 1.x branch of development. This [http://tomoyo.sourceforge.jp/comparison.html.en chart] compares the differences between each branch.<br />
<br />
[http://akari.sourceforge.jp/ AKARI] is based on the TOMOYO Linux 1.x branch and is implemented as a Loadable Kernel Module (LKM). It therefore has the advantage of not requiring the user to patch and recompile the kernel. This [http://akari.sourceforge.jp/comparison.html table] provides a comprehensive comparison of AKARI with the TOMOYO Linux 1.x and 2.x branches.<br />
<br />
==TOMOYO Linux Repository==<br />
An [[Unofficial_User_Repositories|unofficial user repository]] has been made available that has all the necessary packages, including patched versions of kernel26 and kernel26-lts for both i686 and x86_64. The repository can be browsed at [http://repo.tomoyolinux.co.uk repo.tomoyolinux.co.uk]. Add the following to the top of "/etc/pacman.conf":<br />
<br />
<pre><br />
[tomoyo]<br />
Server = http://repo.tomoyolinux.co.uk/archlinux/$arch<br />
</pre><br />
<br />
Currently this repository includes versions of util-linux and mkinitcpio that are in [testing], so the entry must precede all other repositories in your "/etc/pacman.conf". Once these packages have been pushed to [core] then the tomoyo entry can be moved to the bottom.<br />
<br />
Forum thread can be found [https://bbs.archlinux.org/viewtopic.php?id=114075 here].<br />
<br />
==TOMOYO Linux 1.x==<br />
Implementing TOMOYO Linux 1.x using a kernel patched with ccs-patch provides the full functionality obtainable from the TOMOYO Linux project. However, implementation of this branch requires the most hurdles to be overcome, as the kernel must be patched with [http://sourceforge.jp/projects/tomoyo/ ccs-patch] and subsequently recompiled.<br />
<br />
Both kernel26-ccs and the userspace tools must be installed. A package for [http://aur.archlinux.org/packages.php?ID=44131 kernel-ccs] and a package for [http://aur.archlinux.org/packages.php?ID=42606 ccs-tools] are available on the AUR.<br />
<br />
Binary packages are available in the [[#TOMOYO Linux Repository|[tomoyo] repository]].<br />
<br />
===Initializing configuration===<br />
The policy must first be initialized:<br />
# /usr/lib/ccs/init_policy<br />
The policy files are saved in the /etc/css/ directory and can be edited by running:<br />
# ccs-editpolicy<br />
<br />
==AKARI==<br />
===Limitations of AKARI===<br />
AKARI has the advantage of not requiring kernel recompilation. If using the TOMOYO Linux project purely for system analysis, then AKARI is the easiest method of achieving this. If using the TOMOYO Linux project for system restriction, it is a minimal effort way to gain most of the functionality of the TOMOYO Linux 1.x branch. However, there are a few limitations that must be considered:<br />
* It depends on the kernel version and configuration provided by the distribution:<br />
<pre><br />
CONFIG_SECURITY=y [required]<br />
CONFIG_KALLSYMS=y [required]<br />
CONFIG_PROC_FS=y [required]<br />
CONFIG_MODULES=y [required]<br />
CONFIG_SECURITY_PATH=y [optional: for using absolute pathnames]<br />
CONFIG_SECURITY_NETWORK=y [optional: for providing network restriction]<br />
</pre><br />
* The restriction of a few advanced networking operations are limited or unavailable due to the absence of required LSM hooks<br />
* Restricting use of [http://en.wikipedia.org/wiki/Capability-based_security capabilities] is not possible<br />
* Looking up per-task variables is slower as they are managed outside "struct task_struct" in order to keep KABI unchanged. However, this should not be noticeable for the typical end-user as performance decrease by pathname based permission checking is dominant<br />
This [http://akari.sourceforge.jp/comparison.html table] provides a comprehensive comparison of AKARI with the TOMOYO Linux 1.x and 2.x branches.<br />
<br />
{{Note|The Arch Linux kernel from 2.6.36 onwards provides all of the configuration options required for full functionality.}}<br />
<br />
===Installation===<br />
Both AKARI and the userspace tools must be installed. A package for [http://aur.archlinux.org/packages.php?ID=42608 AKARI] and a package for [http://aur.archlinux.org/packages.php?ID=42606 ccs-tools] are available on the AUR.<br />
<br />
The bootloader configuration must be changed in order to activate AKARI:<br />
title Arch Linux<br />
root (hd0,0)<br />
kernel /boot/vmlinuz26 root=/dev/sda1 ro init=/sbin/ccs-init<br />
initrd /boot/kernel26.img<br />
<br />
Binary packages are available in the [[#TOMOYO Linux Repository|[tomoyo] repository]].<br />
<br />
===Initializing configuration===<br />
The policy must first be initialized:<br />
# /usr/lib/ccs/init_policy --module_name=akari<br />
The policy files are saved in the /etc/css/ directory and can be edited by running:<br />
# ccs-editpolicy<br />
<br />
==TOMOYO Linux 2.x==<br />
===Limitations of TOMOYO Linux 2.x===<br />
The implementation of TOMOYO Linux 2.x into the Linux mainline kernel is not yet complete but is still effective for MAC of files. It does not yet support the restriction of:<br />
* file attribute and namespace manipulation<br />
* capabilities<br />
* network<br />
* signal<br />
* environment variables<br />
* local port reservation<br />
This [http://tomoyo.sourceforge.jp/comparison.html.en chart] has a more comprehensive comparison of the differences between each branch of development.<br />
<br />
===Installation===<br />
TOMOYO Linux 2.x is part of the Linux mainline kernel and, in addition to those previously mentioned, requires the following kernel configuration:<br />
CONFIG_SECURITY_TOMOYO=y<br />
{{note|The Arch Linux kernel from 2.6.36 onwards provides all of the configuration options required for full functionality.}}<br />
<br />
If the kernel supports TOMOYO Linux 2.x, then only the userspace tools need to be installed. <br />
* For kernel versions between 2.6.30 and 2.6.35, tomoyo-tools 2.2.x should be installed. A package is available on the [http://aur.archlinux.org/packages.php?ID=42272 AUR]<br />
* For kernel versions 2.6.36 and above, tomoyo-tools 2.3.x should be installed. A package is available on the [http://aur.archlinux.org/packages.php?ID=39931 AUR]<br />
<br />
Binary packages are available in the [[#TOMOYO Linux Repository|[tomoyo] repository]].<br />
<br />
===Initializing configuration===<br />
The policy must first be initialized:<br />
# /usr/lib/tomoyo/init_policy<br />
The policy files are saved in the /etc/tomoyo/ directory and can be edited by running:<br />
# tomoyo-editpolicy<br />
<br />
==Usage==<br />
It is important to consult the relevant documentation in order to use TOMOYO Linux or AKARI effectively:<br />
* [http://tomoyo.sourceforge.jp/documentation.html.en TOMOYO Linux documentation]<br />
* [http://tomoyo.sourceforge.jp/1.8-tmp 90% complete rewrite of 1.8.x documentation] (not yet officially announced)<br />
* [http://akari.sourceforge.jp/index.html.en AKARI documentation]<br />
Run the policy editor to begin editing. If using TOMOYO Linux 1.x or AKARI then ccs-tools should be used:<br />
# /usr/sbin/ccs-editpolicy<br />
If using TOMOYO Linux 2.x then tomoyo-tools should be used:<br />
# /usr/sbin/tomoyo-editpolicy<br />
As the system runs, TOMOYO Linux will create domains and add them to the tree. The access analysis/restriction in TOMOYO Linux is applied via domains. Every process belongs to a single domain and the process will transit to a different domain whenever it executes a program. The name of a domain is a concatenated string expression for the process execution history. For example, the name of the domain which the kernel belongs to is "<kernel>"; the name of domain which /sbin/init invoked by the kernel belongs to is "<kernel> /sbin/init"; if /sbin/init invokes /etc/rc.d/rc then the domain it belongs to is "<kernel> /sbin/init /etc/rc.d/rc". You can suppress or initialize domain transitions as needed.<br />
<br />
Profiles can be assigned to each domain. There are four default profiles:<br />
<br />
{| border="1"<br />
| Disabled || Works as if regular kernel.<br />
|-<br />
| Learning || Do not reject an access request if it violates policy. Append the request to policy.<br />
|-<br />
| Permissive || Do not reject an access request if it violates policy. Do not append the request to policy.<br />
|-<br />
| Enforcing || Reject an access request if it violates policy. Do not append the request to policy.<br />
|}<br />
The learning profile can be used to analyse the system or a specific application. Once all of the desired access requests of a domain have been identified, the policy for that domain can be edited as required before selecting the enforcing profile. This can be done for any and all domains from the start of system boot.<br />
<br />
==References==<br />
* [http://tomomyo.sourceforge.jp/ TOMOYO Linux SourceForge page]<br />
* [http://tomoyo.sourceforge.jp/wiki-e/ TOMOYO Linux Wiki]<br />
* [http://akari.sourceforge.jp/index.html.en AKARI SourceForge page]<br />
* [http://akari.sourceforge.jp/index.html.en AKARI documentation]<br />
* [http://tomoyo.sourceforge.jp/1.8/index.html.en TOMOYO Linux 1.8.x documentation]<br />
* [http://tomoyo.sourceforge.jp/2.3/index.html.en TOMOYO Linux 2.3.x documentation]<br />
* [http://lwn.net/Articles/263179/ TOMOYO Linux Security Goal]<br />
* [http://tomoyo.sourceforge.jp/cgi-bin/lxr/source/etch/domain_policy.conf?v=policy-sample Policy sample]<br />
* [http://elinux.org/TomoyoLinux TOMOYO Linux on the Embedded Linux Wiki]<br />
* [http://sourceforge.jp/projects/tomoyo/document/PacSec2007-en-demo.pdf Presentation slides from PacSec 2007]<br />
<br />
==See also==<br />
* [[AppArmor]]<br />
* [[SELinux]]</div>Jnguyenhttps://wiki.archlinux.org/index.php?title=TOMOYO_Linux&diff=131928TOMOYO Linux2011-02-24T15:04:30Z<p>Jnguyen: TOMOYO Linux Repository</p>
<hr />
<div>[[Category:Security (English)]]<br />
[[Category:Kernel (English)]]<br />
[[Category:Networking (English)]]<br />
[[Category:HOWTOs (English)]]<br />
[http://tomoyo.sourceforge.jp/ TOMOYO Linux] is Mandatory Access Control (MAC) implementation for Linux. It was launched in March 2003 and is sponsored by [http://www.nttdata.co.jp/en/ NTT Data Corporation]. TOMOYO Linux focuses on the behaviour of a system, allowing each process to declare behaviours and resources needed to achieve its purpose. It can be used as a system analysis tool as well as an access restriction tool.<br />
<br />
The security goal of TOMOYO Linux is to provide "MAC that covers practical requirements for most users and keeps usable for most administrators". TOMOYO Linux is not a tool or security professional but for average users and administrators.<br />
{{Note|This article does not aim to be an exhaustive guide and should be used as a supplement to the extensive [http://tomoyo.sourceforge.jp/documentation.html user documentation] provided by the project.}}<br />
{{Tip|[[#TOMOYO Linux Repository|Pre-built binaries]] for all TOMOYO Linux packages are available, including patched versions of kernel26 and kernel26-lts. AKARI is a Linux Kernel Module so is useful for custom kernels like kernel26-ck and kernel26-pf. TOMOYO Linux 2.x branch is already integrated into the mainline kernel and is the easiest of the three to set up, but it only offers a subset of functionality at the present time.}}<br />
<br />
==Introduction==<br />
TOMOYO Linux attempts to make the system where everything is prearranged in an easy to understand way:<br />
* Make all access requests that will occur at least once during the lifetime of the kernel known in advance<br />
* Allow the administrator to write a policy that only allows expected and desirable access requests<br />
Unlike AppArmor, TOMOYO Linux is intended to protect the whole system from attackers exploiting vulnerabilities in applications. TOMOYO Linux addresses this threat by recording the behaviour of all applications in the test environment and then forcing all applications to act within these recorded behaviours in the production environment.<br />
<br />
TOMOYO Linux is not for users wanting ready-made policy files supplied by others. It involves creating policy from scratch, aided by the "learning mode" which can automatically generate policy files with necessary and sufficient permissions for a specific system. TOMOYO Linux reports what is happening within the Linux system and can therefore be used as a system analysis tool. It resembles strace and reports what is being executed by each program and what files/networks are accessed.<br />
<br />
This [http://tomoyo.sourceforge.jp/wiki-e/?WhatIs#comparison table] provides a comprehensive comparison of TOMOYO Linux with [[AppArmor]], [[SELinux]] and [http://schaufler-ca.com/ SMACK].<br />
<br />
==Branches of development==<br />
[http://tomoyo.sourceforge.jp/1.8/index.html.en TOMOYO Linux 1.x] is the original branch of development. TOMOYO Linux was first released on 11th November 2005. It was implemented as a patch that can be applied to the Linux kernel and is still in active development. It can coexist with other security modules such as SELinux, SMACK and AppArmor.<br />
<br />
[http://tomoyo.sourceforge.jp/2.3/index.html.en TOMOYO Linux 2.x] is the Linux mainline kernel branch of development. In June 2009, TOMOYO was merged into the Linux kernel version 2.6.30 and it uses standard Linux Security Module (LSM) hooks. However, the LSM hooks must be extended further in order to port the full MAC functionality of TOMOYO Linux into the Linux kernel. Thus, it does not yet provide equal functionality with the 1.x branch of development. This [http://tomoyo.sourceforge.jp/comparison.html.en chart] compares the differences between each branch.<br />
<br />
[http://akari.sourceforge.jp/ AKARI] is based on the TOMOYO Linux 1.x branch and is implemented as a Loadable Kernel Module (LKM). It therefore has the advantage of not requiring the user to patch and recompile the kernel. This [http://akari.sourceforge.jp/comparison.html table] provides a comprehensive comparison of AKARI with the TOMOYO Linux 1.x and 2.x branches.<br />
<br />
==TOMOYO Linux Repository==<br />
An [[Unofficial_User_Repositories|unofficial user repository]] has been made available that has all the necessary packages, including patched versions of kernel26 and kernel26-lts for both i686 and x86_64. The repository can be browsed at [http://repo.tomoyolinux.co.uk repo.tomoyolinux.co.uk]. Add the following to the top of "/etc/pacman.conf":<br />
<br />
<pre><br />
[tomoyo]<br />
Server = http://repo.tomoyolinux.co.uk/archlinux/$arch<br />
</pre><br />
<br />
Currently this repository includes versions of util-linux and mkinitcpio that are in [testing], so the entry must precede all other repositories in your "/etc/pacman.conf". Once these packages have been pushed to [core] then the tomoyo entry can be moved to the bottom.<br />
<br />
==TOMOYO Linux 1.x==<br />
Implementing TOMOYO Linux 1.x using a kernel patched with ccs-patch provides the full functionality obtainable from the TOMOYO Linux project. However, implementation of this branch requires the most hurdles to be overcome, as the kernel must be patched with [http://sourceforge.jp/projects/tomoyo/ ccs-patch] and subsequently recompiled.<br />
<br />
Both kernel26-ccs and the userspace tools must be installed. A package for [http://aur.archlinux.org/packages.php?ID=44131 kernel-ccs] and a package for [http://aur.archlinux.org/packages.php?ID=42606 ccs-tools] are available on the AUR.<br />
<br />
Binary packages are available in the [[#TOMOYO Linux Repository|[tomoyo] repository]].<br />
<br />
===Initializing configuration===<br />
The policy must first be initialized:<br />
# /usr/lib/ccs/init_policy<br />
The policy files are saved in the /etc/css/ directory and can be edited by running:<br />
# ccs-editpolicy<br />
<br />
==AKARI==<br />
===Limitations of AKARI===<br />
AKARI has the advantage of not requiring kernel recompilation. If using the TOMOYO Linux project purely for system analysis, then AKARI is the easiest method of achieving this. If using the TOMOYO Linux project for system restriction, it is a minimal effort way to gain most of the functionality of the TOMOYO Linux 1.x branch. However, there are a few limitations that must be considered:<br />
* It depends on the kernel version and configuration provided by the distribution:<br />
<pre><br />
CONFIG_SECURITY=y [required]<br />
CONFIG_KALLSYMS=y [required]<br />
CONFIG_PROC_FS=y [required]<br />
CONFIG_MODULES=y [required]<br />
CONFIG_SECURITY_PATH=y [optional: for using absolute pathnames]<br />
CONFIG_SECURITY_NETWORK=y [optional: for providing network restriction]<br />
</pre><br />
* The restriction of a few advanced networking operations are limited or unavailable due to the absence of required LSM hooks<br />
* Restricting use of [http://en.wikipedia.org/wiki/Capability-based_security capabilities] is not possible<br />
* Looking up per-task variables is slower as they are managed outside "struct task_struct" in order to keep KABI unchanged. However, this should not be noticeable for the typical end-user as performance decrease by pathname based permission checking is dominant<br />
This [http://akari.sourceforge.jp/comparison.html table] provides a comprehensive comparison of AKARI with the TOMOYO Linux 1.x and 2.x branches.<br />
<br />
{{Note|The Arch Linux kernel from 2.6.36 onwards provides all of the configuration options required for full functionality.}}<br />
<br />
===Installation===<br />
Both AKARI and the userspace tools must be installed. A package for [http://aur.archlinux.org/packages.php?ID=42608 AKARI] and a package for [http://aur.archlinux.org/packages.php?ID=42606 ccs-tools] are available on the AUR.<br />
<br />
The bootloader configuration must be changed in order to activate AKARI:<br />
title Arch Linux<br />
root (hd0,0)<br />
kernel /boot/vmlinuz26 root=/dev/sda1 ro init=/sbin/ccs-init<br />
initrd /boot/kernel26.img<br />
<br />
Binary packages are available in the [[#TOMOYO Linux Repository|[tomoyo] repository]].<br />
<br />
===Initializing configuration===<br />
The policy must first be initialized:<br />
# /usr/lib/ccs/init_policy --module_name=akari<br />
The policy files are saved in the /etc/css/ directory and can be edited by running:<br />
# ccs-editpolicy<br />
<br />
==TOMOYO Linux 2.x==<br />
===Limitations of TOMOYO Linux 2.x===<br />
The implementation of TOMOYO Linux 2.x into the Linux mainline kernel is not yet complete but is still effective for MAC of files. It does not yet support the restriction of:<br />
* file attribute and namespace manipulation<br />
* capabilities<br />
* network<br />
* signal<br />
* environment variables<br />
* local port reservation<br />
This [http://tomoyo.sourceforge.jp/comparison.html.en chart] has a more comprehensive comparison of the differences between each branch of development.<br />
<br />
===Installation===<br />
TOMOYO Linux 2.x is part of the Linux mainline kernel and, in addition to those previously mentioned, requires the following kernel configuration:<br />
CONFIG_SECURITY_TOMOYO=y<br />
{{note|The Arch Linux kernel from 2.6.36 onwards provides all of the configuration options required for full functionality.}}<br />
<br />
If the kernel supports TOMOYO Linux 2.x, then only the userspace tools need to be installed. <br />
* For kernel versions between 2.6.30 and 2.6.35, tomoyo-tools 2.2.x should be installed. A package is available on the [http://aur.archlinux.org/packages.php?ID=42272 AUR]<br />
* For kernel versions 2.6.36 and above, tomoyo-tools 2.3.x should be installed. A package is available on the [http://aur.archlinux.org/packages.php?ID=39931 AUR]<br />
<br />
Binary packages are available in the [[#TOMOYO Linux Repository|[tomoyo] repository]].<br />
<br />
===Initializing configuration===<br />
The policy must first be initialized:<br />
# /usr/lib/tomoyo/init_policy<br />
The policy files are saved in the /etc/tomoyo/ directory and can be edited by running:<br />
# tomoyo-editpolicy<br />
<br />
==Usage==<br />
It is important to consult the relevant documentation in order to use TOMOYO Linux or AKARI effectively:<br />
* [http://tomoyo.sourceforge.jp/documentation.html.en TOMOYO Linux documentation]<br />
* [http://tomoyo.sourceforge.jp/1.8-tmp 90% complete rewrite of 1.8.x documentation] (not yet officially announced)<br />
* [http://akari.sourceforge.jp/index.html.en AKARI documentation]<br />
Run the policy editor to begin editing. If using TOMOYO Linux 1.x or AKARI then ccs-tools should be used:<br />
# /usr/sbin/ccs-editpolicy<br />
If using TOMOYO Linux 2.x then tomoyo-tools should be used:<br />
# /usr/sbin/tomoyo-editpolicy<br />
As the system runs, TOMOYO Linux will create domains and add them to the tree. The access analysis/restriction in TOMOYO Linux is applied via domains. Every process belongs to a single domain and the process will transit to a different domain whenever it executes a program. The name of a domain is a concatenated string expression for the process execution history. For example, the name of the domain which the kernel belongs to is "<kernel>"; the name of domain which /sbin/init invoked by the kernel belongs to is "<kernel> /sbin/init"; if /sbin/init invokes /etc/rc.d/rc then the domain it belongs to is "<kernel> /sbin/init /etc/rc.d/rc". You can suppress or initialize domain transitions as needed.<br />
<br />
Profiles can be assigned to each domain. There are four default profiles:<br />
<br />
{| border="1"<br />
| Disabled || Works as if regular kernel.<br />
|-<br />
| Learning || Do not reject an access request if it violates policy. Append the request to policy.<br />
|-<br />
| Permissive || Do not reject an access request if it violates policy. Do not append the request to policy.<br />
|-<br />
| Enforcing || Reject an access request if it violates policy. Do not append the request to policy.<br />
|}<br />
The learning profile can be used to analyse the system or a specific application. Once all of the desired access requests of a domain have been identified, the policy for that domain can be edited as required before selecting the enforcing profile. This can be done for any and all domains from the start of system boot.<br />
<br />
==References==<br />
* [http://tomomyo.sourceforge.jp/ TOMOYO Linux SourceForge page]<br />
* [http://tomoyo.sourceforge.jp/wiki-e/ TOMOYO Linux Wiki]<br />
* [http://akari.sourceforge.jp/index.html.en AKARI SourceForge page]<br />
* [http://akari.sourceforge.jp/index.html.en AKARI documentation]<br />
* [http://tomoyo.sourceforge.jp/1.8/index.html.en TOMOYO Linux 1.8.x documentation]<br />
* [http://tomoyo.sourceforge.jp/2.3/index.html.en TOMOYO Linux 2.3.x documentation]<br />
* [http://lwn.net/Articles/263179/ TOMOYO Linux Security Goal]<br />
* [http://tomoyo.sourceforge.jp/cgi-bin/lxr/source/etch/domain_policy.conf?v=policy-sample Policy sample]<br />
* [http://elinux.org/TomoyoLinux TOMOYO Linux on the Embedded Linux Wiki]<br />
* [http://sourceforge.jp/projects/tomoyo/document/PacSec2007-en-demo.pdf Presentation slides from PacSec 2007]<br />
<br />
==See also==<br />
* [[AppArmor]]<br />
* [[SELinux]]</div>Jnguyenhttps://wiki.archlinux.org/index.php?title=Unofficial_user_repositories&diff=131927Unofficial user repositories2011-02-24T15:04:23Z<p>Jnguyen: /* Both i686 and x86_64 */ TOMOYO Linux Repository</p>
<hr />
<div>[[Category: Package management (English)]]<br />
==Why unofficial user repositories==<br />
Since the AUR only allows users to upload PKGBUILD and other package build related files, but does not provide a means for distributing a binary package, a user may want to create a binary repository of their packages elsewhere.<br />
<br />
==The future of Unofficial repos==<br />
I'd like to see more work of this type. Sometimes there are certain projects that don't mesh well with other things, such as the community repo. The 'kdemod' project is a good example. If you want to contribute with your own builds, you can check page [[Custom local repository]].<br />
<br />
In the future, well-thought-out user repositories may be ideal for lots of supplementary things. Forming a "web of trust" is important in cases like this, so we may begin keeping a list of "recommended" repositories somewhere, in order to make it seem more official and trustworthy.<br />
<br />
[[User:Phrakture|Phrakture]] 12:50, 18 May 2007 (EDT)<br />
<br />
== The community repository, maintained by the TUs==<br />
The community repository is included in pacman's default configuration.<br />
<br />
[community]<br />
Include = /etc/pacman.d/mirrorlist<br />
<br />
==List of PUR (unofficial user repositories)==<br />
===Any===<br />
"Any" repos are architecture-independent, i.e. they can be used on both i686 and x86_64 systems.<br />
<pre><br />
[herecura-stable-any]<br />
# Just some stuff; a few java apps, wallpapers, small scripts, xbmc-skin<br />
Server = http://herecura.be/repo/herecura-stable/any<br />
<br />
[herecura-testing-any]<br />
# Some any testing stuff, xbmc-svn skin<br />
Server = http://herecura.be/repo/herecura-testing/any<br />
<br />
[xyne-any]<br />
# The home of Powerpill and Xyne's other contributions.<br />
# More info including a package list can be found at http://xyne.archlinux.ca/repos<br />
Server = http://xyne.archlinux.ca/repos/xyne-any/<br />
</pre><br />
<br />
===Both i686 and x86_64===<br />
<!--Not exactly same as 'any' repositories, this section should probably be separate.--><br />
Repositories with both i686 and x86_64 versions. The $arch variable will be set automatically by pacman.<br />
<pre><br />
[archlinuxfr]<br />
# The french Arch Linux communities packages.<br />
Server = http://repo.archlinux.fr/$arch<br />
<br />
[archaudio-stable]<br />
# and/or *-testing, *-experimental<br />
# Pro-audio repo:<br />
# - http://archaudio.org<br />
# Replace "stable" with repo type (testing/experimental).<br />
Server = http://repos.archaudio.org/stable/$arch<br />
<br />
[archstuff]<br />
# AUR's most voted and many bin32-* and lib32-* packages.<br />
Server = http://archstuff.vs169092.vserver.de/$arch<br />
<br />
[arch-games]<br />
# The Arch Linux Gaming repository project.<br />
# Active mirrors listed in https://github.com/Arch-Games/arch-games/wiki/Mirrors<br />
Server = http://repo.exigen.org/arch/games/$arch<br />
Server = ftp://mirror.selfnet.de/arch-games/$arch<br />
# Currently inactive mirrors<br />
#Server = http://arch.twilightlair.net/games/$arch<br />
#Server = http://pseudoform.org/arch-games/games/$arch<br />
<br />
[burg]<br />
# Burg bootloader repo<br />
# More info : http://archydeb.wordpress.com/<br />
Server = http://dl.dropbox.com/u/11529444/$arch<br />
<br />
[cake]<br />
# Crapkit, dbus, hal, etc. stripped packages compatible with Arch Linux (from http://hereticlinux.org/).<br />
Server = http://hereticlinux.org/repo/cake/$arch<br />
<br />
[catalyst]<br />
# ATI Catalyst proprietary drivers.<br />
Server = http://catalyst.apocalypsus.net/repo/catalyst/$arch<br />
<br />
[pfkernel]<br />
# Kernel packages: generic i686 and x86_64, optimized P3, P4, K7, Atom, Pentium-M, K8, Core2<br />
# nvidia-pf, squid3, arora-git, nvidia-utils-beta<br />
Server = http://dl.dropbox.com/u/11734958/$arch<br />
<br />
[radeon]<br />
# ATI Radeon X.Org drivers, bleeding edge 'git' builds.<br />
Server = http://spiralinear.org/perry3d/$arch<br />
<br />
[sergej-repo]<br />
# ion3 and some other stuff.<br />
# http://code.google.com/p/archlinux-stuff/source/browse/trunk<br />
Server = http://repo.p5n.pp.ru/sergej-repo/$arch/<br />
<br />
[suckless]<br />
# suckless.org packages<br />
Server = http://dl.suckless.org/arch/$arch<br />
<br />
[tomoyo]<br />
# TOMOYO Linux kernels, modules and userspace tools<br />
Server = http://repo.tomoyolinux.co.uk/archlinux/$arch<br />
<br />
[unarch]<br />
# Offers support mainly against devel packages.<br />
# Contains stable packages that aren't in official repo.<br />
Server = http://us4all.info/unarch/arch/$arch<br />
<br />
[kittyserve]<br />
# Contains kittykatt's packages and packages from friends of kittykatt, as well as most mint-related packages<br />
Server = http://repo.kattz.tk/$arch<br />
</pre><br />
<br />
===i686 only===<br />
<pre><br />
[adslgr32]<br />
# The Hellenic (Greek) Arch Linux unofficial repository with many interesting packages.<br />
Server = http://archlinuxgr.tiven.org/archlinux/i686/<br />
<br />
[kde4-eyecandy-32]<br />
# Useful and beautiful plasmoids and themes for KDE4.<br />
Server = http://archlinuxgr.tiven.org/kde4-eyecandy/i686/<br />
<br />
[andrwe]<br />
# For a list of packages see: http://andrwe.org/doku.php/blog/linux/repository<br />
Server = http://repo.andrwe.org/i686<br />
<br />
[archlinux-es]<br />
# Repositorio Hispano (Spanish/Hispanic Respository).<br />
Server = http://repo.archlinux-es.org/i686<br />
<br />
[arch-graphics]<br />
# Repository aimed to provide applications mainly for 3D graphics.<br />
# For more info, look at http://arch-graphics.kx.cz/<br />
Server = http://arch-graphics.kx.cz/repo/i686<br />
<br />
[cgr-i686]<br />
# Packages for some ChicoGeek's PKGBUILDs.<br />
Server = http://cgr.i686.googlepages.com/<br />
<br />
[chaox-stable]<br />
# Pentesting packages and custom kernel patched for WIFI injection.<br />
Server = http://repo.chaox.net/stable<br />
<br />
[compiz-fusion]<br />
# compiz-fusion-git<br />
# Updated to June 2008.<br />
Server = http://compiz.dreamz-box.de/i686<br />
<br />
[cinan]<br />
# Contains packages which aren't in official repos.<br />
# Information at cinan.tk or cinan6.tk<br />
Server = http://cinan.yw.sk/i686<br />
<br />
[dragonlord]<br />
# Mixed packages, I don't want to move into [community],<br />
# but are worth having them or the build time is long.<br />
Server = http://repo.dragonlord.cz/arch/i686<br />
<br />
[englab]<br />
# Packages of englab (mathematical programs), its toolboxes and dependencies.<br />
Server = http://englab.bugfest.net/arch/i686<br />
<br />
[esclinux]<br />
# Mostly games, interactive fiction and abc notation stuffs already on AUR.<br />
Server = http://download.tuxfamily.org/esclinuxcd/ressources/repo/i686/<br />
<br />
[fukawi]<br />
# Some Nagios Stuff; molly-guard; celtx and various networking tools.<br />
Server = http://repo.fukawi2.nl/i686/<br />
Server = ftp://repo.fukawi2.nl/i686/<br />
<br />
[jose1711repo]<br />
# Most of the packages I maintain in AUR (games, tools)<br />
Server = http://arch.l33t.in/i686/<br />
<br />
[kdemod-core]<br />
# Provides core KDE 4.x packages.<br />
# Requires Arch community repository which provides additional packages.<br />
Server = http://chakra-project.org/repo/kdemod-core/i686<br />
Server = http://archlinux.puzzle.ch/kdemod/core/i686<br />
Server = ftp://ftp.wh-stuttgart.net/kdemod/core/i686<br />
<br />
[kdemod-extragear]<br />
# Provides additional KDE 4.x packages.<br />
Server = http://chakra-project.org/repo/kdemod-extragear/i686<br />
<br />
[kpiche]<br />
# Stable OpenSync packages.<br />
Server = http://kpiche.archlinux.ca/repo<br />
<br />
[pst]<br />
# Painters Studio and support packages (http://pst.brankovukelic.com/).<br />
Server = http://pst.brankovukelic.com/i686<br />
<br />
[rfad]<br />
# Repository made by haxit | Contact at: requiem [at] archlinux.us for package suggestions!<br />
Server = http://web.ncf.ca/ey723/archlinux/repo/<br />
<br />
[xdemon-repo]<br />
# madwimax, kismet-svn and aircrack-svn, etc...<br />
Server=http://repo.x-demon.org/archlinux/os/i686<br />
<br />
[nightly]<br />
# Nightly builds of some packages from the AUR.<br />
# Repo-Tracker: http://tracker.kromonos.net/projects/show/nightlyarch<br />
Server = http://nightly.uhuc.de/i686<br />
<br />
[pozitpoh]<br />
# Fresh psi-plus, kvirc4, urtconnector, xneur, etc.<br />
Server = http://pozitpoh.is-a-geek.org/repo/i686<br />
<br />
[herecura-stable]<br />
# Additional apps not found in community.<br />
Server = http://herecura.be/repo/herecura-stable/i686<br />
<br />
[herecura-testing]<br />
# Additional apps for testing build against stable Arch.<br />
Server = http://herecura.be/repo/herecura-testing/i686<br />
<br />
[studioidefix]<br />
# Precompiled boxee packages.<br />
Server = http://studioidefix.googlecode.com/hg/repo/i686<br />
<br />
[mingw32]<br />
# Libs & tools for crosscompiling for Win32, mainly taken from AUR.<br />
# Contact: Alexander 'hatred' Drozdov <adrozdoff [at] gmail (dot) com> (Russian-speaked guys can write on Russian :-)<br />
Server = http://hatred.homelinux.net/archlinux/mingw32/os/i686<br />
<br />
[jrepo]<br />
# Random pkgs for my friends low-end and old laptop.<br />
# These pkgs are optimzed for pentium-m (i686 + sse2).<br />
# All pks that support pulseaudio have been natively complied to include it.<br />
# http://dl.dropbox.com/u/3422289/README list of pkgs and info<br />
Server = http://dl.dropbox.com/u/3422289<br />
<br />
[kernel-panic]<br />
# A various set of useful packages, including (but not limited to) opera, falconpl and kpackagekit<br />
Server = http://kernel-panic.dnsdojo.net/arch/i686<br />
<br />
[ballo]<br />
# Ubuntu theme, Ayatana indicators and Notify OSD,<br />
# GNOME apps (Conduit, GNOME Packagekit, Gnome Subtitles, Rygel…),<br />
# mapping apps (JOSM, Merkaartor, Navit, Viking…),<br />
# some other apps (ConnMan, Gwibber, KompoZer, onBoard…).<br />
# More info: http://arch.ballogyorgy.com/<br />
Server = http://arch.ballogyorgy.com/pkg/<br />
</pre><br />
<br />
===x86_64 only===<br />
<pre><br />
[kde4-eyecandy-64]<br />
# Useful and beautiful plasmoids and themes for KDE4.<br />
Server = http://archlinuxgr.tiven.org/kde4-eyecandy/x86_64/<br />
<br />
[adslgr64]<br />
# The Hellenic (Greek) archlinux unofficial repository with many interesting packages.<br />
Server = http://archlinuxgr.tiven.org/archlinux/x86_64/<br />
<br />
[andrwe]<br />
# For a list of packages see: http://andrwe.dyndns.org/doku.php/blog/repository<br />
Server = http://repo.andrwe.org/x86_64<br />
<br />
[archlinux-es]<br />
# Repositorio Hispano (Spanish/Hispanic Respository).<br />
Server = http://repo.archlinux-es.org/x86_64<br />
<br />
[archlinuxve]<br />
# Home of the splashy packages.<br />
Server = http://repo.archlinux.com.ve/x86_64<br />
<br />
[compiz-fusion]<br />
# compiz-fusion-git<br />
Server = http://compiz.dreamz-box.de/x86_64<br />
<br />
[cinan]<br />
# Contains packages which aren't in official repos.<br />
# Information at cinan.tk or cinan6.tk<br />
Server = http://cinan.yw.sk/x86_64<br />
<br />
[englab]<br />
# Packages of englab (mathematical programs), its toolboxes and dependencies.<br />
Server = http://englab.bugfest.net/arch/x86_64<br />
<br />
[kdemod-core]<br />
# Provides core KDE 4.x packages.<br />
# Requires Arch community repository which provides additional packages.<br />
Server = http://chakra-project.org/repo/core/x86_64<br />
Server = http://kdemod.iskrembilen.com/core/x86_64<br />
Server = http://archlinux.puzzle.ch/kdemod/core/x86_64<br />
Server = ftp://ftp.wh-stuttgart.net/kdemod/core/x86_64<br />
<br />
[kdemod-extragear]<br />
# Provides additional KDE 4.x packages.<br />
Server = http://chakra-project.org/repo/extragear/x86_64<br />
Server = http://kdemod.iskrembilen.com/extragear/x86_64<br />
Server = http://archlinux.puzzle.ch/kdemod/extragear/x86_64<br />
Server = ftp://ftp.wh-stuttgart.net/kdemod/extragear/x86_64<br />
<br />
[kdemod-playground]<br />
# Provides unstable packages for testing purposes.<br />
Server = http://chakra-project.org/repo/playground/x86_64<br />
Server = http://kdemod.iskrembilen.com/playground/x86_64<br />
Server = http://archlinux.puzzle.ch/kdemod/playground/x86_64<br />
Server = ftp://ftp.wh-stuttgart.net/kdemod/playground/x86_64<br />
<br />
[kdemod-legacy]<br />
# Provides KDE 3.5.x packages.<br />
# Requires Arch community repository which provides additional packages.<br />
Server = http://chakra-project.org/repo/legacy/x86_64<br />
<br />
[pst]<br />
# Painters Studio and support packages (http://pst.brankovukelic.com/)<br />
Server = http://pst.brankovukelic.com/x86_64<br />
<br />
[dstr-repo]<br />
# qutim, psi, kdevelop with plugins dev builds and other stuff.<br />
Server = http://dimon.homeftp.org/repo/x86_64<br />
<br />
[nightly]<br />
# Nightly builds of some packages from the AUR.<br />
# Repo-Tracker: http://tracker.kromonos.net/projects/show/nightlyarch<br />
Server = http://files.shadowice.org/nightly/x86_64<br />
<br />
[zen]<br />
# Various and zengeist' AUR packages.<br />
Server = http://zloduch.cz/archlinux/x86_64<br />
<br />
[digitalpioneer]<br />
# Recent GIT/SVN/whatever builds of selected AUR packages.<br />
# List of packages is at http://dl.getdropbox.com/u/453116/repo/pkglist and is subject to change.<br />
# x86_64 only.<br />
Server = http://dl.getdropbox.com/u/453116/repo<br />
<br />
[seiichiro]<br />
# VDR and some plugins, mms, foo2zjs-drivers<br />
Server = http://repo.seiichiro0185.org/x86_64<br />
<br />
[herecura-stable]<br />
# Additional apps not found in community.<br />
Server = http://herecura.be/repo/herecura-stable/x86_64<br />
<br />
[herecura-testing]<br />
# Additional apps for testing build against stable Arch.<br />
Server = http://herecura.be/repo/herecura-testing/x86_64<br />
<br />
[studioidefix]<br />
# Precompiled boxee packages.<br />
Server = http://studioidefix.googlecode.com/hg/repo/x86_64<br />
<br />
[pyropeter]<br />
# My AUR packages: http://aur.archlinux.org/packages.php?SeB=m&K=pyropeter<br />
Server = http://keks.selfip.org/arch/pyropeter<br />
</pre><br />
<br />
==Add your own repository to this list==<br />
If you have your own repository, please add this to this list, so that all other users knows where to find your packages.</div>Jnguyen