How can I start SELinux play machine ?

Shintaro Fujiwara shintaro.fujiwara at gmail.com
Fri Feb 19 13:49:15 UTC 2010


Thanks again my name is on the internet !
Though I do not so lucrative business I am a service person, you know, HAHA.
But sshd_config is set "RootLogin no" cause dangerous in normal Linux world.
Hey, but I could understand using semangae login thing and using
sandbox or anything you guys contrived.

To Mr Walsh
I forgot to post on fedora-selinux-list, so...

2010/2/19 Daniel J Walsh <dwalsh at redhat.com>:
> On 02/19/2010 08:07 AM, Shintaro Fujiwara wrote:
>>
>> 2010/2/19 Dominick Grift<domg472 at gmail.com>:
>>
>>>
>>> On 02/19/2010 01:41 PM, Shintaro Fujiwara wrote:
>>>
>>>>
>>>> 2010/2/19 Dominick Grift<domg472 at gmail.com>:
>>>>
>>>>>
>>>>> On 02/19/2010 01:29 PM, Shintaro Fujiwara wrote:
>>>>>
>>>>>>
>>>>>> 2010/2/19 Dominick Grift<domg472 at gmail.com>:
>>>>>>
>>>>>>>
>>>>>>> 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 at lists.fedoraproject.org
>>>>>>> https://admin.fedoraproject.org/mailman/listinfo/selinux
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>
>>
>>
>
> Shintaro, you can also setup root to login as user_t when logging in via ssh
> and unconfined_t when logging as locallogin.
>
> Although I am not sure user_t will even be allowed to login as root.
>
>
>
>



-- 
http://intrajp.no-ip.com/ Home Page


More information about the selinux mailing list