On Wed, Jun 14, 2017 at 04:35:41PM +0200, Dominick Grift wrote: > 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. https://bugzilla.redhat.com/show_bug.cgi?id=1457406 > > > > > > * 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 -- 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
