HELP: transition denied regardless of policy?

[Aleksander Adamowski]

Stephen Smalley wrote:

>>May 26 03:26:01 machinename kernel: audit(1117070761.996:0): avc:  
>>denied  { transition } for  pid=11773 exe=/bin/bash 
>>path=/home/twiki/bin/mailnotify dev=hda1 ino=51463 
>>scontext=root:sysadm_r:sysadm_crond_t tcontext=root:system_r:twiki_t 
>>tclass=process
>>    
>>
>
>Note that the above transition involves a role change, not just a type
>change. 
>
Got it!

sysadm_crond_t doesn't have the privrole attribute.

Thanks for pointing it out, I didn't notice that, mainly because the 
sysadm_crond_t domain creation process is quite convoluted (it traverses 
several macros from different files).

I had to modify macros/program/crond_macros.te by adding 
priv_system_role attribute to domains generated by the crond_domain macro:

--- crond_macros.te.orig        2004-05-07 17:24:24.000000000 +0200
+++ crond_macros.te     2005-05-27 21:32:57.000000000 +0200
@@ -19,9 +20,13 @@
 define(`crond_domain',`
 # Derived domain for user cron jobs, user user_crond_domain if not system
 ifelse(`system', `$1', `
-type $1_crond_t, domain, privlog, privmail;
+type $1_crond_t, domain, privlog, privmail, nscd_client_domain;
+', `
+ifelse(`sysadm', `$1', `
+type $1_crond_t, domain, user_crond_domain, priv_system_role;
 ', `
 type $1_crond_t, domain, user_crond_domain;
+')
 
 # Access user files and dirs.
 allow $1_crond_t home_root_t:dir search;
@@ -31,8 +36,8 @@


Soon, checkpolicy for FC3 will have support for typeattribute construct:

https://www.redhat.com/archives/fedora-cvs-commits/2005-May/msg00593.html

And I will be able to simply augment the generated sysadm_crond_t domain 
with privrole from my program .te file like that:

typeattribute sysadm_crond_t privrole;

Until then, I can live with the manual modification to the macro, but it 
will get overwritten with every policy sources RPM upgrade.


>Questions:
>- Do you truly want this to run in the same domain when it is run from
>httpd as when it is run from the cron job?  This implies that it has the
>same permissions in both cases.  For example, I might envision the cron
>job as being more trusted (as it was set up by the admin) than the
>process spawned from httpd, and I doubt you want a httpd-spawned process
>to be able to attack the cron job if it happens to be running
>simultaneously.  You can define two different domains, with a shared
>exec type, such that the cron job will transition to one domain and
>httpd will transition to another domain when they run the program.
>  
>
Thanks for suggestion. Thinking about that, I could make a separate 
domain for this process. But it needs access to files  similar to httpd, 
so I might end up with duplicating lots of httpd domain AVC for it, 
which might beat the purpose... OTOH, i I label all those files it would 
make a lot more sense. I might not have enough time for that, though.

>- Is using daemon_domain truly appropriate here?  I'm a little
>skeptical.
>  
>
Possibly not, I'll look into that, thanks!

>- Why are you giving it access to unlabeled_t?  Suggests some other
>problem with your filesystem labels or use of non-labeled fs.
>  
>
Well, this .te is a work in progress, and I've made a preliminary 
version of that domain, relabeled the FS, then put all the errors 
through audit2allow to get AVC rules. I've put them into the .te file 
and right now I'm going through them, looking at suspicious ones and 
deciding what to do with them. So I'll take care of this one - yes, it's 
probably a problem with labels somewhere on my filesystem.


-- 
Best Regards,
    Aleksander Adamowski
        GG#: 274614
        ICQ UIN: 19780575 
	http://olo.ab.altkom.pl