On 10/21/2010 07:36 AM, Shaz wrote:
On Thu, Oct 21, 2010 at 6:40 PM, Justin P. Mattock <justinmattock@xxxxxxxxx <mailto:justinmattock@xxxxxxxxx>> wrote: On 10/21/2010 12:08 AM, Shaz wrote: On Thu, Oct 21, 2010 at 11:48 AM, Justin P. Mattock <justinmattock@xxxxxxxxx <mailto:justinmattock@xxxxxxxxx> <mailto:justinmattock@xxxxxxxxx <mailto:justinmattock@xxxxxxxxx>>> wrote: > On 10/20/2010 11:26 PM, Shaz wrote: >> >> On Thu, Oct 21, 2010 at 10:15 AM, Justin P. Mattock >> <justinmattock@xxxxxxxxx <mailto:justinmattock@xxxxxxxxx> <mailto:justinmattock@xxxxxxxxx <mailto:justinmattock@xxxxxxxxx>>> wrote: >>> >>> On 10/20/2010 07:44 PM, Serge E. Hallyn wrote: >>>> >>>> Quoting Justin P. Mattock (justinmattock@xxxxxxxxx <mailto:justinmattock@xxxxxxxxx> <mailto:justinmattock@xxxxxxxxx <mailto:justinmattock@xxxxxxxxx>>): >>>>> >>>>> o.k. finally connected the dots that I needed to create a initrd.img >>>>> in order for this to load(im a total newbie!!) >>>>> >>>>> Anyways the policy loads everything went in and am now in full >>>>> enforcement mode.. only real issue is with lxde >>>>> same bug here: >>>>> https://bugzilla.redhat.com/show_bug.cgi?id=552885 >>>>> >>>>> seems lxde is in /usr/sbin reason probably for the wrong filelabel.. >>>> >>>> Cool, so does following the steps outlined in that bug make it >>>> work for you? >>>> >>> >>> What I normally have is /boot/System.map-* and vmlinuz-* to load the >>> kernel.. Seems sysvinit knows how to take things there and load_policy() >>> >>> for upstart whatever it's doing(like what you said) needs to go through >>> initrd. Yesterday I though thats what I had done with: >>> fakeroot make-kpkg --initrd --append-to-version=-custom kernel_image >>> kernel_headers >>> >>> but missed one last step: >>> mkinitramfs -k -o initrd.img-2.6.36-rc8-custom-00022-g2b666ca >>> then after doing this everything loaded as is.. >>> >>> Note: guess this is whats being called to do all of this: >>> /usr/share/initramfs-tools/scripts/init-bottom/_load_selinux_policy >>> >>> As for the file labels in /var/run seems most of the files in there are >>> labeled with initrc_t (keep in mind I chose debian as the distro in >>> build.conf, so maybe this is why).. >>> >>> As for lxde, before using chcon I was getting a login context of >>> name:staff_r:netutils_t:s0 then after relabeling those files: >>> >>> (chcon to this context like the bug report had shown) >>> system_u:object_r:xdm_exec_t:s0 /usr/sbin/lxdm >>> system_u:object_r:xdm_exec_t:s0 /usr/sbin/lxdm-binary >>> system_u:object_r:xdm_var_run_t:s0 lxdm.pid >>> >>> I login with the proper context that I chose: >>> name:staff_r:staff_t:s0 >>> >>> Right now I think everything is running o.k. on this operating system.. >>> (nice,small, and functional..with a touch of SELinux on top...) >> >> Dear Justin, >> >> "initrd" helps to load selinux and label "init" so that transitions >> can take effect. Be it upstart or sysvinit! >> >> If this is not done then all your processes will be loaded with >> unconfined_t. Rest of the details you are considering should not >> matter and they might be confusing if you tried to load selinux with >> experimentation rather then proper bootstrap through initrd. >> >> Hope this helps. >> > > well my other machines do not use an initrd image file in /boot only > System.map and vmlinuz(I guess doing make, make install for the kernel is a > bit outdated these days).. > > Anyways sysvinit always loaded the policy just fine and had the processes > correct, as for upstart seems I needed to do the whole > make-kpkg,dpkg,mkinitramfs thing..(which is fine... but would rather keep it > more simpler). AFAIK without initrd your policy will not work properly as labeling is not handled and thus the whole security objective fails. If this is possible without an initrd then it would be init handling it by loading selinux and restarting itself. pretty much what I use over here..(make bisecting easier since I dont have to deal with the hundreds of vmlinuz tags, just one that gets written over) Now the question(I guess)is, is how/why is upstart not _realizing_ this is a system without initrd lets go over here and get the system started? (id imagine the code might have if then/else or something..) Why do you expect Upstart or init to know if initrd was used or not?
well, I guess it's safe to say there are people in the world who dont make initrd images for their system(unless Im the only one..)
Is
this a feature that upstart should handle?
would of been nice, this way I didn't have to wast my time tracking down why load_policy() is not loading..(but ended up being a good learning experience)
I guess not because initrd is
used for early drivers and configuration before the rootfs can be utilized properly.
sure.. and as well as not having initrd..(like what I have over here) Justin P. Mattock -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@xxxxxxxxxxxxx with the words "unsubscribe selinux" without quotes as the message.
