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 ? 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 >>>>> >>>> >>>> >>>> >>> >>> >>> >> >> >> > > > -- http://intrajp.no-ip.com/ Home Page -- selinux mailing list selinux@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/selinux
