On Wed, Jun 14, 2017 at 10:30:25AM -0400, Stephen Smalley wrote: > On Wed, 2017-06-14 at 09:01 -0400, Jan Zarsky wrote: > > Hi, > > > > I would like to improve SELinux audit2allow tool as my bachelor > > thesis. > > I collected ideas from my colleagues from RedHat SELinux team and I > > would also > > like to hear your ideas - what would you improve to make audit2allow > > smarter or > > easier to use. > > > > Ideas collected so far: > > > > * offer dac_read_search when sufficient instead of dac_override > > (see <https://github.com/SELinuxProject/selinux/issues/31>) > > The hard part here is knowing when it is sufficient. Might require > further kernel patches to get to the point where it is completely > unambiguous from the audit messages alone. You could perhaps default > to only allowing dac_read_search and only allow dac_override if you see > that dac_read_search is already allowed and you are still getting a > dac_override denial. This should not be an issue anymore. Becuase now (linux v4.12) dac_read_search is first checked so translating a rule for dac_read_search will always be the most secure option. It might not be enough but youll notice if it isnt. Just rerun it again and you'll end up with dac_override if needed. > > > * offer multiple solutions to a problem (example: 1) add allow rule > > for > > execute + execute_no_trans or 2) add allow rule for execute > > + type_transition rule) > > Is this type_transition to an existing type that already exists, or > defining a new type and transitioning to it, or both? Generating new > domains and types dynamically is one of the major gaps in current > audit2allow, and to date has only been supported in separate tools like > sepolicy generate. One should be extremely careful here. "execute" does not automatically imply "execute_no_trans". That assumption can lead to disaster (https://www.cvedetails.com/cve/CVE-2015-1815/) > > > * interactive mode: ask questions and choose best solution > > * warn when solution touches trusted computing base (rules you > > should not be > > adding) > > * suggest alternate labels for content, example: httpd_t not > > allowed to write > > to user_home_t, might suggest that changing the label to > > httpd_user_content_t > > This seems more along the lines of what setroubleshoot does, and tends > to be policy-specific. We need to preserve the usability of audit2allow > for other policies (e.g. Android, DSSP), so any policy-specific logic > needs to be encapsulated, configuration-driven, and optional. setroubleshoot is not smart enough to suggest httpd_user_content_t, instead it suggest you allow full access to /home/* by toggling the boolean that grants access to user home content. I know this from experience. There was a bug in fedora's apache_user_content_template for more than a year and hardly anyone noticed it, probably because setroubleshoot would have just suggested you allow full access to user home content. > > > * output to CIL (add option for this) > > This would definitely be useful, as generating .te files just adds > overhead at this point and makes audit2allow depend on having > checkmodule and semodule_package installed. In fact, I think we should > move to generating CIL by default and just provide an option for > generating .te files for backward compat. > > > * if the AVC talks about execute permission then offer also > > type_transition > > rule > > * idea for a tool for automatic policy generation: On a test system > > you > > install application, turn the SELinux to permissive and run a > > full test > > suit. You collect all the AVCs in say Elasticsearch (can use > > common logging > > ViaQ project for that) and then there is a tool that searches the > > AVC, > > groups them and creates a policy out of them. > > This seems similar to sepolicy generate. We don't want to bring in > many extra dependencies to audit2allow, but being able to dynamically > generate new domains and types would IMHO be useful. > > > * add option to open bugzilla > > Need to be careful here since not all SELinux users are Red Hat users. > > > * output to Ansible playbook/role task (add option for this) > > Another improvement: > > * Add ability to generate ioctl whitelisting rules, see for example: > http://jeffvanderstoep.blogspot.com/2016/02/collecting-ioctl-command-denials-for.html > but note that the syntax has changed to e.g. > allowxperm <sourcedomain> <targetdomain>:<class> ioctl { <list of ioctl > command values> }; > > > I would also like to know which feature would you appreciate the > > most. > > You should likely study the tooling and workflow used by other security > projects, e.g. AppArmor, TOMOYO, grsecurity, for policy learning and > generation. > -- Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B 6B02 https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02 Dominick Grift
Attachment:
signature.asc
Description: PGP signature
