Hello,
I'm experimenting with SELinux policies again. I've got a test server set up now, so I have a bit more freedom and flexibility. I have a policy that is basically working, and wanted to get some feedback on it.
I'm working on designing a security architecture for a Web application we have under development, and creating an SELinux policy to help implement it. I would like to prevent any flaws in Apache or the Web application from leaking access to other HTTP worker processes for current or future connections, where credentials of other users may be accessible.
The Web server begins in the httpd_t domain, which has somewhat more privileges than our application needs. For example it has access to the listening HTTP socket, where it could accept new connections and so access future connections. I would like to reduce the privileges of the HTTP worker processes after the connection is accepted but before any user data has been processed or our application code has been executed.
I have this working with some mod_perl code which hooks into Apache right after it accepts the connection, and changes its running domain to httpd_portal_app_t. I did this by allowing a dyntransition from httpd_t to httpd_portal_app_t, then writing the new context to "/proc/$$/attr/current", and verified it is working with ps -Z. That domain has a smaller set of privileges than httpd_t, and is not allowed to do things like accept new connections, listen on new sockets, read from log files, etc. There is no rule allowing httpd_portal_app_t to transition back to httpd_t, and after handling a single connection, the process exits (it is configured with the Apache option MaxRequestsPerChild 1).
I am still testing and prototyping, but so far this is all working. I have a few questions, though.
First, I see a lot of warnings in "SELinux by example" and other places on the Web about how using dyntransition is a bad idea. Is that true in this case, and if so is there a better way to get a similar degree of isolation without taking the performance hit that a CGI-based environment would cost?
Second, in RHEL 5, is there a way to constrain my httpd_portal_app_t to have its permission set bounded by that of httpd_t? That is, so that httpd_portal_app_t cannot have any privileges that httpd_t does not have? I see that some versions of SELinux are able to enforce this with the "typebounds" command, but that doesn't seem to be available in RHEL 5? That would help me ensure that this domain could only make things more secure, not less.
Third, since my main goal here is to prevent processes from interacting with each other inappropriately, I would like to prevent each HTTP worker from reading any information from "/proc" for other HTTP workers. Currently they are allowed to do this, because they all run in the same domain. Is there any way to prevent this?
Finally, if anybody has any thoughts or suggestions from doing similar applications, your thoughts are appreciated.
Thanks!
-----Scott.
You might want to look at: http://code.google.com/p/sepgsql/wiki/Apache_SELinux_plus
Ted
On Sat, Jan 15, 2011 at 7:45 PM, Scott Gifford sgifford@suspectclass.com wrote:
Hello, I'm experimenting with SELinux policies again. I've got a test server set up now, so I have a bit more freedom and flexibility. I have a policy that is basically working, and wanted to get some feedback on it. I'm working on designing a security architecture for a Web application we have under development, and creating an SELinux policy to help implement it. I would like to prevent any flaws in Apache or the Web application from leaking access to other HTTP worker processes for current or future connections, where credentials of other users may be accessible. The Web server begins in the httpd_t domain, which has somewhat more privileges than our application needs. For example it has access to the listening HTTP socket, where it could accept new connections and so access future connections. I would like to reduce the privileges of the HTTP worker processes after the connection is accepted but before any user data has been processed or our application code has been executed. I have this working with some mod_perl code which hooks into Apache right after it accepts the connection, and changes its running domain to httpd_portal_app_t. I did this by allowing a dyntransition from httpd_t to httpd_portal_app_t, then writing the new context to "/proc/$$/attr/current", and verified it is working with ps -Z. That domain has a smaller set of privileges than httpd_t, and is not allowed to do things like accept new connections, listen on new sockets, read from log files, etc. There is no rule allowing httpd_portal_app_t to transition back to httpd_t, and after handling a single connection, the process exits (it is configured with the Apache option MaxRequestsPerChild 1). I am still testing and prototyping, but so far this is all working. I have a few questions, though. First, I see a lot of warnings in "SELinux by example" and other places on the Web about how using dyntransition is a bad idea. Is that true in this case, and if so is there a better way to get a similar degree of isolation without taking the performance hit that a CGI-based environment would cost? Second, in RHEL 5, is there a way to constrain my httpd_portal_app_t to have its permission set bounded by that of httpd_t? That is, so that httpd_portal_app_t cannot have any privileges that httpd_t does not have? I see that some versions of SELinux are able to enforce this with the "typebounds" command, but that doesn't seem to be available in RHEL 5? That would help me ensure that this domain could only make things more secure, not less. Third, since my main goal here is to prevent processes from interacting with each other inappropriately, I would like to prevent each HTTP worker from reading any information from "/proc" for other HTTP workers. Currently they are allowed to do this, because they all run in the same domain. Is there any way to prevent this? Finally, if anybody has any thoughts or suggestions from doing similar applications, your thoughts are appreciated. Thanks! -----Scott.
-- selinux mailing list selinux@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/selinux
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 01/15/2011 08:45 PM, Scott Gifford wrote:
Hello,
I'm experimenting with SELinux policies again. I've got a test server set up now, so I have a bit more freedom and flexibility. I have a policy that is basically working, and wanted to get some feedback on it.
I'm working on designing a security architecture for a Web application we have under development, and creating an SELinux policy to help implement it. I would like to prevent any flaws in Apache or the Web application from leaking access to other HTTP worker processes for current or future connections, where credentials of other users may be accessible.
The Web server begins in the httpd_t domain, which has somewhat more privileges than our application needs. For example it has access to the listening HTTP socket, where it could accept new connections and so access future connections. I would like to reduce the privileges of the HTTP worker processes after the connection is accepted but before any user data has been processed or our application code has been executed.
I have this working with some mod_perl code which hooks into Apache right after it accepts the connection, and changes its running domain to httpd_portal_app_t. I did this by allowing a dyntransition from httpd_t to httpd_portal_app_t, then writing the new context to "/proc/$$/attr/current", and verified it is working with ps -Z. That domain has a smaller set of privileges than httpd_t, and is not allowed to do things like accept new connections, listen on new sockets, read from log files, etc. There is no rule allowing httpd_portal_app_t to transition back to httpd_t, and after handling a single connection, the process exits (it is configured with the Apache option MaxRequestsPerChild 1).
I am still testing and prototyping, but so far this is all working. I have a few questions, though.
First, I see a lot of warnings in "SELinux by example" and other places on the Web about how using dyntransition is a bad idea. Is that true in this case, and if so is there a better way to get a similar degree of isolation without taking the performance hit that a CGI-based environment would cost?
It is a matter of the http_portal_app_t might be able to influence httpd_t through some back channel that SELinux does not block. Basically the books and literature is saying setexeccon/fork/exec is more secure then fork/setexec.
Second, in RHEL 5, is there a way to constrain my httpd_portal_app_t to have its permission set bounded by that of httpd_t? That is, so that httpd_portal_app_t cannot have any privileges that httpd_t does not have? I see that some versions of SELinux are able to enforce this with the "typebounds" command, but that doesn't seem to be available in RHEL 5? That would help me ensure that this domain could only make things more secure, not less.
No. The stuff you are reading about is not available as far as I know.
Third, since my main goal here is to prevent processes from interacting with each other inappropriately, I would like to prevent each HTTP worker from reading any information from "/proc" for other HTTP workers. Currently they are allowed to do this, because they all run in the same domain. Is there any way to prevent this?
libvirt and sandbox use MCS separation for this. Basically they grab random MCS labels to separate the processes. I would suggest using two Categories, s0:c0-c1023,c0-1023 and make sure they are never the same.
s0:c1,c43 s0:c2,c43
Is fine.
s0:c1,c1 is not
Then just set that context and you should get separation. if you need the processes to handle data it might get a little more complicated.
Finally, if anybody has any thoughts or suggestions from doing similar applications, your thoughts are appreciated.
Thanks!
-----Scott.
-- selinux mailing list selinux@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/selinux
On Mon, Jan 17, 2011 at 2:45 PM, Daniel J Walsh dwalsh@redhat.com wrote: [ ... ]
Third, since my main goal here is to prevent processes from interacting
with
each other inappropriately, I would like to prevent each HTTP worker from reading any information from "/proc" for other HTTP workers. Currently
they
are allowed to do this, because they all run in the same domain. Is
there
any way to prevent this?
libvirt and sandbox use MCS separation for this. Basically they grab random MCS labels to separate the processes. I would suggest using two Categories, s0:c0-c1023,c0-1023 and make sure they are never the same.
s0:c1,c43 s0:c2,c43
Is fine.
s0:c1,c1 is not
Then just set that context and you should get separation. if you need the processes to handle data it might get a little more complicated.
Thanks! I think I will need to learn a little more about this feature before I can use it. I will need a way to generate a unique category number (maybe from the PID?), and the processes will need to handle some shared data and code, so I will need to figure that out as well.
I will also look in more detail at Apache_SELinux_plus, I had skimmed through the material but I should read it in more detail. Thanks for the tip Ted!
I will see what progress I can make and post again if I have more questions. I really appreciate all the helpful people on this list!
-----Scott.
On Mon, Jan 17, 2011 at 11:27 PM, Scott Gifford sgifford@suspectclass.comwrote:
On Mon, Jan 17, 2011 at 2:45 PM, Daniel J Walsh dwalsh@redhat.com wrote: [ ... ]
Third, since my main goal here is to prevent processes from interacting
with
each other inappropriately, I would like to prevent each HTTP worker
from
reading any information from "/proc" for other HTTP workers. Currently
they
are allowed to do this, because they all run in the same domain. Is
there
any way to prevent this?
libvirt and sandbox use MCS separation for this. Basically they grab random MCS labels to separate the processes. I would suggest using two Categories, s0:c0-c1023,c0-1023 and make sure they are never the same.
s0:c1,c43 s0:c2,c43
Is fine.
s0:c1,c1 is not
Then just set that context and you should get separation. if you need the processes to handle data it might get a little more complicated.
Thanks! I think I will need to learn a little more about this feature before I can use it. I will need a way to generate a unique category number (maybe from the PID?), and the processes will need to handle some shared data and code, so I will need to figure that out as well.
OK, so I have started experimenting with this, but /proc is not behaving how I expect so far.
So I open up two shells. In the first I run:
runcon -l s0-s0:c0,c1 bash
and in the second:
runcon -l s0-s0:c0,c2 bash
So both should have access to c1, but only the first will have access to c1 and only the second will have access to c2.
When I try this on files, it works:
shell1$ *id -Z* user_u:system_r:unconfined_t:-s0:c0,c1 shell1$ *ls -lZ test.c1 test.c2* -rw-rw-r-- sgifford sgifford user_u:object_r:user_home_t:s0:c1 test.c1 -rw-rw-r-- sgifford sgifford user_u:object_r:user_home_t:s0:c2 test.c2 shell1$ *head -1 test.c1 test.c2* ==> test.c1 <== Category 1 head: cannot open `test.c2' for reading: Permission denied
But on /proc files it does not:
shell1$ *id -Z* user_u:system_r:unconfined_t:-s0:c0,c1 shell1$ *ls -lZ /proc/10961/maps* -r--r--r-- sgifford sgifford user_u:system_r:unconfined_t:-s0:c0,c2 /proc/10961/maps shell1$ *head -1 /proc/10961/maps* 002ac000-002ad000 r-xp 002ac000 00:00 0 [vdso]
That is, even though "ls -lZ" indicates that the maps file for PID 10961 requires c2 and my shell does not have c2, still I am allowed to read this file.
I must be misunderstanding something here. Any thoughts or hints?
Thanks!
-----Scott.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 02/20/2011 06:31 AM, Scott Gifford wrote:
On Mon, Jan 17, 2011 at 11:27 PM, Scott Gifford sgifford@suspectclass.comwrote:
On Mon, Jan 17, 2011 at 2:45 PM, Daniel J Walsh dwalsh@redhat.com wrote: [ ... ]
Third, since my main goal here is to prevent processes from interacting
with
each other inappropriately, I would like to prevent each HTTP worker
from
reading any information from "/proc" for other HTTP workers. Currently
they
are allowed to do this, because they all run in the same domain. Is
there
any way to prevent this?
libvirt and sandbox use MCS separation for this. Basically they grab random MCS labels to separate the processes. I would suggest using two Categories, s0:c0-c1023,c0-1023 and make sure they are never the same.
s0:c1,c43 s0:c2,c43
Is fine.
s0:c1,c1 is not
Then just set that context and you should get separation. if you need the processes to handle data it might get a little more complicated.
Thanks! I think I will need to learn a little more about this feature before I can use it. I will need a way to generate a unique category number (maybe from the PID?), and the processes will need to handle some shared data and code, so I will need to figure that out as well.
OK, so I have started experimenting with this, but /proc is not behaving how I expect so far.
So I open up two shells. In the first I run:
runcon -l s0-s0:c0,c1 bash
and in the second:
runcon -l s0-s0:c0,c2 bash
So both should have access to c1, but only the first will have access to c1 and only the second will have access to c2.
s0-s0:c0,c2 should not have access to c1
but
s0-s0:c0,c2 should
When I try this on files, it works:
shell1$ *id -Z* user_u:system_r:unconfined_t:-s0:c0,c1 shell1$ *ls -lZ test.c1 test.c2* -rw-rw-r-- sgifford sgifford user_u:object_r:user_home_t:s0:c1 test.c1 -rw-rw-r-- sgifford sgifford user_u:object_r:user_home_t:s0:c2 test.c2 shell1$ *head -1 test.c1 test.c2* ==> test.c1 <== Category 1 head: cannot open `test.c2' for reading: Permission denied
But on /proc files it does not:
shell1$ *id -Z* user_u:system_r:unconfined_t:-s0:c0,c1 shell1$ *ls -lZ /proc/10961/maps* -r--r--r-- sgifford sgifford user_u:system_r:unconfined_t:-s0:c0,c2 /proc/10961/maps shell1$ *head -1 /proc/10961/maps* 002ac000-002ad000 r-xp 002ac000 00:00 0 [vdso]
from /policy/mcs:
# Note: # - getattr on dirs/files is not constrained. # - /proc/pid operations are not constrained.
so that explains the above
That is, even though "ls -lZ" indicates that the maps file for PID 10961 requires c2 and my shell does not have c2, still I am allowed to read this file.
I must be misunderstanding something here. Any thoughts or hints?
Thanks!
-----Scott.
-- selinux mailing list selinux@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/selinux
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 02/20/2011 05:59 PM, Dominick Grift wrote:
On 02/20/2011 06:31 AM, Scott Gifford wrote:
On Mon, Jan 17, 2011 at 11:27 PM, Scott Gifford sgifford@suspectclass.comwrote:
On Mon, Jan 17, 2011 at 2:45 PM, Daniel J Walsh dwalsh@redhat.com wrote: [ ... ]
Third, since my main goal here is to prevent processes from interacting
with
each other inappropriately, I would like to prevent each HTTP worker
from
reading any information from "/proc" for other HTTP workers. Currently
they
are allowed to do this, because they all run in the same domain. Is
there
any way to prevent this?
libvirt and sandbox use MCS separation for this. Basically they grab random MCS labels to separate the processes. I would suggest using two Categories, s0:c0-c1023,c0-1023 and make sure they are never the same.
s0:c1,c43 s0:c2,c43
Is fine.
s0:c1,c1 is not
Then just set that context and you should get separation. if you need the processes to handle data it might get a little more complicated.
Thanks! I think I will need to learn a little more about this feature before I can use it. I will need a way to generate a unique category number (maybe from the PID?), and the processes will need to handle some shared data and code, so I will need to figure that out as well.
OK, so I have started experimenting with this, but /proc is not behaving how I expect so far.
So I open up two shells. In the first I run:
runcon -l s0-s0:c0,c1 bash
and in the second:
runcon -l s0-s0:c0,c2 bash
So both should have access to c1, but only the first will have access to c1 and only the second will have access to c2.
s0-s0:c0,c2 should not have access to c1
but
s0-s0:c0,c2 should
Err.. i meant: s0-s0:c0.c2 should
. signals a range (so c0.c2 means c0, c1 and c2). , is just a seperator (so c0,c2 mean c0 and c2).
When I try this on files, it works:
shell1$ *id -Z* user_u:system_r:unconfined_t:-s0:c0,c1 shell1$ *ls -lZ test.c1 test.c2* -rw-rw-r-- sgifford sgifford user_u:object_r:user_home_t:s0:c1 test.c1 -rw-rw-r-- sgifford sgifford user_u:object_r:user_home_t:s0:c2 test.c2 shell1$ *head -1 test.c1 test.c2* ==> test.c1 <== Category 1 head: cannot open `test.c2' for reading: Permission denied
But on /proc files it does not:
shell1$ *id -Z* user_u:system_r:unconfined_t:-s0:c0,c1 shell1$ *ls -lZ /proc/10961/maps* -r--r--r-- sgifford sgifford user_u:system_r:unconfined_t:-s0:c0,c2 /proc/10961/maps shell1$ *head -1 /proc/10961/maps* 002ac000-002ad000 r-xp 002ac000 00:00 0 [vdso]
from /policy/mcs:
# Note: # - getattr on dirs/files is not constrained. # - /proc/pid operations are not constrained.
so that explains the above
That is, even though "ls -lZ" indicates that the maps file for PID 10961 requires c2 and my shell does not have c2, still I am allowed to read this file.
I must be misunderstanding something here. Any thoughts or hints?
Thanks!
-----Scott.
-- selinux mailing list selinux@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/selinux
On Sun, Feb 20, 2011 at 12:02 PM, Dominick Grift domg472@gmail.com wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 02/20/2011 05:59 PM, Dominick Grift wrote:
On 02/20/2011 06:31 AM, Scott Gifford wrote:
[ ... ]
OK, so I have started experimenting with this, but /proc is not behaving
how
I expect so far.
So I open up two shells. In the first I run:
runcon -l s0-s0:c0,c1 bash
and in the second:
runcon -l s0-s0:c0,c2 bash
So both should have access to c1, but only the first will have access to
c1
and only the second will have access to c2.
Above I meant to say "both should have access to c0". [ ... ]
shell1$ *id -Z* user_u:system_r:unconfined_t:-s0:c0,c1 shell1$ *ls -lZ /proc/10961/maps* -r--r--r-- sgifford sgifford user_u:system_r:unconfined_t:-s0:c0,c2 /proc/10961/maps shell1$ *head -1 /proc/10961/maps* 002ac000-002ad000 r-xp 002ac000 00:00 0 [vdso]
from /policy/mcs:
# Note: # - getattr on dirs/files is not constrained. # - /proc/pid operations are not constrained.
so that explains the above
Ah, yes it does, thanks! I wonder if I can adjust this policy to get different behavior, or if it's hardcoded somewhere outside the policy?
-------Scott.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 02/20/2011 09:47 PM, Scott Gifford wrote:
On Sun, Feb 20, 2011 at 12:02 PM, Dominick Grift domg472@gmail.com wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 02/20/2011 05:59 PM, Dominick Grift wrote:
On 02/20/2011 06:31 AM, Scott Gifford wrote:
[ ... ]
OK, so I have started experimenting with this, but /proc is not behaving
how
I expect so far.
So I open up two shells. In the first I run:
runcon -l s0-s0:c0,c1 bash
and in the second:
runcon -l s0-s0:c0,c2 bash
So both should have access to c1, but only the first will have access to
c1
and only the second will have access to c2.
Above I meant to say "both should have access to c0". [ ... ]
shell1$ *id -Z* user_u:system_r:unconfined_t:-s0:c0,c1 shell1$ *ls -lZ /proc/10961/maps* -r--r--r-- sgifford sgifford user_u:system_r:unconfined_t:-s0:c0,c2 /proc/10961/maps shell1$ *head -1 /proc/10961/maps* 002ac000-002ad000 r-xp 002ac000 00:00 0 [vdso]
from /policy/mcs:
# Note: # - getattr on dirs/files is not constrained. # - /proc/pid operations are not constrained.
so that explains the above
Ah, yes it does, thanks! I wonder if I can adjust this policy to get different behavior, or if it's hardcoded somewhere outside the policy?
No, not hardcoded. This is just configuration (policy) you can define your own constraints, or modify existing ones.
-------Scott.
On Sun, Feb 20, 2011 at 4:05 PM, Dominick Grift domg472@gmail.com wrote:
On 02/20/2011 09:47 PM, Scott Gifford wrote:
On Sun, Feb 20, 2011 at 12:02 PM, Dominick Grift domg472@gmail.com
wrote:
[ ... ]
from /policy/mcs:
# Note: # - getattr on dirs/files is not constrained. # - /proc/pid operations are not constrained.
so that explains the above
Ah, yes it does, thanks! I wonder if I can adjust this policy to get different behavior, or if it's hardcoded somewhere outside the policy?
No, not hardcoded. This is just configuration (policy) you can define your own constraints, or modify existing ones.
OK, I think I've got this. I removed the "or ( t2 == domain )" from these rules in policy/mcs:
- - mlsconstrain dir { create getattr setattr read write link unlink rename search add_name remove_name reparent rmdir lock ioctl } - (( h1 dom h2 ) or ( t2 == domain ) or ( t1 == mlsfileread )); - - mlsconstrain file { read } - (( h1 dom h2 ) or ( t2 == domain ) or ( t1 == mlsfileread ));
and I seem to be getting the behavior I want. Anybody see any risks or downsides to this?
For long-term maintenance, it looks like I can't override this in my own module, I will need to patch the base policy, maybe by adding another patch to the serefpolicy-2.4.6 RPM specfile and maintaining this by hand? Is there a better way to maintain customizations to the base policy?
I think I can automatically generate a unique category set from a PID by using two MCS categories to represent each bit of the PID, the first for a 0-bit and the second for a 1-bit. That will take 32 categories for a 16-bit PID, which seems reasonable.
Thanks for the help!
-----Scott.
On Sun, Feb 20, 2011 at 5:54 PM, Scott Gifford sgifford@suspectclass.comwrote: [ ... ]
I think I can automatically generate a unique category set from a PID by using two MCS categories to represent each bit of the PID, the first for a 0-bit and the second for a 1-bit. That will take 32 categories for a 16-bit PID, which seems reasonable.
OK, I've got this working now, each PID gets a unique set of MCS categories, and so HTTPD child processes canot read each other's process information.
They do have to share files sometimes, so I designated c0 for that, and made sure the processes are always in c0. Now if something should be shared, it should remove all groups besides c0, and it will be shareable.
I expected to do this through file mapping in my module's .fc file, like this:
/var/www/portal_auth(/.*)? gen_context(system_u:object_r:httpd_sys_script_rw_t,s0,c0)
But when new files are created in /var/www/portal_auth, they still have all of the PID-specific categories, in addition to c0.
To make this work, I had to grant { setattr relabelfrom relabelto } to my Web app and make a call to setxattr to change the category on shared files.
That works, but it seems like it would be simpler and more secure to do this through file mappings in my modules .fc file.
Is there a mistake in my file context configuration above somewhere? Or am I misunderstanding how categories are applied from file context rules?
Thanks for any tips,
------Scott.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 02/21/2011 01:25 AM, Scott Gifford wrote:
On Sun, Feb 20, 2011 at 5:54 PM, Scott Gifford <sgifford@suspectclass.com mailto:sgifford@suspectclass.com> wrote: [ ... ]
I think I can automatically generate a unique category set from a PID by using two MCS categories to represent each bit of the PID, the first for a 0-bit and the second for a 1-bit. That will take 32 categories for a 16-bit PID, which seems reasonable.OK, I've got this working now, each PID gets a unique set of MCS categories, and so HTTPD child processes canot read each other's process information.
They do have to share files sometimes, so I designated c0 for that, and made sure the processes are always in c0. Now if something should be shared, it should remove all groups besides c0, and it will be shareable.
I expected to do this through file mapping in my module's .fc file, like this:
/var/www/portal_auth(/.*)? gen_context(system_u:object_r:httpd_sys_script_rw_t,s0,c0)But when new files are created in /var/www/portal_auth, they still have all of the PID-specific categories, in addition to c0.
To make this work, I had to grant { setattr relabelfrom relabelto } to my Web app and make a call to setxattr to change the category on shared files.
That works, but it seems like it would be simpler and more secure to do this through file mappings in my modules .fc file.
Is there a mistake in my file context configuration above somewhere? Or am I misunderstanding how categories are applied from file context rules?
Thanks for any tips,
------Scott.
-- selinux mailing list selinux@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/selinux
When a process running at MCS1 creates a file it will create the file with the same label MCS1. I am not sure what you are trying to do with /var/run/portal_auth, does every one of your scripts need to be able to read/write every file within the directory?
On Mon, Feb 21, 2011 at 11:46 AM, Daniel J Walsh dwalsh@redhat.com wrote:
On 02/21/2011 01:25 AM, Scott Gifford wrote:
[ ... ]
They do have to share files sometimes, so I designated c0 for that, and made sure the processes are always in c0. Now if something should be shared, it should remove all groups besides c0, and it will be shareable.
I expected to do this through file mapping in my module's .fc file, like this:
/var/www/portal_auth(/.*)? gen_context(system_u:object_r:httpd_sys_script_rw_t,s0,c0)But when new files are created in /var/www/portal_auth, they still have all of the PID-specific categories, in addition to c0.
To make this work, I had to grant { setattr relabelfrom relabelto } to my Web app and make a call to setxattr to change the category on shared files.
That works, but it seems like it would be simpler and more secure to do this through file mappings in my modules .fc file.
[ ... ]
When a process running at MCS1 creates a file it will create the file
with the same label MCS1. I am not sure what you are trying to do with /var/run/portal_auth, does every one of your scripts need to be able to read/write every file within the directory?
Yes, I am creating categories for my Web server child processes based on their PID to stop them from having access to each other's internal data in "/proc" (a variation on your earlier suggestion to "grab random MCS labels to separate the processes"), but the files in /var/run/portal_auth have session data that all the Web processes need access to.
I can keep using setxattr, that seems to work well enough.
But I guess I'm not clear on when and how the category field to gen_context in the .fc file is used?
Thanks,
------Scott.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 02/21/2011 12:37 PM, Scott Gifford wrote:
On Mon, Feb 21, 2011 at 11:46 AM, Daniel J Walsh <dwalsh@redhat.com mailto:dwalsh@redhat.com> wrote:
On 02/21/2011 01:25 AM, Scott Gifford wrote:[ ... ]
> They do have to share files sometimes, so I designated c0 for that, and > made sure the processes are always in c0. Now if something should be > shared, it should remove all groups besides c0, and it will be shareable. > > I expected to do this through file mapping in my module's .fc file, like > this: > > /var/www/portal_auth(/.*)? > gen_context(system_u:object_r:httpd_sys_script_rw_t,s0,c0) > > > But when new files are created in /var/www/portal_auth, they still have > all of the PID-specific categories, in addition to c0. > > To make this work, I had to grant { setattr relabelfrom relabelto } to > my Web app and make a call to setxattr to change the category on shared > files. > > That works, but it seems like it would be simpler and more secure to do > this through file mappings in my modules .fc file. [ ... ] When a process running at MCS1 creates a file it will create the file with the same label MCS1. I am not sure what you are trying to do with /var/run/portal_auth, does every one of your scripts need to be able to read/write every file within the directory?Yes, I am creating categories for my Web server child processes based on their PID to stop them from having access to each other's internal data in "/proc" (a variation on your earlier suggestion to "grab random MCS labels to separate the processes"), but the files in /var/run/portal_auth have session data that all the Web processes need access to.
I can keep using setxattr, that seems to work well enough.
But I guess I'm not clear on when and how the category field to gen_context in the .fc file is used?
Thanks,
------Scott.
-- selinux mailing list selinux@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/selinux
The syntax should have been:
/var/www/portal_auth(/.*)? gen_context(system_u:object_r:httpd_sys_script_rw_t,s0,s0:c0)
s0:c0 means Security Level s0 with category c0.
If you leave the files with no categories s0, then they should be able to read/write them.
Moving to categories provides isolation between the scripts, the goal would be for the scripts to not be able to attack each other, but allowing them to write to the same files potentially gives them a mechanism to attack each other.
On Mon, Feb 21, 2011 at 2:22 PM, Daniel J Walsh dwalsh@redhat.com wrote:
On 02/21/2011 12:37 PM, Scott Gifford wrote:
Yes, I am creating categories for my Web server child processes based on their PID to stop them from having access to each other's internal data in "/proc" (a variation on your earlier suggestion to "grab random MCS labels to separate the processes"), but the files in /var/run/portal_auth have session data that all the Web processes need access to.
I can keep using setxattr, that seems to work well enough.
But I guess I'm not clear on when and how the category field to gen_context in the .fc file is used?
[ ... ]
The syntax should have been:
/var/www/portal_auth(/.*)? gen_context(system_u:object_r:httpd_sys_script_rw_t,s0,s0:c0)
s0:c0 means Security Level s0 with category c0.
When I try that I get this error:
libsepol.mls_from_string: invalid MLS context s0:s0:c0
Which seems to confirm what the Tresys Wiki page GettingStartedhttp://oss.tresys.com/projects/refpolicy/wiki/GettingStartedsays:
Since the MCS policy has only one sensitivity (s0), this is automatically added by the gen_context() macro, and should not be added by the user.
Any other suggestions for how to get these files labeled with a category automatically?
If you leave the files with no categories s0, then they should be able
to read/write them.
Yeah, true, but I'm not sure how to cause them to have no category either, apart from using setxattr.
Moving to categories provides isolation between the scripts, the goal would be for the scripts to not be able to attack each other, but allowing them to write to the same files potentially gives them a mechanism to attack each other.
Definitely true, but the communication is necessary in this case, and the files are easier to understand and control than the process data. I think it's a good tradeoff for my application.
Thanks!
------Scott.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 02/21/2011 10:19 PM, Scott Gifford wrote:
On Mon, Feb 21, 2011 at 2:22 PM, Daniel J Walsh <dwalsh@redhat.com mailto:dwalsh@redhat.com> wrote:
On 02/21/2011 12:37 PM, Scott Gifford wrote: > Yes, I am creating categories for my Web server child processes based on > their PID to stop them from having access to each other's internal data > in "/proc" (a variation on your earlier suggestion to "grab random MCS > labels to separate the processes"), but the files > in /var/run/portal_auth have session data that all the Web processes > need access to. > > I can keep using setxattr, that seems to work well enough. > > But I guess I'm not clear on when and how the category field to > gen_context in the .fc file is used? >[ ... ]
The syntax should have been: /var/www/portal_auth(/.*)? gen_context(system_u:object_r:httpd_sys_script_rw_t,s0,s0:c0) s0:c0 means Security Level s0 with category c0.When I try that I get this error:
libsepol.mls_from_string: invalid MLS context s0:s0:c0Which seems to confirm what the Tresys Wiki page GettingStarted http://oss.tresys.com/projects/refpolicy/wiki/GettingStarted says:
Ok, I guess you were write, anyways with the c0, that should only setup labeling if for SELinux away applications, It will not set the label automatically. You would still need to do the restorecon -F.
Since the MCS policy has only one sensitivity (s0), this is automatically added by the gen_context() macro, and should not be added by the user.
Any other suggestions for how to get these files labeled with a category automatically?
I am not sure there is a way.
If you leave the files with no categories s0, then they should be able to read/write them.Yeah, true, but I'm not sure how to cause them to have no category either, apart from using setxattr.
I think if you do the file context correctly you can run restorecon -F to fix the label. If your CGI were in Code or python, you could use setfscreatecon, to set the label automatically.
Moving to categories provides isolation between the scripts, the goal would be for the scripts to not be able to attack each other, but allowing them to write to the same files potentially gives them a mechanism to attack each other.Definitely true, but the communication is necessary in this case, and the files are easier to understand and control than the process data. I think it's a good tradeoff for my application.
Thanks!
------Scott.
On Tue, Feb 22, 2011 at 9:00 AM, Daniel J Walsh dwalsh@redhat.com wrote:
On 02/21/2011 10:19 PM, Scott Gifford wrote:
[ ... ]
Yeah, true, but I'm not sure how to cause them to have no category either, apart from using setxattr.
I think if you do the file context correctly you can run restorecon -F to fix the label. If your CGI were in Code or python, you could use setfscreatecon, to set the label automatically.
My code is in Perl, so I just printed the NULL-terminated context name to:
/proc/$$/attr/fscreate
It required that I give the process context setfscreate permission, like this:
allow httpd_ppi_portal_app_t self:process setfscreate;
Now it is working great, thanks!
-----Scott.
On Wed, Feb 23, 2011 at 12:38 AM, Scott Gifford sgifford@suspectclass.comwrote:
On Tue, Feb 22, 2011 at 9:00 AM, Daniel J Walsh dwalsh@redhat.com wrote:
On 02/21/2011 10:19 PM, Scott Gifford wrote:
[ ... ]
Yeah, true, but I'm not sure how to cause them to have no category either, apart from using setxattr.
I think if you do the file context correctly you can run restorecon -F to fix the label. If your CGI were in Code or python, you could use setfscreatecon, to set the label automatically.
My code is in Perl,
Also, are these the python bindings you're talking about above?
http://sourceforge.net/projects/python-selinux/
Those functions would be pretty easy for me to port to perl, if this would be useful to anybody else.
-----Scott.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 02/23/2011 12:44 AM, Scott Gifford wrote:
On Wed, Feb 23, 2011 at 12:38 AM, Scott Gifford <sgifford@suspectclass.com mailto:sgifford@suspectclass.com> wrote:
On Tue, Feb 22, 2011 at 9:00 AM, Daniel J Walsh <dwalsh@redhat.com <mailto:dwalsh@redhat.com>> wrote: On 02/21/2011 10:19 PM, Scott Gifford wrote: [ ... ] > Yeah, true, but I'm not sure how to cause them to have no category > either, apart from using setxattr. > I think if you do the file context correctly you can run restorecon -F to fix the label. If your CGI were in Code or python, you could use setfscreatecon, to set the label automatically. My code is in Perl,Also, are these the python bindings you're talking about above?
http://sourceforge.net/projects/python-selinux/Those functions would be pretty easy for me to port to perl, if this would be useful to anybody else.
-----Scott.
Yes that would be great or just fix up swig in libselinux to generate perl bindings. We currently generate python and ruby bindings.
selinux@lists.fedoraproject.org
-
Daniel J Walsh -
Dominick Grift -
Scott Gifford -
Ted Toth