AKARI : FAQ

General questions

Q1: What is AKARI?

A1: A Linux kernel module that can both automatically and interactively generate policies for Mandatory Access Control.

Q2: Who are the target users?

A2: Administrators that do not have the time and energy for more complex server security management.

Q3: How much extra memory is consumed?

A3: Fixed part (code and data in the kernel) is about 100 KB, variant part (access permissions) is a few hundred KB.

Q4: How large is the performance loss?

A4: Not formally tested, but it should be negligible for the regular user.

Q5: Which kernel versions are supported?

A5: Linux kernel 2.6.0 and later are supported. These are available from https://www.kernel.org/.

Q6: What is AKARI licensed under?

A6: AKARI is licensed under the GNU General Public License (GPL).

Q7: Does AKARI have any usage other than for Mandatory Access Control?

A7: Yes, you can use it as a system analysis tool or to create custom filesystem images with minimum files.

Policy management

Q1: Is the policy syntax easy?

A1: Yes, the syntax has been designed to be easily managed.

Q2: What is a domain?

A2: The domain in AKARI is a history of process execution determined by the sequence in which they are executed.

Q3: What is a profile?

A3: The profile in AKARI is a configuration that defines what level and type of MAC is used for a particular domain.

Q4: Can I update policies dynamically?

A4: Yes.

Q5: Do I need to restart processes after updating policies?

A5: No, unless you delete a domain and recreate it.

Q6: Will processes referring a domain crash by deleting the domain?

A6: No, processes will not crash because the deleted domain remains until processes terminate.

Q7: What measures against tampering policies are there?

A7: Programs or domains can be restricted from modifying policy.

Q8: How can I edit policies?

A8: An ncurses based CUI editor is included to modify policies. You may also use any text editors.

Q9: What is "Learning mode"?

A9: A mode in which access permissions are appended automatically in order to determine safe behaviours and resources that are required by a program for normal operation.

Q10: Are there problems appending access permissions automatically?

A10: There should be no problems, as AKARI uses absolute pathnames and fine-grained domain divisions.

Q11: Can I update packages while the Mandatory Access Control is enabled?

A11: Yes, by assigning different profiles to domains, or by using tools provided with AKARI (e.g. /usr/sbin/ccs-queryd).

Q12: Can I protect only daemon processes like SELinux's Targeted Policy?

A12: Yes, by assigning different profiles to domains.

Implementation

Q1: What is the security model of AKARI?

A1: Domain and Type Enforcement (DTE) only.

Q2: Are there concepts of users and roles?

A2: No, but it is possible to delegate a part of administration tasks.

Q3: Do userland applications need to be patched?

A3: No.

Q4: Can AKARI protect sshd from exploit codes?

A4: No, but it is possible to countermeasure illegal logins by enforcing additional authentication.

Q5: Which division is AKARI categorized in TCSEC?

A5: Unknown.

Q6: What security labels does AKARI use?

A6: AKARI uses absolute pathnames as security labels.

Q7: Can I use wildcards for pathnames?

A7: Yes.

Q8: Is multi-level security (MLS) supported?

A8: No. Save in the different directories according to sensitivity level of the file.

Q9: Are there functions like Linux Intrustion Detection System's (LIDS) stateful ACL?

A9: No.

Q10: Are the correctness of security labels guaranteed?

A10: Since pathnames are used as security labels, the correctness of security labels is guaranteed unless the directory entry get corrupted.

Q11: Are resources other than files protected?

A11: Yes, AKARI supports many resources (e.g. network ports, environment variables). See AKARI/TOMOYO functionality comparison table for a list of all the resources that can be restricted.