Running checks on source policy for Android (AOSP)

[Johnmper]

Hi, first I would like to say I'm fairly new to SELinux and I'm still exploring all sorts of documentations.

• Is it possible with the current tool to check syntax of policies for Android or would changes be required?
• I can run the checks on the standalone .TE files. But can I validate if a macro really exists in the AOSP sepolicy repo?

[dburgener]

Hello! Welcome to the SELinux world!

I do not believe that checking Android policies works "out of the box" at the moment. The central issue is that refpolicy style te files start with a policy_module() statement and android ones do not. While that might sound like a fairly easy issue to overcome, internal details of the parser unfortunately make it at least non-trivial. I'm not sure what the full scope to enable this behavior would be. Some semi-recent changes (#138 and#143) to wrap the parsing better were probably a pre-requisite which should help a lot, but I haven't revisited the problem since those changes were in. It may only be a small refactor at this point.

I suspect the policy_module statement is the primary blocker here but I haven't looked at the state of Android policy in a few years and I'm not sure what else might fall out on trying to parse it. Probably a lot of it should be solvable with configuration.

I can run the checks on the standalone .TE files. But can I validate if a macro really exists in the AOSP sepolicy repo?

Not at the present, no. I wonder if you could expand on the value this provides for you? We generally avoid adding checks for things that will be caught by the compiler unless the compiler catches it in a very unhelpful way. In the non-android context using undefined macros typically is a straightforward compiler error, so this hasn't been a high priority.

In general, very little attention has been given to Android specific issues here. I don't have the bandwidth currently to devote attention to them, but I would happily accept PRs that moved us towards enabling useful Android support.

[Johnmper]

Hello, thanks for the welcome and by the fast reply.

Thought so, I actually already tried using the policy_module() statement just like you commented and I can run selint in some sections of the policy. It's good to know I wasn't going in the wrong direction.

I can run the checks on the standalone .TE files. But can I validate if a macro really exists in the AOSP sepolicy repo?

Not at the present, no. I wonder if you could expand on the value this provides for you?

The compiler will catch these problems that's true. Probably don't need this, but right now I am detached from the build system that's why I asked. Thanks

Can I ask then if selint does any check if the permissions and classes are valid? Or does it check only the syntax?

Btw, it's possible I still don't have the correct setup as I have these popping up: (still didn't check why)

Note: Check E-007 is not performed because no permission macro has been parsed.
Note: Check E-008 is not performed because no class has been parsed.

[dburgener]

Can I ask then if selint does any check if the permissions and classes are valid?

This should be checks E-007 and E-008, which you're getting errors on. The behavior on locating the classes and permissions differs based on if you're building policy for use on your current system or cross-compiling. To cross-compile you want to use the -s flag with selint. In that situation, selint looks for files named "obj_perm_sets.spt", "access_vectors" in the list of files passed for scanning and loads information from them if present (on refpolicy systems, obj_perm_sets.spt is the permission macros, and access_vectors is the permissions and classes). I don't have Android policy in front of me at the moment to see if they ship equivalent files. It's possible some customization may be needed for the macros in particular. In non-source mode the same information is read from the running system and from the SELinux development headers (/usr/share/selinux/devel). That path is unfortunately hard-coded at the moment. I'd definitely accept a PR to make it configurable.

I'd also mention that I'd take results against Android policy with a grain of salt. There are somewhat different standards and conventions here than for refpolicy policies and not all checks may necessarily apply. If you were to come up with a config that works well on your Android system and wanted to share it, I'd accept a PR for a suggested Android config to help people in the future.

[Johnmper]

This should be checks E-007 and E-008, which you're getting errors on.

Thanks, will check this then.

I don't have Android policy in front of me at the moment to see if they ship equivalent files.

Yes, they have similar files (_accessvectors is there, the _obj_permsets.spt has a different name I believe). Not sure if I can use them directly but will check what is possible.

I'd also mention that I'd take results against Android policy with a grain of salt.

Thanks. Yes, I will manually check things for now, but will probably already catch somethings to correct on my side.

If you were to come up with a config that works well on your Android system and wanted to share it, (...)

I'm still trying to figure things out. In the future if possible will do so.

Thanks again, you spared me of a couple hours of painfuly looking at my screen. I think you can close.