Hi!
I'm having a problem with FC3 strict policy. Basically, I've customised the policy to cover all that I need on that system, but there's one last denial that I'm unable to remedy:
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
(where /home/twiki/bin/mailnotify has a context of system_u:object_r:twiki_exec_t.)
This is directly related to my twiki.te policy:
#BEGIN daemon_domain(twiki) var_lib_domain(twiki) domain_auto_trans(httpd_t, twiki_exec_t, twiki_t)
# daemon_domain(twiki) gets this done anyway: #role_transition sysadm_r twiki_exec_t system_r;
domain_auto_trans(sysadm_crond_t, twiki_exec_t, twiki_t) # domain_auto_tras should do it, but duplicating it doesn't hurt: role sysadm_r types twiki_t; allow sysadm_crond_t twiki_t:process transition;
# exe=/usr/bin/perl path=/etc/ld.so.cache : allow twiki_t etc_t:file { getattr read };
allow httpd_t twiki_exec_t:dir { getattr search }; allow httpd_t twiki_exec_t:file ioctl; allow httpd_t twiki_var_lib_t:dir { getattr read search }; allow httpd_t twiki_var_lib_t:file { append getattr ioctl read }; allow twiki_t bin_t:dir { search }; allow twiki_t bin_t:file { getattr }; allow twiki_t crond_t:fifo_file { ioctl read write }; allow twiki_t home_root_t:dir { search }; allow twiki_t twiki_exec_t:dir { search }; allow twiki_t urandom_device_t:chr_file { read };
allow twiki_t unlabeled_t:dir { getattr read search };
allow httpd_sys_script_t httpd_runtime_t:file write; allow httpd_sys_script_t httpd_t:tcp_socket ioctl; allow httpd_sys_script_t twiki_var_lib_t:dir { add_name remove_name search write }; allow httpd_sys_script_t twiki_var_lib_t:file { create getattr read unlink }; allow httpd_t twiki_var_lib_t:dir { add_name remove_name write }; allow httpd_t twiki_var_lib_t:file { create rename setattr unlink write }; #END
The problem is, although the domain_auto_trans(sysadm_crond_t, twiki_exec_t, twiki_t) ...allows for: allow sysadm_crond_t twiki_t:process transition;
And I've even allowed that process transition (allow sysadm_crond_t twiki_t:process transition;) explicitly a few rows later (actually audit2allow has given me this).
But the transition to root:system_r:twiki_t is still denied.
Am I missing something?
On Thu, 2005-05-26 at 03:39 +0200, Aleksander Adamowski wrote:
Hi!
I'm having a problem with FC3 strict policy. Basically, I've customised the policy to cover all that I need on that system, but there's one last denial that I'm unable to remedy:
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. Hence, you are hitting a constraint in policy/constraints that says that a process may not change roles unless it meets certain restrictions. The role transition is occurring because you have declared it as a daemon domain, thus it is trying to transition to the system_r role for system processes.
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. - Is using daemon_domain truly appropriate here? I'm a little skeptical. - Why are you giving it access to unlabeled_t? Suggests some other problem with your filesystem labels or use of non-labeled fs.
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.
On Fri, 2005-05-27 at 21:39 +0200, Aleksander Adamowski wrote:
Soon, checkpolicy for FC3 will have support for typeattribute construct:
https://www.redhat.com/archives/fedora-cvs-commits/2005-May/msg00593.html
I doubt it. FC3 only gets bug fixes, not enhancements. You'll have to pull from FC4/development if you want those changes.
Also, in general, if using strict policy, you are advised to track the development tree, as Red Hat hasn't been issuing updates to strict policy in FC3 at all.
Stephen Smalley wrote:
I doubt it. FC3 only gets bug fixes, not enhancements. You'll have to pull from FC4/development if you want those changes.
Also, in general, if using strict policy, you are advised to track the development tree, as Red Hat hasn't been issuing updates to strict policy in FC3 at all.
Strange, the patch is against FC-3 files:
/cvs/dist/rpms/checkpolicy/FC-3/checkpolicy-typeattribute.patch /cvs/dist/rpms/checkpolicy/FC-3/checkpolicy.spec
I thought it would go into a future package update...
On Wed, 2005-06-01 at 14:42 +0200, Aleksander Adamowski wrote:
Strange, the patch is against FC-3 files:
/cvs/dist/rpms/checkpolicy/FC-3/checkpolicy-typeattribute.patch /cvs/dist/rpms/checkpolicy/FC-3/checkpolicy.spec
I thought it would go into a future package update...
I could be wrong - Dan will know. My impression was that FC3 would only get bug fixes at this point, so I wouldn't have expected any changes to its checkpolicy program (unless they are required by an updated targeted policy for FC3).
selinux@lists.fedoraproject.org
-
Aleksander Adamowski -
Aleksander Adamowski -
Stephen Smalley