8:39 p.m.
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?
--
Best Regards,
Aleksander Adamowski
GG#: 274614
ICQ UIN: 19780575
http://olo.ab.altkom.pl
7:22 a.m.
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
National Security Agency
2:39 p.m.
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
9:11 a.m.
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
National Security Agency
7:42 a.m.
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...
--
Best Regards,
Aleksander Adamowski
GG#: 274614
ICQ UIN: 19780575
http://olo.ab.altkom.pl
7:35 a.m.
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).
--
Stephen Smalley
National Security Agency
6911
days inactive
6917
days old
selinux@lists.fedoraproject.org
5 comments
3 participants
participants (3)
-
Aleksander Adamowski -
Aleksander Adamowski -
Stephen Smalley