https://wiki.archlinux.org/api.php?action=feedcontributions&user=Fclad&feedformat=atomArchWiki - User contributions [en]2024-03-28T09:27:46ZUser contributionsMediaWiki 1.41.0https://wiki.archlinux.org/index.php?title=OpenDKIM&diff=342555OpenDKIM2014-10-31T19:37:57Z<p>Fclad: Added ipv6 loppback to TrustedHosts</p>
<hr />
<div>[[Category:Mail Server]]<br />
DomainKeys Identified Mail is a digital email signing/verification technology, which is already supported by some common mail providers (for example yahoo, google, etc).<br />
<br />
== The idea ==<br />
<br />
Basically DKIM means digitally signing all messages on the server to verify the message actually was sent from the domain in question and is not spam or pishing (and has not been modified).<br />
<br />
*The sender's mail server signs outgoing email with the private key.<br />
<br />
*When the message arrives, the receiver (or his server) requests the public key from the domain's DNS and verifies the signature.<br />
<br />
This ensures the message was sent from a server who's private key matches the domain's public key.<br />
<br />
For more info see [http://tools.ietf.org/html/rfc6376 RFC 6376]<br />
<br />
== Installation ==<br />
<br />
[[pacman|Install]] the package {{Pkg|opendkim}} from the [[Official repositories]]. Alternatively, you can build and install the {{AUR|opendkim-opendbx}} package from the [[AUR]] which adds opendbx support for communicating with several databases, including {{Pkg|mariadb}}, {{Pkg|postgresql}}, {{Pkg|sqlite}} and Firebird.<br />
<br />
== Basic configuration ==<br />
* To generate a secret signing key, you need to specify the domain used to send mails and a selector which is used to refer to the key. You may choose anything you like, see the RFC for details, but alpha-numeric strings should be OK:<br />
opendkim-genkey -r -s myselector -d example.com<br />
* Copy/move the sample configuration file {{ic|/etc/opendkim/opendkim.conf.sample}} to {{ic|/etc/opendkim/opendkim.conf}} and change the following options:<br />
{{hc|/etc/opendkim/opendkim.conf|<br />
Domain example.com<br />
KeyFile /path/to/keys/server1.private<br />
Selector myselector<br />
Socket inet:8891@localhost<br />
UserID opendkim<br />
}}<br />
<br />
* Add a '''DNS TXT''' record with your selector and public key. The correct record is generated with the private key and can be found in {{ic|myselector.txt}} in the same location as the private key. Example:<br />
myselector._domainkey IN TXT "v=DKIM1; k=rsa; s=email; p=...................."<br />
Check that your DNS record has been correctly updated:<br />
host -t TXT myselector._domainkey.example.com<br />
You may also check that your DKIM DNS record is properly formated using one of the DKIM Key checker available on the web.<br />
<br />
* Enable and start the {{ic|opendkim.service}}. Read [[Daemons]] for more information.<br />
<br />
== Postfix integration ==<br />
<br />
Either add the following lines to {{ic|main.cf}}:<br />
non_smtpd_milters=inet:127.0.0.1:8891<br />
smtpd_milters=inet:127.0.0.1:8891<br />
<br />
Or change smtpd options in {{ic|master.cf}}:<br />
smtp inet n - n - - smtpd<br />
-o smtpd_client_connection_count_limit=10<br />
-o smtpd_milters=inet:127.0.0.1:8891<br />
<br />
submission inet n - n - - smtpd<br />
-o smtpd_enforce_tls=no<br />
-o smtpd_sasl_auth_enable=yes<br />
-o smtpd_client_restrictions=permit_sasl_authenticated,reject<br />
-o smtpd_sasl_path=smtpd<br />
-o cyrus_sasl_config_path=/etc/sasl2<br />
-o smtpd_milters=inet:127.0.0.1:8891<br />
<br />
== Sendmail integration ==<br />
<br />
Edit the {{ic|sendmail.mc}} file and add the following line, '''after the last line''' starting with {{ic|FEATURE}}:<br />
<br />
{{hc|/etc/mail/sendmail.mc|<br />
<nowiki><br />
INPUT_MAIL_FILTER(`opendkim', `S=inet:8891@localhost')<br />
</nowiki><br />
}}<br />
<br />
Rebuild the {{ic|sendmail.cf}} file with:<br />
<br />
{{bc|# m4 /etc/mail/sendmail.mc > /etc/mail/sendmail.cf}}<br />
<br />
And then restart the sendmail.service. Read [[Daemons]] for more details.<br />
<br />
==Multiple Domains==<br />
If you're providing mail server service to multiple virtual domains on the same server, you'll need to modify the basic configuration as below:<br />
<br />
Provide these directives in /etc/opendkim/opendkim.conf<br />
KeyTable refile:/etc/opendkim/KeyTable<br />
SigningTable refile:/etc/opendkim/SigningTable<br />
ExternalIgnoreList refile:/etc/opendkim/TrustedHosts<br />
InternalHosts refile:/etc/opendkim/TrustedHosts<br />
<br />
Create these 2 files to tell opendkim where to find the correct keys. You can use the same key for all the domains or generate a key for each domain. Make changes to match your settings. Add more lines as needed.<br />
/etc/opendkim/KeyTable <br />
myselector._domainkey.example1.com example1.com:myselector:/etc/opendkim/myselector.private<br />
myselector._domainkey.example2.com example2.com:myselector:/etc/opendkim/myselector.private<br />
...<br />
<br />
/etc/opendkim/SigningTable<br />
*@example1.com myselector._domainkey.example1.com<br />
*@example2.com myselector._domainkey.example2.com<br />
...<br />
<br />
Create file /etc/opendkim/TrustedHosts tells opendkim who to let use your keys. This is referenced by the ExternalIgnoreList directive in your conf file. Opendkim will ignore this list of hosts when verifying incoming mail. And, because it’s also referenced by the InternalHosts directive, this same list of hosts will be considered “internal,” and opendkim will sign their outgoing mail.<br />
127.0.0.1<br />
::1<br />
hostname.example1.com<br />
example1.com<br />
hostname.example2.com<br />
example2.com<br />
...<br />
<br />
Change ownership of all files to opendkim:<br />
chown -R opendkim:mail /etc/opendkim<br />
<br />
Add a DNS TXT record with your selector and public key for each of the domains.<br />
<br />
You can now restart opendkim.<br />
<br />
== Security ==<br />
<br />
The default configuration for the OpenDKIM daemon is less than ideal from a security point of view (all those are minor security issues):<br />
* The OpenDKIM daemon does not need to run as {{ic|root}} at all (the configuration suggested earlier will have OpenDKIM drop {{ic|root}} privileges by himself but {{ic|systemd}} can do this too and much earlier).<br />
* If your mail daemon is on the same host as the OpenDKIM daemon, there is no need for localhost tcp sockets and unix sockets may be used instead, allowing classic user/group access controls.<br />
* OpenDKIM is using the {{ic|/tmp}} folder by default whereas it could use its own folder with additional access restrictions.<br />
<br />
The following configurations files will fix most of those issues (assuming you're using Postfix) and drop some unnecessary options in the systemd service unit:<br />
{{hc|/etc/tmpfiles.d/opendkim.conf|<br />
D /run/opendkim 0750 opendkim postfix<br />
}}<br />
{{hc|/etc/opendkim/opendkim.conf|<br />
BaseDirectory /var/lib/opendkim<br />
Domain example.com<br />
KeyFile /etc/opendkim/myselector.private<br />
Selector myselector<br />
Socket local:/run/opendkim/socket<br />
Syslog Yes<br />
TemporaryDirectory /run/opendkim<br />
UMask 002<br />
}}<br />
{{hc|/etc/systemd/system/opendkim.service|<nowiki><br />
[Unit]<br />
Description=OpenDKIM daemon<br />
After=network.target remote-fs.target nss-lookup.target<br />
<br />
[Service]<br />
Type=forking<br />
User=opendkim<br />
Group=postfix<br />
ExecStart=/usr/bin/opendkim -x /etc/opendkim/opendkim.conf<br />
<br />
[Install]<br />
WantedBy=multi-user.target</nowiki><br />
}}<br />
<br />
== Notes ==<br />
While you're about to fight spam and increase people's trust in your server, you might want to take a look at [http://en.wikipedia.org/wiki/Sender_Policy_Framework Sender Policy Framework], which basically means adding a DNS Record stating which servers are authorized to send email for your domain.</div>Fcladhttps://wiki.archlinux.org/index.php?title=TOMOYO_Linux&diff=249429TOMOYO Linux2013-03-05T12:23:14Z<p>Fclad: /* Installation */</p>
<hr />
<div>[[Category:Security]]<br />
[[Category:Kernel]]<br />
[[ja:TOMOYO Linux]]<br />
[[ru: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 [https://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 {{ic|/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 [https://aur.archlinux.org/packages.php?ID=42608 AKARI] and a package for [https://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 {{ic|/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 very close to 1.x since 2.5.x. 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 [https://aur.archlinux.org/packages.php?ID=42272 AUR]<br />
<br />
If all ok, append '''security=tomoyo TOMOYO_trigger=/bin/systemd''' to parameter GRUB_CMDLINE_LINUX_DEFAULT in {{ic|/etc/default/grub}}:<br />
<pre>GRUB_CMDLINE_LINUX_DEFAULT="quiet init=/bin/systemd security=tomoyo TOMOYO_trigger=/bin/systemd"</pre><br />
After, recompile {{ic|grub.cfg}}:<br />
# grub-mkconfig -o /boot/grub/grub.cfg<br />
So, TOMOYO will load all saved policies from {{ic|/etc/tomoyo/policy/current}} when {{ic|/bin/systemd}} executes.<br />
<br />
For first time, you may want to auto-save in-memory policies to filesystem when computer goes to shutdown/reboot. If yes, append the following line to {{ic|/etc/rc.local.shutdown}}:<br />
<pre>/usr/sbin/tomoyo-savepolicy</pre><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 {{ic|/etc/tomoyo/}} directory and can be edited by running:<br />
# tomoyo-editpolicy<br />
<br />
By default, tomoyo will start with "Disabled" profile (see profile-table below). You may want to enable learning mode for everybody right now. Just switch profile for {{ic|<kernel>}} namespace in {{ic|/etc/tomoyo/policy/current/domain_policy.conf}}:<br />
<pre><kernel><br />
use_profile 1<br />
use_group 0</pre><br />
If unsure if such wide learning is needed, just ignore this step. You can switch profiles later using '''tomoyo-editpolicy''' in "Domain transition editor" by pressing '''S''' on any selected domain (domains).<br />
<br />
Now, the computer should be restarted.<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 {{ic|/sbin/init}} invoked by the kernel belongs to is "<kernel> /sbin/init"; if {{ic|/sbin/init}} invokes {{ic|/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.5/index.html.en TOMOYO Linux 2.5.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>Fcladhttps://wiki.archlinux.org/index.php?title=TOMOYO_Linux&diff=249303TOMOYO Linux2013-03-04T23:12:07Z<p>Fclad: </p>
<hr />
<div>[[Category:Security]]<br />
[[Category:Kernel]]<br />
[[ja:TOMOYO Linux]]<br />
[[ru: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 [https://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 {{ic|/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 [https://aur.archlinux.org/packages.php?ID=42608 AKARI] and a package for [https://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 {{ic|/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 very close to 1.x since 2.5.x. 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 [https://aur.archlinux.org/packages.php?ID=42272 AUR]<br />
<br />
If all ok, append '''security=tomoyo TOMOYO_trigger=/bin/systemd''' to parameter GRUB_CMDLINE_LINUX_DEFAULT in {{ic|/etc/default/grub}}:<br />
<pre>GRUB_CMDLINE_LINUX_DEFAULT="quiet init=/bin/systemd security=tomoyo TOMOYO_trigger=/usr/lib/systemd/systemd"</pre><br />
After, recompile {{ic|grub.cfg}}:<br />
# grub-mkconfig -o /boot/grub/grub.cfg<br />
So, TOMOYO will load all saved policies from {{ic|/etc/tomoyo/policy/current}} when {{ic|/bin/systemd}} executes.<br />
<br />
For first time, you may want to auto-save in-memory policies to filesystem when computer goes to shutdown/reboot. If yes, append the following line to {{ic|/etc/rc.local.shutdown}}:<br />
<pre>/usr/sbin/tomoyo-savepolicy</pre><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 {{ic|/etc/tomoyo/}} directory and can be edited by running:<br />
# tomoyo-editpolicy<br />
<br />
By default, tomoyo will start with "Disabled" profile (see profile-table below). You may want to enable learning mode for everybody right now. Just switch profile for {{ic|<kernel>}} namespace in {{ic|/etc/tomoyo/policy/current/domain_policy.conf}}:<br />
<pre><kernel><br />
use_profile 1<br />
use_group 0</pre><br />
If unsure if such wide learning is needed, just ignore this step. You can switch profiles later using '''tomoyo-editpolicy''' in "Domain transition editor" by pressing '''S''' on any selected domain (domains).<br />
<br />
Now, the computer should be restarted.<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 {{ic|/sbin/init}} invoked by the kernel belongs to is "<kernel> /sbin/init"; if {{ic|/sbin/init}} invokes {{ic|/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.5/index.html.en TOMOYO Linux 2.5.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>Fclad