Hello. I am working on selinux support in initng, which is in review for extras now [1]. But it seems that initng requires a policy to work (just tested in targeted mode) Using the default context (sbin_t) lets all apps that are started from initng run as kernel_t. Relabling /sbin/initng to init_exec_t (same as init) fixes this and the processes run as init_t and udev_t for udev, but some issues still remain. hald,httpd, etc. also run as init_t which is *wrong* they have to get into their own domain. How is this handled in sysvinit? After reading the code I havn't found anything about it. The patch I wrote can be found here: http://bugzilla.initng.thinktux.net/show_bug.cgi?id=365 Did I do something wrong? Did I miss something? After fixing this we will run into an other problem. Every time the filesystem gots relabled initng will become sbin_t which will break it. To fix this we need to modify the selinux-policy. What should be done if a package in extras requires to change a core package? Should I just fill a bug against it and hope that it will be released as an update for FC4, and gets into rawhide too? Was unable to find anything about it in the wiki. 1: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=173459
dragoran wrote:
Hello. I am working on selinux support in initng, which is in review for extras now [1]. But it seems that initng requires a policy to work (just tested in targeted mode) Using the default context (sbin_t) lets all apps that are started from initng run as kernel_t.
What is the path? We can set it up in policy.
Relabling /sbin/initng to init_exec_t (same as init) fixes this and the processes run as init_t and udev_t for udev, but some issues still remain.
I will add to policy.
hald,httpd, etc. also run as init_t which is *wrong* they have to get into their own domain. How is this handled in sysvinit? After reading the code I havn't found anything about it.
Are the startup scripts marked initrc_exec_t?
The patch I wrote can be found here: http://bugzilla.initng.thinktux.net/show_bug.cgi?id=365 Did I do something wrong? Did I miss something? After fixing this we will run into an other problem. Every time the filesystem gots relabled initng will become sbin_t which will break it. To fix this we need to modify the selinux-policy. What should be done if a package in extras requires to change a core package? Should I just fill a bug against it and hope that it will be released as an update for FC4, and gets into rawhide too? Was unable to find anything about it in the wiki. 1: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=173459
-- fedora-selinux-list mailing list fedora-selinux-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-selinux-list
Daniel J Walsh wrote:
dragoran wrote:
Hello. I am working on selinux support in initng, which is in review for extras now [1]. But it seems that initng requires a policy to work (just tested in targeted mode) Using the default context (sbin_t) lets all apps that are started from initng run as kernel_t.
What is the path? We can set it up in policy.
Relabling /sbin/initng to init_exec_t (same as init) fixes this and the processes run as init_t and udev_t for udev, but some issues still remain.
I will add to policy.
ok thx
hald,httpd, etc. also run as init_t which is *wrong* they have to get into their own domain. How is this handled in sysvinit? After reading the code I havn't found anything about it.
Are the startup scripts marked initrc_exec_t?
yes I did chcon -t initrc_exec_t on all files in /etc/initng/system and /etc/initng/daemons
The patch I wrote can be found here: http://bugzilla.initng.thinktux.net/show_bug.cgi?id=365 Did I do something wrong? Did I miss something? After fixing this we will run into an other problem. Every time the filesystem gots relabled initng will become sbin_t which will break it. To fix this we need to modify the selinux-policy. What should be done if a package in extras requires to change a core package? Should I just fill a bug against it and hope that it will be released as an update for FC4, and gets into rawhide too? Was unable to find anything about it in the wiki. 1: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=173459
-- fedora-selinux-list mailing list fedora-selinux-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-selinux-list
dragoran schrieb:
Daniel J Walsh wrote:
dragoran wrote:
Hello. I am working on selinux support in initng, which is in review for extras now [1]. But it seems that initng requires a policy to work (just tested in targeted mode) Using the default context (sbin_t) lets all apps that are started from initng run as kernel_t.
What is the path? We can set it up in policy.
Relabling /sbin/initng to init_exec_t (same as init) fixes this and the processes run as init_t and udev_t for udev, but some issues still remain.
I will add to policy.
ok thx
hald,httpd, etc. also run as init_t which is *wrong* they have to get into their own domain. How is this handled in sysvinit? After reading the code I havn't found anything about it.
Are the startup scripts marked initrc_exec_t?
yes I did chcon -t initrc_exec_t on all files in /etc/initng/system and /etc/initng/daemons
checked this and found out that initng does not execute any scripts. the "scripts" are just files that contain infos about which daemon should be started and which deps it has. this results in hald beeing started directly from initng using execv(). This results in hald (and other services) run as init_t. If I put /sbin/service hald start into the exec line hald runs as hald_t. Why is a script required to get into the correct domain? Is there any way to fix this without adding setexeccon() for every daemon?
On Thu, 2006-02-02 at 18:07 +0100, dragoran wrote:
checked this and found out that initng does not execute any scripts. the "scripts" are just files that contain infos about which daemon should be started and which deps it has. this results in hald beeing started directly from initng using execv(). This results in hald (and other services) run as init_t. If I put /sbin/service hald start into the exec line hald runs as hald_t. Why is a script required to get into the correct domain? Is there any way to fix this without adding setexeccon() for every daemon?
The current policy only defines domain transitions from init (init_t) to rc (initrc_t) -> daemons. It doesn't define direct domain transitions from init_t to the daemon domains, except for a few cases where that has been necessary (getty, gdm). The policy could certainly also include additional transitions directly from init_t to the daemon domains, and that would work, but it will bloat the policy a bit to include both sets of transitions. The script isn't required; it just happens to be the current init approach, so that is what policy was written for. Adding setexeccon() to every daemon wouldn't be desirable or helpful.
Stephen Smalley wrote:
On Thu, 2006-02-02 at 18:07 +0100, dragoran wrote:
checked this and found out that initng does not execute any scripts. the "scripts" are just files that contain infos about which daemon should be started and which deps it has. this results in hald beeing started directly from initng using execv(). This results in hald (and other services) run as init_t. If I put /sbin/service hald start into the exec line hald runs as hald_t. Why is a script required to get into the correct domain? Is there any way to fix this without adding setexeccon() for every daemon?
The current policy only defines domain transitions from init (init_t) to rc (initrc_t) -> daemons. It doesn't define direct domain transitions from init_t to the daemon domains, except for a few cases where that has been necessary (getty, gdm). The policy could certainly also include additional transitions directly from init_t to the daemon domains, and that would work, but it will bloat the policy a bit to include both sets of transitions. The script isn't required; it just happens to be the current init approach, so that is what policy was written for. Adding setexeccon() to every daemon wouldn't be desirable or helpful.
so what is the solution? use setexecon() to run the daemons as initrc_t to let the domain transitions take effect? this should also be init_t -> initrc_t -> daemon .. or did I miss / missunderstood something?
On Thu, 2006-02-02 at 18:48 +0100, dragoran wrote:
so what is the solution? use setexecon() to run the daemons as initrc_t to let the domain transitions take effect?
No, that wouldn't work, nor it is useful.
this should also be init_t -> initrc_t -> daemon .. or did I miss / missunderstood something?
As I said, the policy could be extended to include direct transitions from init_t -> daemon domains so that initng would work as is. But that needs to be taken up on selinux list and directed to refpolicy maintainers.
Stephen Smalley wrote:
On Thu, 2006-02-02 at 18:48 +0100, dragoran wrote:
so what is the solution? use setexecon() to run the daemons as initrc_t to let the domain transitions take effect?
No, that wouldn't work, nor it is useful.
this should also be init_t -> initrc_t -> daemon .. or did I miss / missunderstood something?
As I said, the policy could be extended to include direct transitions from init_t -> daemon domains so that initng would work as is. But that needs to be taken up on selinux list and directed to refpolicy maintainers.
filled bug: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=179761
selinux@lists.fedoraproject.org