This PR fixes a lot of clippy warnings. Code is now much more idiomatic.

No functional change intended. The code still builds and all tests pass after these changes.

Some info about dbus and SELinux: https://blog.siphos.be/2014/06/d-bus-and-selinux/

SELinux policies ship a dbus_contexts file at /etc/selinux/[policyname]/contexts/dbus_contexts which provides mappings from dbus service names to SELinux label. If a mapping is not defined, dbus uses the label of the owning process.

The common case is to leave this file empty as with this template and simply allow the default behavior.

Dbus throws errors and has substantially degraded functionality if this file is not present at all, so we need to ship a file there.

The current approach doesn't yet provide support for actually specifying the mappings, but it is full featured enough to make that straightforward when it is added. Presumably something like an @dbus() annotation will be a very straightforward way to specify this in Cascade, and it can then be plugged in to this machinery.

This enables recursively discovering all policy files in the specified path(s), which is expected to be the most common use case.

Additional ergonomics, like defaulting to CWD if no path is specified is future work.

A rule like:

allow(this, foo, system, [start]);

Fails to compile currently, because system is parsed as the reserved keyword rather than some arbitrary string that will later be consumed as a valid object class.

Previously we allow the user to do something like: resource baz inherits foo, foo, bar

This is either a needless duplicate or a possible typo. The compiler will now produce an error if a duplicate inherit like this is present.

Nothing is actually done with these yet. Future work will need to override the default ordering assumptions.

In our existing docs, we have used this syntax extensively in annotations, and (to my knowledge) never in function calls. For consistency, we should support both.

The near term need is to support this syntax in annotations. A follow-on PR will add actual support here. Allowing these to work in the parser allows annotations that have no behavior defined yet, but use the "name=foo" syntax to at least parse correctly.

--package takes the output files and packages them up into the contents to go in /etc/selinux

Currently, we only package the compiled policy.32 and file_contexts. This commit assumes that the secilc version present generates a policy.32. That's an obviously broken assumption that should be fixed before merging this. Over the longer term, we should be able to take the infrastructure added here and add all the other files.

For a policy built without specific system configuration, this names the final policy "out", which may not be desirable.

The capability, process and cap_userns object classes have more than 32 permissions, which is the max permissions per class. Therefore SELinux has separate capability2, process2 and cap2_userns classes to handle this overflow. In Cascade, we just treat these "2" permissions as part of the main class.

Previously, validation worked, but the outputted CIL didn't handle the mapping correctly. This commit correctly maps capability2, process2 and cap2_userns permissions back to the correct object class in the output.

Detect whether we are writing to a terminal and conditionally enable color on error output

I had assumed termcolor did this for us, but according to their documentation, they do not, and recommend using the atty crate for this purpose: https://docs.rs/termcolor/latest/termcolor/#detecting-presence-of-a-terminal

The approach in this commit lets casc determine whether or not to use color, and then error.rs translates that boolean decision into the appropriate termcolor commands. Casc makes its decision in turn based on atty detecting a terminal. This architecture allows for future binaries to make different decisions if needed (eg a --nocolor flag).

Reported-by: Matthew Sheets [email protected]

• Add syntax examples
• Remove mention that traits are future work (they have now been implemented)
• Split paragraphs
• Simplify wording around virtual modules

This keyword allows you to extend a type declared elsewhere.

It is an error to use the extend keyword on an undeclared type.

One minor note is that this moves aliases before associations in the compilation order. This is so aliases can be extended. I don't think there's any reason that associations need to be done first.

If you do something like:

allow(this, this: resource, capability, foo);

Then you will get a message that "foo" is not in the "capability2" object class. The expectation is that the error message should refer to the "capability" object class instead.

Hello,

The @associate_call expects a virtual function. This condition is not well stipulated in the documentation.

The problem is generated by the method: apply_associate_annotations::inherit_annotations Caused by (as far as I saw): A new type is generated (mock.mock_conf in the example I have presented), which tries to inherit the mock_conf type. Since mock_conf is not virtual, an error is thrown.

Code to reproduce the problem:

• the following .CAS code could not be compiled:

resource mock_conf  {
	@associated_call
	fn read(domain source) {
		allow(source, this, file, [ read open getattr ]);
	}
	file_context("/home/csandu/Documents", [file dir], this);
}

@associate([mock_conf])
domain mock {
	mock_conf.read(this);
}

Is this the expected behavior? If so, why one should "expect" virtual when using @associated_call(s)?

Thank you for your support, Cristian Sandu

Hello,

The resulting .CIL of a .CAS file has the definition all of the system's base classes, such as: "alg_socket", "anon_inode". This monolithic approach is problematic because the resulting .CIL require manual editing before being insert in the SE's Binary Tree of policies.

I understand why this approach is desired, but shouldn't be any compilation option to disable these embeddings?

Thank you for your support, Cristian

file_context("/dev/log", socket, system_u:object_r:devlog_t:mls_systemhigh);

Reports "invalid" character on the ":". At a quick glance, it looks like ":" is handled in context parsing, but not in the lexing. So perhaps just including this in the lexer will pass it on to the rest which is unit tested and should work. On the other hand, maybe we want to parse contexts as contexts? Needs a more comprehensive investigation.