On 02/19/2010 02:07 PM, Shintaro Fujiwara wrote: > 2010/2/19 Dominick Grift <domg472@xxxxxxxxx>: >> On 02/19/2010 01:41 PM, Shintaro Fujiwara wrote: >>> 2010/2/19 Dominick Grift <domg472@xxxxxxxxx>: >>>> On 02/19/2010 01:29 PM, Shintaro Fujiwara wrote: >>>>> 2010/2/19 Dominick Grift <domg472@xxxxxxxxx>: >>>>>> On 02/18/2010 10:17 PM, Shintaro Fujiwara wrote: >>>>>>> Hi, I 'm ready to start SELinux server in my office first time, and I >>>>>>> want to persuade everyone how safe the SELinux server is. >>>>>>> >>>>>>> How can I demonstrate administrators and my boss the advantage of >>>>>>> SELinux comparing other servers? >>>>>>> >>>>>>> SELinux play machine hit me but is too far or should I just >>>>>>> demonstrate in a certain ocassion for certain purpose? >>>>>> >>>>>> It depends a bit on your distro and policy model. >>>>>> >>>>>> But generally you can demonstrate how TE enforces integrity for targeted >>>>>> system daemons. >>>>>> >>>>>> If you use strict policy you can also enforce integrity for user >>>>>> processes. You can also demonstrate role based access control. >>>>>> >>>>>> You can demonstrate how MCS can be useful to restrict processes access >>>>>> to objects. >>>>>> >>>>>> If you use MLS model you can demonstrate enforcement of confidentiality. >>>>>> >>>>>> I never actually connected to play machine but i gather it mapped the >>>>>> root Linux login to the user_u SELinux user. >>>>>> >>>>> >>>>> Sounds great, bu if root became user_u, any other user should be id=0 ? >>>> >>>> No, root linux login is id 0, and root is in the user_u SELinux user group. >>>> >>>> So in practice you will end up with a restricted root. >>>> >>> >>> Thanks we both awake...9 >>> Yes, I know, but how can I configure, say semanage or anything if user >>> id 0 (root) is restricted by SELinux ? >>> Should I make, say user "fujiwara" id 0 also? >>> I don't know two user can be id 0, though... >>> Or you mean temporarily set root user_u ? >>> That'll make sense. >> >> Well it depends on your distro and policy model. If you use Fedora 12 >> for your demonstration then you can also use sudo. With for example >> rhel5 and strict policy you can probably use su plus newrole. >> >> So basically add a user, give the user access to root, but do not give >> the user access to a privileged SELinux userdomain. >> >> Or you can, like i stated, in my first example just map root (uid0) to >> user_u SELinux user. In that case you can still give a secondary normal >> user access to root in another domain using su/newrole or sudo. >> >> It is best to just try it out. >> >> (example fedora 12) >> >> semanage login -m -s user_u -r s0-s0 root >> useradd -Z stuff_u shintaro >> echo "shintaro ALL=(ALL) TYPE=sysadm_t ROLE=sysadm_r ALL" >> /etc/sudoers >> >> So when "root" logs in and does id -Z he will see >> user_u:user_r:user_u:s0. Root now cannot use suid application and only >> has access to user_t SELinux user domain. >> >> Linux user Shintaro by default is staff_u:staff_r:staff_t:s0 and has >> access to root via /etc/sudoers. The staff_u SELinux user group has >> access to the privileged administrator user domain called sysadm_t. So >> now Shintaro can do: sudo -s to open up a shell as root/sysadm_t which >> provides sufficient administrator permissions in terms of both DAC and MAC. > > Thanks now my name is in staff_u or I should say mapped... > But, isn't staff_u can't log in from ssh? > In fedora xx, the number I forgot, but Linux user mapped to staff_u > couldn't log in through sshd. > Or can I in F12 ? staff_u (staff_t) should be able to login with ssh. With F12 there are many nice ways to demonstrate. One of those demonstrations would be confined root. Sandbox (policycoreutils-sandbox) is also nice to demonstrate. Restricted users, restricted daemons, restricted user applications etc. etc. I created a series of articles and screen casts to demonstrate some of this functionality here: http://selinux-mac.blogspot.com/2009/06/selinux-screencasts.html http://selinux-mac.blogspot.com/2009/06/selinux-lockdown-part-one-confined.html http://selinux-mac.blogspot.com/2009/06/selinux-lockdown-part-three-permissive.html http://selinux-mac.blogspot.com/2009/06/selinux-lockdown-part-four-customized.html http://selinux-mac.blogspot.com/2009/06/selinux-lockdown-part-five-selinux-rbac.html http://selinux-mac.blogspot.com/2009/06/selinux-lockdown-part-six-customized.html http://selinux-mac.blogspot.com/2009/06/selinux-lockdown-part-seven-su-newrole.html http://selinux-mac.blogspot.com/2009/06/selinux-lockdown-part-eight-unconfined.html http://selinux-mac.blogspot.com/2009/06/selinux-lockdown-part-nine-booleans.html > It's a very good idea that confine the user root and make myown be > real-root or say, using sudo to certain domain. > I can demonstrate that with the document which Japanes Secure OS group > guys ( I'm also a member) made last year. > I will translate it into English so that you guys can see it thouroughly. > We would like to propagate this good contrivance through net or over hand. > Thanks. > > > > > > >> >>> >>> >>>>> >>>>> >>>>>> There are a lot of ways to demonstrate SELinux. You could restrict a >>>>>> simple hello world shell script and shows what happens if you extend the >>>>>> script to make it do something it is not intended to do. >>>>>> >>>>>> Same goes for webapplications. You could write a webapp and make it do >>>>>> something that SELinux policy does not allow it to do. >>>>>> >>>>>> Generally TE tries to prevent privilege escalation. It restricts processes. >>>>>> >>>>> >>>>> Yes, thanks, but I want to demonstrate how SELinux denies when web >>>>> application's vulnerability exists. >>>>> Say, it could not get root's priviladges. >>>> >>> >>>> In that case find or engineer a web application vulnerability and >>>> demonstrate how SELinux is able to prevent privilege escalation. >>>> >>> >>> OK, I think I can do that. >>> But apache has any vulnerability? >>> Oh, we should not talk this matter.. >>> >>>>>>> Thanks in advance. >>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> selinux mailing list >>>>>> selinux@xxxxxxxxxxxxxxxxxxxxxxx >>>>>> https://admin.fedoraproject.org/mailman/listinfo/selinux >>>>>> >>>>> >>>>> >>>>> >>>> >>>> >>>> >>> >>> >>> >> >> >> > > >
Attachment:
signature.asc
Description: OpenPGP digital signature
-- selinux mailing list selinux@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/selinux
