The neverallow parser has a bug where it cannot parse multiline neverallow
rules that have inline comments. For example (taken from the bug description):
```
neverallow appdomain
system_server:udp_socket
{accept append bind create ioctl listen lock name_bind relabelfrom relabelto setattr shutdown };
```
Initially, the plan to fix this was to use the existing `avrule_read` function the
libsepol parser, however this function expects a compiled `policy` file that represents
the policies to be read in, while the neverallow parser reads from a `.te` file or a string.
This CL implements a fix to this parsing issue by pre-parsing the string
(either read in from a file or passed in as a string directly) and removing
the comments, before proceeding with the parsing as before.
Bug: 334697757
Test: atest android.security.cts.SELinuxNeverallowRulesTest
Change-Id: Ica67dedc23ca9c8b5ba8566198b6bfa785780921
This CL fixes leaks of the policy that we're building up. The analyzer
only caught the leaks on the error path, but I assume that
`check_assertions` does nothing to free the object that it's handed.
Analyzer warnings:
system/sepolicy/tools/sepolicy-analyze/neverallow.c:439:9: warning:
Potential leak of memory pointed to by 'avrule'
[clang-analyzer-unix.Malloc]
system/sepolicy/tools/sepolicy-analyze/neverallow.c:439:9: warning:
Potential leak of memory pointed to by 'neverallows'
[clang-analyzer-unix.Malloc]
Bug: None
Test: Treehugger; reran the analyzer
Change-Id: I79a0c34e8b53d33a1f01497337590eab660ad3ec
Fix the following warnings:
system/sepolicy/tools/sepolicy-analyze/neverallow.c:346:9: warning:
Potential leak of memory pointed to by '__s1'
system/sepolicy/tools/sepolicy-analyze/neverallow.c:346:9: warning:
Potential leak of memory pointed to by 'id'
system/sepolicy/tools/sepolicy-analyze/neverallow.c:364:13: warning:
Potential leak of memory pointed to by 'classperms'
system/sepolicy/tools/sepolicy-analyze/neverallow.c:364:13: warning:
Potential leak of memory pointed to by 'node'
Bug: b/27101951
Test:Warnings are gone.
Change-Id: Ib9b2e0b9f19950b4b764d438ee58340e6c022ef5
Empty typeset is not an issue in neverallow rules. The reason is that
it's completly normal for scontext or tcontext of neverallow rules to
evaluate to an empty type set. For example, there are neverallow rules
whose purpose is to test that all types with particular powers are
associated with a particular attribute:
neverallow {
untrusted_app_all
-untrusted_app
-untrusted_app_25
} domain:process fork;
Test: sepolicy-analyze neverallow -w -n \
'neverallow {} {}:binder call;'
produces empty output instead of "Warning! Empty type set"
Bug: 37357742
Change-Id: Id61b4fe22fafaf0522d8769dd4e23dfde6cd9f45
Commit dc0ab516f11d8e2c413315e733e25a41ba468e4f changed the libsepol
structures on which sepolicy-analyze relies so that it could be compiled
as a C++ library. Reflect this change in sepolicy-analyze.
Change-Id: I7da601767c3a4ebed7274e33304d8b589a9115fe
Also, divide each sepolicy-analyze function into its own component for simplified
command-line parsing and potentially eventual modularization.
Bug: 18005561
Change-Id: I45fa07d776cf1bec7d60dba0c03ee05142b86c19