From: russell@coker.com.au (Russell Coker) Date: Wed, 19 Apr 2017 23:49:10 +1000 Subject: [refpolicy] [PATCH] second strict patch In-Reply-To: References: <20170419110059.edrv6goiv2xwrnvk@athena.coker.com.au> Message-ID: <201704192349.10888.russell@coker.com.au> To: refpolicy@oss.tresys.com List-Id: refpolicy.oss.tresys.com On Wed, 19 Apr 2017 10:23:15 PM Christian G?ttsche wrote: > > Index: refpolicy-2.20170419/policy/support/file_patterns.spt > > =================================================================== > > --- refpolicy-2.20170419.orig/policy/support/file_patterns.spt > > +++ refpolicy-2.20170419/policy/support/file_patterns.spt > > @@ -489,7 +489,7 @@ define(`rw_chr_files_pattern',` > > > > define(`create_chr_files_pattern',` > > allow $1 self:capability mknod; > > allow $1 $2:dir add_entry_dir_perms; > > > > - allow $1 $3:chr_file create_chr_file_perms; > > + allow $1 $3:chr_file { create_chr_file_perms setattr }; > > why setattr in create pattern? I don't think it makes sense to allow creating an object without setattr, the creater can always control the Unix permissions via the mode parameter to mknod anyway. I think that the aims in designing policy should not be about having the fiddly details exposed all the time but in making it easy to achieve reasonable security aims when writing policy. Having multiple patterns for such things isn't going to help things, it will just make people not use patterns because it takes too many needless lines of policy that give a result that's not clear. I'm all for creating more restrictive macros and patterns when it actually does some good. For example the rw_inherited_*_perms macros provide real benefits. But I don't think that creating a device node without setattr is helping. -- My Main Blog http://etbe.coker.com.au/ My Documents Blog http://doc.coker.com.au/