From: harrytaurus2002@hotmail.com (HarryCiao) Date: Mon, 22 Nov 2010 10:57:07 +0000 Subject: [refpolicy] FW: Add support for the samhain program In-Reply-To: <4CE695C4.5020501@tresys.com> References: , , , , <20101111121804.GA17316@localhost.localdomain>, , , , <20101112115307.GB21277@localhost.localdomain>, , , , <20101115123522.GE21277@localhost.localdomain>, , <4CE3E080.9070109@tresys.com> , <4CE695C4.5020501@tresys.com> Message-ID: To: refpolicy@oss.tresys.com List-Id: refpolicy.oss.tresys.com Hi Chris, Please see my inline responses, thanks! [cut] > > > > Right, I have added below range_transition rule to the samhain_run() > > interface to enforce the samhain domain to run in the clearance se > > curity level: > > > > ifdef(`enable_mls', ` > > range_transition $1 samhain_exec_t:process mls_systemhigh; > > ') > > > > However, since secadm_t does not belong to the mlsprocsetsl nor > > privrangetrans attribute, the MLS constraint for process transition will > > fail if the secadm is trying to run samhain in s0 in the command line, > > so secadm would still have to fallback on the newrole program to switch > > to the clearance level. > > But, above range_transition rule would enforce the samhain domain > > running with the clearance level, I think it's desirable to have it :-) > > After thinking about this some more, the level change should probably be > an active decision, so we should skip the range_transition. Theres also > the problem that if the user and it's terminal are, for example, system > low, then they run samhain at system high, samhain won't be able to > write to the terminal. > Well, I see you point, and I still want to preserve the range_transition there in the samhain_run interface, which could enforce the samhain domain running in mls_systemhigh, which in turn I think is the only way to ensure the samhain log files or data base files to be of mls_systemhigh too. (BTW do we have range_transition rule for files?) Well, since samhain would have to create and write to its log files to /var/log/ which is of s0, I have granted it the mlsfilewrite attribute, so it will be fine to run on user_devpts_t:s0 already :-) [cut] > > > > So these two domain would have a lot of rules in common and it would > > greatly simplify our life if we keep them as one. > > Using an attribute would make it easier. Create two domains having a > common attribute, and then add the common rules to the attribute. > Alternatively, you could use a template. > > The key thing here is the database. We only want it writeable when its > intended, which is when its run interactively to create/update it. > Right, thanks a lot! Template is the right choice to collect all those common rules for both domains no matter started by command line or init script, then I could grant each domain different privileges against the signature database. Please see my attached v5 patch, it's really exciting to be able to make use of the template for the very first of my time :-) Have a nice day! Best regards, Harry -------------- next part -------------- An HTML attachment was scrubbed... URL: http://oss.tresys.com/pipermail/refpolicy/attachments/20101122/9c2264ea/attachment.html -------------- next part -------------- A non-text attachment was scrubbed... Name: v5-Add-support-for-the-samhain-program.patch Type: text/x-patch Size: 11519 bytes Desc: not available Url : http://oss.tresys.com/pipermail/refpolicy/attachments/20101122/9c2264ea/attachment.bin