ZeroMAC

One day your daemons become your enemies

v0.9.4.x stable version

ABOUT

ZeroMAC is a label/rule based Linux kernel LSM Mandatory Access Control security system.

The main goals of ZeroMAC:

• fast, highly scalable (from embedded devices to servers)
• simple and effective configuration, one rule set, one configuration file (can be embedded to the kernel)
• settings can be composed, updated, retrieved, compared, saved and restored with ease through a serial security console
• protects against label flood attacks (and a few more DOS attacks) by design
• transactions for consistent, failsafe, atomic configuration update
• easily customizable learning modes
• can be used without userspace utilities
• can be started with rules, and settings applied before the first code execution (sealed before boot)
• separates kernel processes and userspace processes with dedicated labels
• fire up new daemons can be done in minutes, with optimised learning commands
• can log to kernel audit subsystem and/or kernel log too, with the option of turning to silent
• operating modes can be changed any time, practically between any modes
• it is compact, unneeded code sections will not be compiled into the kernel
• forced label files and directories for consistent file system labelling
• forced labels (will be/are) stored in the filesystem
• easy to create and maintain forced label directory trees
• the learning method is independent of any logging subsystem
• prepared for user space incident response (proactive security) and central (remote) monitoring
• the system is free, open source, GNU GPL v2
• independent of governments and big companies :)

The aim of this project, in a nutshell, is to create security entities and make the connection between them (with a kind of set theory and rules) in a snap, providing efficient protection against zero day attacks.

ZeroMAC uses the standard LSM hooks as SELinux but has a quite different structure and simple configuration for easy and effective use.

It cannot be used as a loadable module, because as a module it could not give you the basic functionality which is an important part of the project, provide security right from the very first code load and execution.

You can create label/rule environments to meet the Bell-LaPadula security model as well as Biba but optimised without strictly following the papers.

By default, it does not have the (numeric) linear security level structure and its dedicated fields (do you know about any real existing organizational structure which can be covered by the simple linear MLS theory...?) Although, you can implement read down, write up by labels and rules in seconds.

There is no official mechanism at the moment, which assigns labels on user login, I'll write a pam.d patch set later (maybe for v1.0). (currently, it is more secure without it, but there is an existing workaround to implement, contact me if you would like to use it)

There are lots of kernel configuration options to choose from, you can completely skip compiling the logging and user interface (and a few more) subsystems if you use it in embedded systems.

You can create forced label files or directories, which will be stored in the file system, in extended attributes. It is a very important aim to provide a way to keep the security labels on files consistent, and have to relabel only temporary file systems at boot time. If you do not boot up without a ZeroMAC enabled kernel, probably need no relabel your filesystem.

A very important difference to other LSM based systems, if you copy or move (!) a file or directory to a forced label area, it will change the access label to the forced one. For example, if you create a web root directory, and you set the tree as the forced label to 'webdata', all files and directories will have this label, no matter which process created or moved files there. Any process can place there files only if they have write access to 'webdata' label (and of course can pass the directory walking).

In ZeroMAC, only the admin can change label, or admin can grant a process to change (to specific) label(s). Although admin can give other labels the right to update (specific) ZeroMAC labels or even use the security console's given commands.

INTRODUCTION

To operate ZeroMAC, you have to compile a Linux kernel with the patch (see install section), you need to label your files and directories, you have to create the configuration and rules and you are ready to go. Please read the whole documentation before you try.

LABELS

ZeroMAC uses labels to identify security contexts for processes, files and sockets and other resources and uses rules to declare the relations of them. There are three kinds of labels, the access label, which is the security identification of the resource or process, the execute label which declares what label change is required if the actual file or directory is executed or used and the create label, which will use the process to create new files.

All labels are limited to 16 characters and can contain letters, numbers, + - _ characters and are case sensitive.

All resources have to have at least one label, the access label, processes should have two labels "access:create", inodes (files and directories) should have three labels, "access:execute:create", and sockets or other resources could have only one, "access" label.

ACCESS LABELS

Every process has a label. The process label is the label the owner had when started the process. Every file, directory, or socket has an access label.
Every process has (label level) rights to access all the files and resources which has the very same label but cannot access other label's processes and files unless you create a specific rule to do so. If you do not have rules for a label, then that process and related resources will be isolated from the other labels.

The label named underscore "_" has a special meaning, it is the undefined label. (otherwise, it works the same, you can declare rules for it as usual). If a file has no ZeroMAC access label, it will have an undefined label. (current version 0.9.4.x can handle it as an ordinary label, but current userspace utilities handle it a different way, this could change soon, read later)

If a process will create a file, it will be created by the label of the process. The process cannot change its label, there are two exceptions: execute labels and setting it through /proc/self/attr/current, but the later depends on compile-time options. (not allowed by default)

EXECUTE LABELS

All the inodes (files and directories) should have an execute label. If there is an exec label and the file executed, the process access label will get the execute label of the file. (else the new process will get the label of the process who executed the file) If a directory has an execute label, files and directories will be forced to get this label as access label, and created directories will have the same access and exec labels, therefore you can be sure if you create a directory with an exec label "foo", all components of that tree will be created with "foo" label, no matter if you create the file there or move there. Files and directories will change labels even if the admin will write or move to there, but admin can change a file or directory access label in a forced label directory.

Please note, all processes can change their label only if you create a rule with "C" change label privilege. For example, if you have a rule (system apache C) then system label can run a file with apache execute label, and the created process will have the apache label.

CREATE LABELS

If an executable file has a create label, when you execute it, the process will get its create label, and all the files it will create will get this label as an access label. This way you can easily separate the files for a label that can read and execute, and files that can write, but cannot execute. (Read the "How to build ZeroMAC security" section for details)

Please note, if you use create label, then you need to apply a rule which will allow your process access label to create files as the create label. If you will not allow it, the process cannot create files, but still can read/write the ones with its access label. (unless you restrict to write its own label by a rule of course)

RULES

The access matrix for the labels are defined in rules, it can be used to declare the relationship between labels. The rules are defined in form, where the subject is usually the label of the process, the object is the label of the resource, (task, file (inode), socket, etc.). Whitespaces are needed between and after the labels. It is allowed to have 0 or more whitespaces anywhere in the access or deny sections and between them. The rule is valid if it has access or deny privileges, or if it is empty. An empty rule is like
Dot is a fill character, but it is a valid "empty" privilege set in itself. Access and deny sections are letters that represent privileges.
A rule with all the privileges allowed looks like this: If you would allow learning but you would not like to ever learn right to write, append and change label, read and write ZeroMAC access labels and mount volumes looks like The rule provides access for the subject label to resources labelled by the object label with the access rights defined by the access privileges and will deny all the requests which are in deny privileges. Whitespaces (ASCII 32) are allowed in rules everywhere. Deny privileges starts with "/" character which was "!" in previous versions, but changed because of the convenience in shell commands.

PRIVILEGES

Privileges are rights that subject can have on the object. Privileges are grouped based on functionalities, and assigned a letter for each of them, to make it easy to handle with a few characters. If you need different groups, you can change them in seconds (hacking the source code). If you list privileges, you will get it padded with dots, and positioned to the same column (for easy reading).

There are label level privileges that are granted default for labels if they access resources with the same label and system-level privileges which provide access to the system. Letters that represent the privileges are not case sensitive. If you see the log, you will see all the privileges which are asked as lowercase characters and uppercase the letters which are rejected or learned. They are the same if you use them in rule declarations.

LABEL LEVEL PRIVILEGES

Label level privileges affect directly only the subject and object label. (Subject can do something on the object) If the subject and object labels are the same, all label level privileges are allowed by default (although you can restrict it if you create a rule with fewer privileges, see rules priority section, same subject and object label)

R - ZMAC_MAY_READ W - ZMAC_MAY_WRITE A - ZMAC_MAY_APPEND X - ZMAC_MAY_EXEC S - ZMAC_MAY_SOCKRW I - ZMAC_MAY_IPC J - ZMAC_MAY_MMAP G - ZMAC_MAY_SENDSIGNAL P - ZMAC_MAY_PTRACE

SYSTEM LEVEL PRIVILEGES

System-level privileges affect not only subject and object labels but the whole system, and therefore affect other labels, or can change system behaviour somehow. System-level privileges could be harmful, handle those with special care, especially if you create wildcard rules!

E - ZMAC_MAY_E_WRITE M - ZMAC_MAY_MOUNT T - ZMAC_MAY_MOUNT_TRUSTED C - ZMAC_MAY_CHANGELABEL Y - ZMAC_MAY_Z_READ Z - ZMAC_MAY_Z_WRITE L - ZMAC_MAY_LEARN = - ZMAC_BHPR

SYSTEM REQUESTED SPECIAL PRIVILEGES

These privileges are asked in some parts of the ZeroMAC security system, but cannot place them in rules, and the system cannot learn these. You can see these letters in log files when access is requested for some reason.

* - ZMAC_NEED_ADMIN U - ZMAC_MAY_USE_UI There is no privilege for module loading and unloading at the moment because I do not use modules at all. For embedded systems modules are pointless, for servers modules are not secure (and pointless). But if you use modules, (for desktop systems the modules are a must-have) it is very important to allow only specific modules to load, so I'll create privilege for module handling soon. (this summer maybe)

WILDCARD LABEL

If you would like to apply a rule for all the labels on a position, then you can use the wildcard label. The wildcard label is "%", it can be used in rule declarations in itself to represent all the labels. It cannot be used to substitute some letters in a label, it can be used only in itself in place of a label. (Previously it was "*", but changed to "%" for shell commands convenience.)
For example the rule
means system label has read/write access to all the other labels. Or rule like
means none of the labels should have read/write/append/execute access to "apache" label. (unless if you have a higher priority rule)

RULES PRIORITY

The more exact the rule has the more (higher) priority. If you use wildcard labels in rules, there are 4 priority levels,

priority	subject	object
4	%	%
3	label	%
2	%	label
1	label	label

the lowest priority is when the rule has a wildcard as the subject and object too. Higher the priority if the subject is a label and the object is the wildcard, etc, and the literal rules which have exact labels for subject and object have the highest priority. The higher priority rules will overwrite the access rights of the lower priority rules. (Access sides will be added to the Access result of the different priority rules, as well as the Deny sides, but when a higher priority rule has the same privilege on the opposite side, then the higher priority rule will overwrite the lower priority.)
For example, if you have rules like:
The first rule has the lowest priority, if there are no higher priority rules declared with the opposite meaning, samba can read and write all the labels. The second rule has higher priority, and it says no one can read and write log labelled files and directories, therefore even samba cannot read log labelled files (just because it has higher priority). The last rule is a literal rule, which has the highest priority, which says apache can read log labelled files. (if you doubt the applicable privileges for two labels, there is the "check rules" console command, which will show you the result for the given labels, read later) Remember, all the rules which contain wildcards can be created and deleted by admin only (learning procedure creates literal rules).

And finally, if you have a literal rule for the same subject and object label, that has higher priority than the system's default behaviour, to allow label level privileges for the same label, and will override it. It means, for example, if apache label would like to write a file which labelled as apache it can do it, because "write" is a label level privilege, but if you declare a rule like
that means apache can read apache and can send a signal to other apache labelled processes, but if we have a specific rule like this, and "write" is not allowed there, it cannot write. This way you can restrict the labels on themselves, which is very important for several reasons, read later...

The recording, storing, listing order of rules has no priority for the rules, priority will be calculated on the contents of the rules only. The rules will be processed at the very moment of each request.

There are some special cases when you have a lower priority rule, but you would like to apply it even if we have higher priority rules. You can do it if you use '=' privilege at the given place in your rules. For example, if you say then it will override higher priority rules, and backup labelled processes can write log labels even if you have a higher priority rule, which denies all write access to "log" labels. It is important, override higher priority rules scope is valid only for the given access or deny rule section. You can use this privilege for different priority levels, this time the higher priority BHPR sections will apply.

DOUBLE WILDCARD LABEL

The double wildcard label "%%" can be used to select all existing labels, and can be used only in handling rules, and cannot be used in rule declarations. The double wildcard will select all the existing labels in a given position, even it will select a (single) wildcard label there. For example, the next ZeroMAC console command will delete all the rules which have foo as subject:
another example, if you have rules:
and you say it will delete only the first rule (because a single wildcard is a specific label used in rules), but if you say it will delete all the rules which have apache as the subject.

This will delete all the rules:
(read about this later)

To be clear: The (single) wildcard label can be used in rules, and it represents all the labels (meaning all the labels which are existing now and will exist in the future). Double wildcard label can be used only when handling rules, and it selects only rules with existing labels, it is used to select a set of rules to which you will apply modifications. (Please let me know if it is not clear this way.)

ADMIN

You can declare one label as the admin label. The process with the admin label has full access to all labels on the system. Admin can override every rule. Only the admin can change the labels of files and directories and set the rules which regulate how the labels can interoperate. Only the admin can access the ZeroMAC user interface and even the ZeroMAC security labels on any mounted disk. (There are exceptions, see Z,Y privileges, and grant/revoke console commands. You have to compile in these options to the kernel if you would like to use them.)

Initially, the admin label is not set, which means all the labels are admin labels on the system, you have to set the admin label as early as you can do to "seal" ZeroMAC. I highly recommend setting the admin label before boot. You can do it by a kernel configuration option, this way you will boot up with an already sealed kernel.
You can set/change the admin label with userspace (command line) utility: or the console command:

TRANSACTIONS

Transactions are batched commands which are processed at once when the transaction is committed. Transactions are very important for several reasons:

The first reason is consistency. All the rules can be deleted and created from the ground up in a transaction, do not have to worry about how to change the current rules to get the desired rule set. Partial delete and recreate of rules (or modifications) are also possible. The operating modes and rules can be set at the same time, so after the transaction is committed, you will get a consistent rule/mode set, which cannot be modified by any other learning request or another console submission. Actually, you can save your current running config and reload it any time.

The second reason is transactions are fail safe. You can create rule sets and apply them whenever you want, even when you are under attack, and you are low on resources. The transaction mechanism will guarantee, all the modifications will take place only if there are no errors in the transaction. (Out of memory, syntax error, etc). If there are errors in the transaction, then it will be discarded completely, never applied. If there were no errors, they will be committed, and all rules and settings will be applied at the same time. You can be sure about your current rules will be untouched if the transaction is discarded or rollback asked.

The third reason is atomicity. Sometimes more than one rule will give you the needed results. You have to take special care, what rules you have at the moment, and in what order you have to apply the rules for a flawless operation. For example, you will create a low priority rule which will reject lots of requests for a set of labels, then will create a rule (or rules) for the exceptions as a higher priority rule. If there are requests between the time you apply the rules, they will be rejected, which you do not want in an operative environment.
Transaction mechanism guarantee atomicity, which means all the commands will be applied at once, and will not be distracted by other modifications submitted any way to ZeroMAC.

You can start more transactions that overlap each other, they will be applied in the order of transaction closing commit commands issued. Transactions will not keep the state of the settings at the beginning of the transaction, therefore other's console sessions or the ZeroMAC system itself can apply modifications while you record the content of the transaction. If you write the transactions directly on the console, you can list the current rules if you already started the transaction.
Please note, if you leave the console session (accidentally or intended) while recording the transaction commands, the transaction will be discarded, none of the commands will be executed. If there is an error in the transaction, the system will still check the rest of the commands if there are errors or not, and will be reported.

Transactions are very important if you change console access settings because if you change the admin label, or apply a revoke command (and revoke will take access rights from your current label), you will lose the right to execute the subsequent commands, but using transaction, all commands will be executed if you had access when you issued the transaction commands and commit. If you lose the console access before committing the transaction, an access error will occur and the transaction will be discarded.

You can start the transaction with the console command and you can commit it with the command if you do not want your transaction to apply, you can say and you will quit from the transaction, and all commands will be discarded.

Also note, the command also runs like a transaction in itself, so all learned rules will be rolled back atomically (see LEARNING section). (Also, you can use it in a transaction as an ordinary command.)

OPERATING MODES

There are different operating modes (depends on compile options, see there).
Admin can change between them any time with the (set mode to enforced) console command or with (zm enforced) userspace utility. Compile-time you can tell which mode to start with.
Operating modes are:

enforced permissive disabled learning restricted learning off

LEARNING

Learning means ZeroMAC can learn rules which are needed to pass the security violations that happened. Learning mode always creates or modifies only literal rules (rules without wildcard labels). No matter how you switched to learning mode, rules deny sections are always checked, and if something is denied by the rules, that will be rejected and not allowed to learn by any circumstances. It is very important, that learning will learn label level rules even if the subject and object labels are the same. If you are not in learning mode, that will not rise a security violation, so it would be logical to abandon learning for this situation, but learning is about getting the least privileges that are enough to complete the operations asked. (Another very important reason is if you can restrict the access rights for the same label and if we do not learn label level access, and after a while, a rule created with system-level rights, then all the previous label level rights will not be added to the rule, which renders your system unusable... so believe me, you need it, this way)
It is important to note, if your system behaves somehow when you use learning, it does not mean, it will do the same next time. So if you learn rules, you have to be careful about if the application can run other possible ways.
It is also important to know, learning mode will not organise the labels and the security system for you, it will give you only a hint, what security requests you have to allow if you would like to use the system the current way. Sometimes it will show you it needs privileges which you would not allow them to use, and you have to relabel your files, directories and maybe running applications to make your system safe. If you fire up a daemon and you are allowed to learn rules for it, and the system created rules which you do not like, you can stop the daemon and can use "reset learned" console command to rollback all that it has learned.

There are two ways to use the learning mode:

The first method is to switch to "learning" or "restricted learning" operating modes. This way the system will modify and create rules as needed when a security violation occurs, for all the labels. Restricted learning means only label level rules are learned, this is less harmful) To switch you can use "zm" userspace utility or the console command.

The other way is to use MAY_LEARN privilege, and this is more interesting :)
You can use the console command to set mysql label to learn any privileges if there is a request for "mysql" as subject and "log" as the object.
(I wrote a capital L here, but only because small-cap l maybe not be readable with some browsers, but you can use either l or L here.)
If there will be a security violation, this rule will be modified. If you would like to stop learning for this particular rule, you should say: this will remove MAY_LEARN privilege and learning is stopped for this rule. (but the learned privileges will stay)

Remember, you can use MAY_LEARN with wildcard labels too, and rule priority will apply as usual, so if you say that means mysql can do and learn anything (L), but cannot read and write ZeroMAC labels on the filesystem (/yz), none of the labels can learn anything to admin label by the next rule, and finally cannot learn system-level privileges to apache label. The last two rules are higher priority rules than the first one, so they will overwrite the first on their scope. (see "RULES PRIORITY" section) (This is a bad example anyway, only for illustration, do not use it like this.) In the "INSTALL" section you can find examples of how to set up ZeroMAC, and how to use learning mode to fire up a new daemon.

USER INTERFACE (CONSOLE)

Userspace can communicate with ZeroMAC security system by the security console, which is an ordinary asynchronous character device. Only the admin labelled process can open the ZeroMAC security console. (see exceptions grant/revoke console commands.) If the admin is not defined, then any process can open and use it.
You can open it from any application if the application has access rights to the console file. There are two ways you can compile in the console, as a device node in the devfs file system (default: /dev/zmac), or you can have it in proc filesystem (default: /proc/zmac). If you choose to have it in devfs, you can rename, remove etc the console device file, and you can place it anywhere, you can even create it in your home directory with: you can list devices with and you can find there the major device number of zmac at character devices.

If you choose procfs, you can access the console at /proc/zmac. On this location, you cannot delete, rename, or destroy it. (be sure attacker cannot unmount /proc). Do not forget to set the console file location in userspace utility compile-time.

All the console commands and answers are human-readable. (you can directly open the console with the "zc" userspace utility, see there) The commands are case sensitive, all lowercase letters. All words in the commands can be substituted by (at least) the first 3 letters. Label names cannot be shortened.

You have to close every command line with an LF character. To close the console session, you can send an (ASCII 0) character as an EOF, or use the exit command with LF at the end (or you can simply close the console if you finished, and got all the answers). No commands will be executed after EOF or exit. After the console executed the last command, (and got EOF somehow), it will send 0 length response as EOF, it is safe to close the console after it.

You can send more commands in a batch, the console will process them in the order they issued and will respond to each command (almost). The commands which are not closed with LF or 0 characters will not be processed! The whitespace characters are the space (ASCII 32) and tab (ASCII 7). Any number of whitespace characters are allowed, but you need at least one between the command words and labels, etc. You can have empty lines, and you can have remarks after console commands, remarks must start with "#". All characters are handled as remarks until the end of the line and will be dropped. Quotes are not allowed and there is no (any kind of) escape character. If you exceed the maximum size of a line (which is more than enough), the whole line will be dropped, and you will get an error response.

All the answer lines are closed with LF. You can use the console in two modes: user mode or API mode.

If you open the console, user mode is the default, you have to send the command "api" to switch to API mode. (there is no way to switch back to user mode) (API mode is designed for userspace utilities, if you talk to the console directly, you don't need to change to API mode) There are two kinds of responses you can have: Single line responses and multi-line responses.

Single line responses are result lines. Result lines are composed of an integer response code in square brackets, a white space and a result text, which is closed by an LF character. Like this: If there is no error, then the API response code is positive, it usually identifies the type of answer. If there is an error, the response code is negative.

The multi-line console API responses are composed of one or more status lines and 0 or more content lines in the body, and a result line at the end. The multi-line response always starts with a status line and ends with a result line. (all responses must contain one result line, and only one)

The status line is composed of one opening square bracket, then an integer status code, a white space, and a status text, closed by an LF character. (there is no closing bracket in the status line!) Content lines cannot start with the opening bracket, so if you are in API mode, and see a line that does not start with the opening bracket, you know what it is.

If you use the console in user mode, then single line responses will contain the result text only and multi-line responses will contain only the content lines (and status and result texts only if there is an error, but they will be printed without the API response codes). All the answers are human-readable, composed with code page ISO-8859-1.

If you use the userspace console utility (zc) to submit a single command, it will show you the responses in user mode. (but in the background it needs the answers in API mode to get the error codes for return to the shell, and get the idea if print the results to stdout or stderr.)

An API mode multi-line response should look like this: Please note, usually, you will get the name of the list in the first status line, and the response error status in the last (result) line. We should say, all the console command API responses will get one line started with closed brackets, with a response code in it, and all will be positive if no error, and negative if had error(s). Future commands should send more status lines, and some of them could be negative which should mean there were syntax or other errors in execution, but you have to use the last line's (result line) response code to evaluate the success of the response.

(This is simple and logical for me, but maybe not for the readers. If you think this part (or any part) of the docmuentation is not clear enough, please let me know, then I have to improve!)

The error codes reserved for the console are from -20 to -99.
The current errors are:

CONSOLE COMMANDS

The console commands are:

helo api set rules modify rules delete rules check rule set admin set mode to grant revoke show grants show admin show mode show labels show version show rules show config show api version reset learned start commit rollback exit

USER SPACE (COMMAND LINE) UTILITIES

You can download the latest userspace utilities from : http://www.zeromac.uk/zutils-2.0.14.tgz

All you have to do is unpack it, and compile: Please note, with ZMAC_CONSOLE environment variable you can tell what console device you would like to use. The default for devfs is /dev/zmac, for procfs it is /proc/zmac. The default install directory is /usr/local/bin, but you can change it in makefile.

I suggest to use GCC 7 or later to compile utilities. (for the best optimization)

All the userspace utilities are returns with error codes to the shell if there were problems, which you can handle. Please see the userspace utilities error codes section.

The userspace utilities are:

zc zr zrset zrdel zrmod zm za zls zch zchdir

USER SPACE UTILITIES ERROR CODES

Please remember, if the console returned an error, then the userspace utility will return that error code (-20 to -99) as a positive number to the shell.
(read the console error codes section)

INSTALL

I have to refresh this section, no install instructions here, maybe I can upload the refreshed instructions this summer.

Current stable patch: http://www.zeromac.uk/zmac-0.9.4.19.bz2

(This stable release is feature frozen, no public development version available at the very moment (as I would not like to post unstable nightly builds))

This patch is for Linux kernel version 5.15.x tested with: 5.15. The patch will not work directly with the older kernel versions, but it isn't too hard to backport. If you would like to patch an older version, please let me know, I'll help you. It is easy to compile for 5.x.x - 5.x.x. (The next generation of the ZeroMAC system (0.9.5.x) would be hard to backport)

Place the ZeroMAC patch file and the kernel source in the same directory, and type: Then you have to create your config, compile, and enjoy your security :)

THE CURRENT STATE OF ZeroMAC DEVELOPMENT

The project is under development and is before official public release. There are only process and file system access control, there is no network access control at the moment. (I think I'll implement network security a bit different than current solutions, but I have to read tons of source code and documentation and have no time for that now)

I do write and maintain ZeroMAC in my (almost non-existent) free time (it's great fun to write a security system). I wrote it for myself, but feel free to use it, if you like it. :)

The current version seems to be stable, it is feature frozen until 2022. (Please note, I do not support older versions <=0.9.3.x)

If you found a bug, please be sure you used the latest version of ZeroMAC, and please report the bug!!!! Thank you!!!

As you can see I hate writing documentation, so it is far from complete and is far from perfect. (I wrote it in parts, in a hurry, so it can be inconsistent here and there. Please let me know if you find problems in the documentation.) Lots of features are still undocumented, once I'll have some time, I'll rewrite the full doc.

Kernel compile options are entirely undocumented here, but I wrote help in each option, those are up to date.

Currently, the source code is not in kernel style... (lines are longer than 80 and all parts of the source code are placed into one .c file, but for now, it makes it easy to handle and overview...) (btw 80 char wrap makes source code less readable IMHO)
Once I reach 1.0 I'll do a massive code clean, and will convert it to kernel style.
I have lots and lots of ideas about what to implement, so maybe version 1.0 is not here, but I'll create a stable version from every stage before reaching version 1.0. (I also use it (currently earlier versions) in production environment so I need stable versions too.)

Before I reach version 1.0 I will easily sacrifice backwards compatibility for better features or speed, better efficiency. After reaching 1.0, backwards compatibility will be important. If you use 0.9.x, be prepared for some modifications.

CONTACT

Currently, I can handle mails with a delay. (I have to work from early morning to late night) Please excuse me if you do not get an answer so quickly.

Making the system stable and bug free is important, so If you found a bug, please write an email, and start your subject with [BUG] please!
Also if you can do any type of attack against ZeroMAC, (even side-channel attacks) let me know, I'm interested, I'm excited, I'm curious!!!!

(I am not interested in module load attacks, and libc call hijack attacks, they are way too easy.)

You can donate the project if you like it: