Re: Collecting ideas for audit2allow improvement

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, Jun 14, 2017 at 09:58:43AM -0400, jwcart2 wrote:
> On 06/14/2017 09:01 AM, 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>)
> >    * 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)
> >    * 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
> >    * output to CIL (add option for this)
> 
> This would definitely be helpful and should be relatively straightforward.
> 
> Jim

I will second that. I actually think this is the only compelling improvement in the whole list.

Except this (which isnt in the list):

https://twitter.com/evilSnobu/status/871787143781285889

Granted, its about sealert but it applies to audit2allow as well. Do not overwhelm users: they will get intimidated.
The idea is that things should improve security not to just dump a long list of (mostly terrible) options on unsuspecting users

Focus on making audit2allow more enjoyable to use. Waste no time on impossible missions, remove all the functionality that tries to do the impossible and does it terribly.

Stick with the basics, its a helper tool, its not some magic tool that can make security decisions on your behalf, and it never will be

> 
> >    * 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.
> >    * add option to open bugzilla
> >    * output to Ansible playbook/role task (add option for this)
> > 
> > I would also like to know which feature would you appreciate the most.
> > 
> > Thanks
> > 
> > Jan Zarsky
> > 
> 
> 
> -- 
> James Carter <jwcart2@xxxxxxxxxxxxx>
> National Security Agency

-- 
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


[Index of Archives]     [Selinux Refpolicy]     [Linux SGX]     [Fedora Users]     [Fedora Desktop]     [Yosemite Photos]     [Yosemite Camping]     [Yosemite Campsites]     [KDE Users]     [Gnome Users]

  Powered by Linux