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?
Thanks in advance.
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.
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.
Thanks in advance.
On 02/18/2010 04:44 PM, Dominick Grift wrote:
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.
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.
Thanks in advance.
-- selinux mailing list selinux@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/selinux
Simple demonstration in Fedora 12. Create a script.
cat > /usr/bin/showshadow << _EOF #!/bin/sh id cat /etc/shadow _EOF
chmod +x /usr/bin/showshadow
showshadow uid=0(root) gid=0(root) groups=0(root),1(bin),2(daemon),3(sys),4(adm),6(disk),10(wheel) context=staff_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 root:*::: bin:*:14043:0:99999:7::: daemon:*:14043:0:99999:7::: adm:*:14043:0:99999:7::: lp:*:14043:0:99999:7::: sync:*:14043:0:99999:7::: shutdown:*:14043:0:99999:7::: halt:*:14043:0:99999:7::: mail:*:14043:0:99999:7::: news:*:14043:0:99999:7::: uucp:*:14043:0:99999:7::: operator:*:14043:0:99999:7::: games:*:14043:0:99999:7::: gopher:*:14043:0:99999:7::: ftp:*:14043:0:99999:7::: nobody:*:14043:0:99999:7::: vcsa:!!:14043:0:99999:7::: distcache:!!:14043:0:99999:7::: nscd:!!:14043:0:99999:7::: tcpdump:!!:14043:0:99999:7:::
# sandbox showshadow uid=0 gid=0 groups=0,1,2,3,4,6,10 context=staff_u:unconfined_r:sandbox_t:s0:c512,c625 cat: /etc/shadow: Permission denied
To see the error message
# ausearch -m avc -ts recent ---- time->Thu Feb 18 17:03:36 2010 type=PATH msg=audit(1266530616.620:1997): item=0 name="/etc/shadow" inode=5688120 dev=fd:01 mode=0100400 ouid=0 ogid=0 rdev=00:00 obj=system_u:object_r:shadow_t:s0 type=CWD msg=audit(1266530616.620:1997): cwd="/tmp" type=SYSCALL msg=audit(1266530616.620:1997): arch=c000003e syscall=2 success=no exit=-13 a0=7fff6bb88798 a1=0 a2=7fff6bb88120 a3=a items=1 ppid=26934 pid=26938 auid=3267 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0 ses=3 comm="cat" exe="/bin/cat" subj=staff_u:unconfined_r:sandbox_t:s0:c512,c625 key=(null) type=AVC msg=audit(1266530616.620:1997): avc: denied { open } for pid=26938 comm="cat" name="shadow" dev=dm-1 ino=5688120 scontext=staff_u:unconfined_r:sandbox_t:s0:c512,c625 tcontext=system_u:object_r:shadow_t:s0 tclass=file
grep shadow /var/log/messages Feb 18 17:03:42 localhost setroubleshoot: SELinux is preventing /bin/cat "open" access on /etc/shadow. For complete SELinux messages. run sealert -l 95108dbb-8254-4a00-886d-028bafa4996a
What's sandbox showshadow ? I didn't know the command sandbox. Pretty interesting. But my boss doesn't konw what the /etc/shadow is...
2010/2/19 Daniel J Walsh dwalsh@redhat.com:
On 02/18/2010 04:44 PM, Dominick Grift wrote:
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. 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.
Thanks in advance.
-- selinux mailing list selinux@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/selinux
Simple demonstration in Fedora 12. Create a script.
cat > /usr/bin/showshadow << _EOF #!/bin/sh id cat /etc/shadow _EOF
chmod +x /usr/bin/showshadow
showshadow uid=0(root) gid=0(root) groups=0(root),1(bin),2(daemon),3(sys),4(adm),6(disk),10(wheel) context=staff_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 root:*::: bin:*:14043:0:99999:7::: daemon:*:14043:0:99999:7::: adm:*:14043:0:99999:7::: lp:*:14043:0:99999:7::: sync:*:14043:0:99999:7::: shutdown:*:14043:0:99999:7::: halt:*:14043:0:99999:7::: mail:*:14043:0:99999:7::: news:*:14043:0:99999:7::: uucp:*:14043:0:99999:7::: operator:*:14043:0:99999:7::: games:*:14043:0:99999:7::: gopher:*:14043:0:99999:7::: ftp:*:14043:0:99999:7::: nobody:*:14043:0:99999:7::: vcsa:!!:14043:0:99999:7::: distcache:!!:14043:0:99999:7::: nscd:!!:14043:0:99999:7::: tcpdump:!!:14043:0:99999:7:::
# sandbox showshadow uid=0 gid=0 groups=0,1,2,3,4,6,10 context=staff_u:unconfined_r:sandbox_t:s0:c512,c625 cat: /etc/shadow: Permission denied
To see the error message
# ausearch -m avc -ts recent
time->Thu Feb 18 17:03:36 2010 type=PATH msg=audit(1266530616.620:1997): item=0 name="/etc/shadow" inode=5688120 dev=fd:01 mode=0100400 ouid=0 ogid=0 rdev=00:00 obj=system_u:object_r:shadow_t:s0 type=CWD msg=audit(1266530616.620:1997): cwd="/tmp" type=SYSCALL msg=audit(1266530616.620:1997): arch=c000003e syscall=2 success=no exit=-13 a0=7fff6bb88798 a1=0 a2=7fff6bb88120 a3=a items=1 ppid=26934 pid=26938 auid=3267 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0 ses=3 comm="cat" exe="/bin/cat" subj=staff_u:unconfined_r:sandbox_t:s0:c512,c625 key=(null) type=AVC msg=audit(1266530616.620:1997): avc: denied { open } for pid=26938 comm="cat" name="shadow" dev=dm-1 ino=5688120 scontext=staff_u:unconfined_r:sandbox_t:s0:c512,c625 tcontext=system_u:object_r:shadow_t:s0 tclass=file
grep shadow /var/log/messages Feb 18 17:03:42 localhost setroubleshoot: SELinux is preventing /bin/cat "open" access on /etc/shadow. For complete SELinux messages. run sealert -l 95108dbb-8254-4a00-886d-028bafa4996a
-- selinux mailing list selinux@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/selinux
2010/2/19 Dominick Grift domg472@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 ?
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.
Thanks in advance.
-- selinux mailing list selinux@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/selinux
On 02/19/2010 01:29 PM, Shintaro Fujiwara wrote:
2010/2/19 Dominick Grift domg472@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.
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.
Thanks in advance.
-- selinux mailing list selinux@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/selinux
2010/2/19 Dominick Grift domg472@gmail.com:
On 02/19/2010 01:29 PM, Shintaro Fujiwara wrote:
2010/2/19 Dominick Grift domg472@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.
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@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/selinux
On 02/19/2010 01:41 PM, Shintaro Fujiwara wrote:
2010/2/19 Dominick Grift domg472@gmail.com:
On 02/19/2010 01:29 PM, Shintaro Fujiwara wrote:
2010/2/19 Dominick Grift domg472@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.
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@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/selinux
2010/2/19 Dominick Grift domg472@gmail.com:
On 02/19/2010 01:41 PM, Shintaro Fujiwara wrote:
2010/2/19 Dominick Grift domg472@gmail.com:
On 02/19/2010 01:29 PM, Shintaro Fujiwara wrote:
2010/2/19 Dominick Grift domg472@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@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/selinux
On 02/19/2010 02:07 PM, Shintaro Fujiwara wrote:
2010/2/19 Dominick Grift domg472@gmail.com:
On 02/19/2010 01:41 PM, Shintaro Fujiwara wrote:
2010/2/19 Dominick Grift domg472@gmail.com:
On 02/19/2010 01:29 PM, Shintaro Fujiwara wrote:
2010/2/19 Dominick Grift domg472@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 ?
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.h... http://selinux-mac.blogspot.com/2009/06/selinux-lockdown-part-three-permissi... http://selinux-mac.blogspot.com/2009/06/selinux-lockdown-part-four-customize... http://selinux-mac.blogspot.com/2009/06/selinux-lockdown-part-five-selinux-r... http://selinux-mac.blogspot.com/2009/06/selinux-lockdown-part-six-customized... http://selinux-mac.blogspot.com/2009/06/selinux-lockdown-part-seven-su-newro... http://selinux-mac.blogspot.com/2009/06/selinux-lockdown-part-eight-unconfin... http://selinux-mac.blogspot.com/2009/06/selinux-lockdown-part-nine-booleans....
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@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/selinux
On 02/19/2010 08:07 AM, Shintaro Fujiwara wrote:
2010/2/19 Dominick Griftdomg472@gmail.com:
On 02/19/2010 01:41 PM, Shintaro Fujiwara wrote:
2010/2/19 Dominick Griftdomg472@gmail.com:
On 02/19/2010 01:29 PM, Shintaro Fujiwara wrote:
2010/2/19 Dominick Griftdomg472@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@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.
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@redhat.com:
On 02/19/2010 08:07 AM, Shintaro Fujiwara wrote:
2010/2/19 Dominick Griftdomg472@gmail.com:
On 02/19/2010 01:41 PM, Shintaro Fujiwara wrote:
2010/2/19 Dominick Griftdomg472@gmail.com:
On 02/19/2010 01:29 PM, Shintaro Fujiwara wrote:
2010/2/19 Dominick Griftdomg472@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@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.
selinux@lists.fedoraproject.org
-
Daniel J Walsh -
Dominick Grift -
Shintaro Fujiwara