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: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.
- 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.
- 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 otherWell, 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.
problem with your filesystem labels or use of non-labeled fs.
--
Best Regards,
Aleksander Adamowski
GG#: 274614
ICQ UIN: 19780575 http://olo.ab.altkom.pl
-- fedora-selinux-list mailing list fedora-selinux-list@xxxxxxxxxx http://www.redhat.com/mailman/listinfo/fedora-selinux-list
