On Wednesday 23 July 2008 21:09, "Marco d'Itri" <[EMAIL PROTECTED]> wrote: > On Jul 23, Russell Coker <[EMAIL PROTECTED]> wrote: > > > Exactly why can't you fix the SELinux policy? > > > > If you define "fix" to mean "make it work with the current udev script" > > then that would involve either running /etc/init.d/udev as udevd_t (which > > will cause some issues with run_init) > > What kind of issues? Can't they be worked around? > Why moving part of the code to a different program would not be a > problem too?
Moving the code in question to a different program allows running it under a different security context. The concept is simply that scripts in /etc/init.d will start privileged programs and not do much else. The other programs (in locations such as /sbin) will be more privileged. This means that we can analyse the policy and determine what rights the various programs have. We can make a list of domains which are permitted to perform various privileged operations (such as creating device nodes) and then determine which programs might run in those domains. Being able to exclude all of /etc/init.d from such a list is a good thing (the simplest work-around would be to just permit all scripts in /etc/init.d to do such things). If we exclude the simplest (and worst) option, then running /etc/init.d/udev as udev_t would require changing run_init (which uses initrc_t exclusively for the scripts it runs) or having run_init call /etc/init.d/udev-runner (or some other script that is a wrapper for /etc/init.d/udev). > > The functionality of mounting the tmpfs on /dev and populating it with > > the bare minimum of devices is separate to the main functionality of > > udev. Why do you object to splitting the code according to function? > > For a start, I object on principle to changes requested by the > maintainers of other packages who cannot clearly show that changing my > package instead of their package is the right thing to do. > Then I object to changes I do not understand, because udev is complex > and its init script is very complex, so I do not want to have in my > package some important code whose implications I do not know about. The best way of understanding this would be to set up a SE Linux strict configuration machine. Would you like me to give you a Xen DomU for this purpose? I don't think that you will be able to really understand the issues unless you set it up. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
