From: dominick.grift@gmail.com (grift) Date: Sun, 09 Dec 2012 11:59:51 +0100 Subject: [refpolicy] [PATCH 04/11] Initial policy for makewhatis In-Reply-To: <20121209094426.GA20616@siphos.be> References: <1355000222-7297-1-git-send-email-sven.vermeulen@siphos.be> <1355000222-7297-5-git-send-email-sven.vermeulen@siphos.be> <1355003874.1797.47.camel@localhost> <20121209094426.GA20616@siphos.be> Message-ID: <1355050791.1797.63.camel@localhost> To: refpolicy@oss.tresys.com List-Id: refpolicy.oss.tresys.com On Sun, 2012-12-09 at 10:44 +0100, Sven Vermeulen wrote: > On Sat, Dec 08, 2012 at 10:57:54PM +0100, grift wrote: > [... About makewhatis and logsentry policies ...] > > I would rather have the actual cron script labeled and leave this file > > generic instead since this policy only supports a domain transition from > > crond anyway. > > What's the rational behind that? The application is marked as an > application_domain, so regular user domains can execute it. Also, other > policies like tmpreaper, which are also meant to just be triggered through a > cronjob, are setup the same way (i.e. /usr/sbin/tmp{reaper,watch} are marked > as tmpreaper_exec_t). > Yes regular users may be able to execute it but there is currently no other domain transition specified. The rationale is the following. If you look at the prelink policy i will use that as a reference to back up my suggesting: if you transition on the actual cron script you will be generally safer that things work if you have unconfined disabled: # seinfo -xaunconfined_domain_type | grep cron unconfined_cronjob_t system_cronjob_t crond_t this shows that a bunch of cron domains are unconfined in fedora at least so all cron scripts by default run fine. However stuff *might* break if you disable the unconfined domain, For example if the cron script does something that is currently not allowed. Some stupid example: lets say the cron script creates a file in the makewhatis tmp location. or it actually creates it. Then you have crond_t creating the makewhatis tmp location (on top of that with a non-optimal type if you do not specify a proper type transition. if you do the transition on the script then you will avoid any of those issues currently and in the future (you never know when a script may get updated to do something you dont want crond to do) Basically it ensures that stuff will keep working even if you have unconfined disabled if done right. If you would have enclosed a valid use case for why users should directly transition on the actually executable file rather than the cron script then i would be more convinced but currently you only transition on cron and so i prefer that you then do it on the script and leave the executable file generic, I hope my reasoning made sense to you > Wkr, > Sven Vermeulen > _______________________________________________ > refpolicy mailing list > refpolicy at oss.tresys.com > http://oss.tresys.com/mailman/listinfo/refpolicy