When does echo 0 > /selinux/inforce need to be used? I.e., where is selinux enforcing itself on the system to protect it? When I do yum install of some package, it seems to work (not being blocked). When would doing something not work because selinux is watching it (or whatever that process is doing)?
Thanks,
-wes
Wes James wrote:
When does echo 0 > /selinux/inforce need to be used? I.e., where is selinux enforcing itself on the system to protect it? When I do yum install of some package, it seems to work (not being blocked). When would doing something not work because selinux is watching it (or whatever that process is doing)?
It changes selinux mode from enforcing to permissive, which means it still complains, but lets the processes run anyway.
mark
On 11/5/2013 2:15 PM, m.roth@5-cent.us wrote:
Wes James wrote:
When does echo 0 > /selinux/inforce need to be used? I.e., where is selinux enforcing itself on the system to protect it? When I do yum install of some package, it seems to work (not being blocked). When would doing something not work because selinux is watching it (or whatever that process is doing)?
It changes selinux mode from enforcing to permissive, which means it still complains, but lets the processes run anyway.
the most common scenario for selinux problems is when you change default locations for something, for instance, putting a postgresql database cluster on a different path than /var/lib/postgresql/x.y/data, or have users with home directories other than /home/$USER
if you do something like this and get weird errors, you can set selinux to permissive, and see your thing works. if so, analyze the selinux error logs to see what corrective action you need (typically, relabeling the unusual location for whatever it is).
On Tue, Nov 5, 2013 at 3:28 PM, John R Pierce pierce@hogranch.com wrote:
On 11/5/2013 2:15 PM, m.roth@5-cent.us wrote:
Wes James wrote:
When does echo 0 > /selinux/inforce need to be used? I.e., where is selinux enforcing itself on the system to protect it? When I do yum install of some package, it seems to work (not being blocked). When
would
doing something not work because selinux is watching it (or whatever
that
process is doing)?
It changes selinux mode from enforcing to permissive, which means it
still
complains, but lets the processes run anyway.
the most common scenario for selinux problems is when you change default locations for something, for instance, putting a postgresql database cluster on a different path than /var/lib/postgresql/x.y/data, or have users with home directories other than /home/$USER
if you do something like this and get weird errors, you can set selinux to permissive, and see your thing works. if so, analyze the selinux error logs to see what corrective action you need (typically, relabeling the unusual location for whatever it is).
OK. Thanks.
-wes
John R Pierce wrote:
On 11/5/2013 2:15 PM, m.roth@5-cent.us wrote:
Wes James wrote:
When does echo 0 > /selinux/inforce need to be used? I.e., where is selinux enforcing itself on the system to protect it? When I do yum install of some package, it seems to work (not being blocked). When
would doing something not work because selinux is watching it (or
whatever
that process is doing)?
It changes selinux mode from enforcing to permissive, which means it still complains, but lets the processes run anyway.
the most common scenario for selinux problems is when you change default locations for something, for instance, putting a postgresql database cluster on a different path than /var/lib/postgresql/x.y/data, or have users with home directories other than /home/$USER
if you do something like this and get weird errors, you can set selinux to permissive, and see your thing works. if so, analyze the selinux error logs to see what corrective action you need (typically, relabeling the unusual location for whatever it is).
Or you might need to create special local policies for software in non-standard (but standard for your work environment) locations, or for local or third party software that was written in total ignorance or disregard of selinux (such as from CA, or Matlab...), or, in some cases, just leave it in permissive mode.
mark "NOT a fan of selinux, dealt with it far too much"
On Tue, Nov 5, 2013 at 3:38 PM, m.roth@5-cent.us wrote:
John R Pierce wrote:
On 11/5/2013 2:15 PM, m.roth@5-cent.us wrote:
Wes James wrote:
When does echo 0 > /selinux/inforce need to be used? I.e., where is selinux enforcing itself on the system to protect it? When I do yum install of some package, it seems to work (not being blocked). When
would doing something not work because selinux is watching it (or
whatever
that process is doing)?
It changes selinux mode from enforcing to permissive, which means it still complains, but lets the processes run anyway.
the most common scenario for selinux problems is when you change default locations for something, for instance, putting a postgresql database cluster on a different path than /var/lib/postgresql/x.y/data, or have users with home directories other than /home/$USER
if you do something like this and get weird errors, you can set selinux to permissive, and see your thing works. if so, analyze the selinux error logs to see what corrective action you need (typically, relabeling the unusual location for whatever it is).
Or you might need to create special local policies for software in non-standard (but standard for your work environment) locations, or for local or third party software that was written in total ignorance or disregard of selinux (such as from CA, or Matlab...), or, in some cases, just leave it in permissive mode.
mark "NOT a fan of selinux, dealt with it far too much"
OK. Why not use some other linux that doesn't use selinux then? I guess in permissive mode, you could still monitor the logs and take action, if needed.
-wes
Wes James wrote:
On Tue, Nov 5, 2013 at 3:38 PM, m.roth@5-cent.us wrote:
John R Pierce wrote:
On 11/5/2013 2:15 PM, m.roth@5-cent.us wrote:
Wes James wrote:
When does echo 0 > /selinux/inforce need to be used? I.e., where
is selinux enforcing itself on the system to protect it? When I do yum install of some package, it seems to work (not being blocked). When would doing something not work because selinux is watching it (or whatever that process is doing)?
It changes selinux mode from enforcing to permissive, which means it still complains, but lets the processes run anyway.
the most common scenario for selinux problems is when you change default locations for something, for instance, putting a postgresql
database
cluster on a different path than /var/lib/postgresql/x.y/data, or have users with home directories other than /home/$USER
if you do something like this and get weird errors, you can set selinux to permissive, and see your thing works. if so, analyze the
selinux
error logs to see what corrective action you need (typically, relabeling the unusual location for whatever it is).
Or you might need to create special local policies for software in non-standard (but standard for your work environment) locations, or for local or third party software that was written in total ignorance or disregard of selinux (such as from CA, or Matlab...), or, in some cases, just leave it in permissive mode.
mark "NOT a fan of selinux, dealt with it far too much"OK. Why not use some other linux that doesn't use selinux then? I guess in permissive mode, you could still monitor the logs and take action, if needed.
1. The most widely used distro of Linux in the US is RHEL ("upstream") and RHEL-derived distros, like CentOS. RHEL gives you selinux. 2. You really expect any organization, much less a large one, to change distros just because there's issues that annoy sysadmins, and only occasionally users (due to sysadmins fighting the good fight, and mostly beating the damn thing)? 3. I really, *REALLY* like a *stable* distro (don't get me started on fedora). None of us wants to debug the o/s....
Yeah, I'm the one who does most of the shut selinux up around here....
mark
On Tue, Nov 5, 2013 at 3:53 PM, m.roth@5-cent.us wrote:
Wes James wrote:
On Tue, Nov 5, 2013 at 3:38 PM, m.roth@5-cent.us wrote:
<snip>
mark "NOT a fan of selinux, dealt with it far too much"OK. Why not use some other linux that doesn't use selinux then? I guess in permissive mode, you could still monitor the logs and take action, if needed.
- The most widely used distro of Linux in the US is RHEL ("upstream") and
RHEL-derived distros, like CentOS. RHEL gives you selinux. 2. You really expect any organization, much less a large one, to change distros just because there's issues that annoy sysadmins, and only occasionally users (due to sysadmins fighting the good fight, and mostly beating the damn thing)? 3. I really, *REALLY* like a *stable* distro (don't get me started on fedora). None of us wants to debug the o/s....
Yeah, I'm the one who does most of the shut selinux up around here....
mark
Ok. Thanks for the info.
-wes
On 2013-11-05, Wes James comptekki@gmail.com wrote:
Why not use some other linux that doesn't use selinux then?
If it were harder to disable (either temporarily or permanently) then I could see someone making this case. But it's trivial to disable SELinux in CentOS, so there's no real reason to use a different distro just because it doesn't use SELinux.
--keith
On Tue, Nov 5, 2013 at 4:01 PM, Keith Keller < kkeller@wombat.san-francisco.ca.us> wrote:
On 2013-11-05, Wes James comptekki@gmail.com wrote:
Why not use some other linux that doesn't use selinux then?
If it were harder to disable (either temporarily or permanently) then I could see someone making this case. But it's trivial to disable SELinux in CentOS, so there's no real reason to use a different distro just because it doesn't use SELinux.
--keith
Your right. I did a google search on "disable selinux" and got this on the first hit:
http://www.crypt.gen.nz/selinux/disable_selinux.html
Seems pretty straight forward.
Thanks,
-wes
On 11/05/2013 06:13 PM, Wes James wrote:
On Tue, Nov 5, 2013 at 4:01 PM, Keith Keller < kkeller@wombat.san-francisco.ca.us> wrote:
On 2013-11-05, Wes James comptekki@gmail.com wrote:
Why not use some other linux that doesn't use selinux then?
If it were harder to disable (either temporarily or permanently) then I could see someone making this case. But it's trivial to disable SELinux in CentOS, so there's no real reason to use a different distro just because it doesn't use SELinux.
--keith
Your right. I did a google search on "disable selinux" and got this on the first hit:
http://www.crypt.gen.nz/selinux/disable_selinux.html
Seems pretty straight forward.
Thanks,
-wes
http://stopdisablingselinux.com/ ;)
On Tue, Nov 5, 2013 at 11:35 PM, Phil Gardner phil.gardnerjr@gmail.comwrote:
On 11/05/2013 06:13 PM, Wes James wrote:
On Tue, Nov 5, 2013 at 4:01 PM, Keith Keller < kkeller@wombat.san-francisco.ca.us> wrote:
On 2013-11-05, Wes James comptekki@gmail.com wrote:
Why not use some other linux that doesn't use selinux then?
If it were harder to disable (either temporarily or permanently) then I could see someone making this case. But it's trivial to disable SELinux in CentOS, so there's no real reason to use a different distro just because it doesn't use SELinux.
--keith
Your right. I did a google search on "disable selinux" and got this on
the
first hit:
http://www.crypt.gen.nz/selinux/disable_selinux.html
Seems pretty straight forward.
Thanks,
-wes
LOL :)
Thanks,
-wes
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 11/05/2013 05:13 PM, Wes James wrote:
First you should use setenforce 0/setenforce 1.
Theoretically never. It should really be discouraged. It is like the Enterprise bringing it "Shields" down.
SELinux in permissive mode will continue to do access checks but just logs them but does not block access.
SELinux blocks "confined" processes, but usually does not block the administrator who is running as unconfined_t, and is allowed to do everything he could do if SELinux was disabled.
Confined processes are targeted to system services. Stuff that is started at boot versus processes started by a logged in user.
I blog on the topic alot at danwalsh.livejournal.com
BTW, When do I need to setenforce 0?
SELinux is a labeling system, if your labels get screwed up, you might need to setenforce 0 to get the system to run. Commands like restorecon/fixfiles can be used to restore the labels on your system to the default.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 11/05/2013 05:13 PM, Wes James wrote:
When does echo 0 > /selinux/inforce need to be used? I.e., where is selinux enforcing itself on the system to protect it? When I do yum install of some package, it seems to work (not being blocked). When would doing something not work because selinux is watching it (or whatever that process is doing)?
Thanks,
-wes _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
First you should use setenforce 0/setenforce 1.
Theoretically never. It should really be discouraged. It is like the Enterprise bringing it "Shields" down.
SELinux in permissive mode will continue to do access checks but just logs them but does not block access.
SELinux blocks "confined" processes, but usually does not block the administrator who is running as unconfined_t, and is allowed to do everything he could do if SELinux was disabled.
Confined processes are targeted to system services. Stuff that is started at boot versus processes started by a logged in user.
I blog on the topic alot at danwalsh.livejournal.com
BTW, When do I need to setenforce 0?
SELinux is a labeling system, if your labels get screwed up, you might need to setenforce 0 to get the system to run. Commands like restorecon/fixfiles can be used to restore the labels on your system to the default.
On Wed, Nov 6, 2013 at 9:23 AM, Daniel J Walsh dwalsh@redhat.com wrote:
SELinux blocks "confined" processes, but usually does not block the administrator who is running as unconfined_t, and is allowed to do everything he could do if SELinux was disabled.
Confined processes are targeted to system services. Stuff that is started at boot versus processes started by a logged in user.
Is there a way to configure things so tomcat or other java web containers can unpack the war files used for code deployment and compile/cache jsp code on the fly but not be able to write anything else (like from the several instances of struts vulnerabilities)?
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 11/06/2013 11:55 AM, Les Mikesell wrote:
On Wed, Nov 6, 2013 at 9:23 AM, Daniel J Walsh dwalsh@redhat.com wrote:
SELinux blocks "confined" processes, but usually does not block the administrator who is running as unconfined_t, and is allowed to do everything he could do if SELinux was disabled.
Confined processes are targeted to system services. Stuff that is started at boot versus processes started by a logged in user.
Is there a way to configure things so tomcat or other java web containers can unpack the war files used for code deployment and compile/cache jsp code on the fly but not be able to write anything else (like from the several instances of struts vulnerabilities)?
We can control the directory that an application can write to and directories that they can execute. We can do this at the process level.
Not sure if we can do what you describe.
On Wed, Nov 6, 2013 at 11:01 AM, Daniel J Walsh dwalsh@redhat.com wrote:
SELinux blocks "confined" processes, but usually does not block the administrator who is running as unconfined_t, and is allowed to do everything he could do if SELinux was disabled.
Confined processes are targeted to system services. Stuff that is started at boot versus processes started by a logged in user.
Is there a way to configure things so tomcat or other java web containers can unpack the war files used for code deployment and compile/cache jsp code on the fly but not be able to write anything else (like from the several instances of struts vulnerabilities)?
We can control the directory that an application can write to and directories that they can execute. We can do this at the process level.
Not sure if we can do what you describe.
The problem is that web developers normally package sites as war files to deploy/update (basically a zip of the configs/jars/jsps, etc.) and the servers unpack them directly into the working locations, then execute them. Also as jsp pages are hit the first time, they are compiled into java byte code and cached for repeated executions. So unless you do some extra work like pre-building things on a host that isn't on line and rsyncing the results over to the live servers, the running process needs to be able to write in the same location where it will execute code. So, things like the vulnerabilities in the struts framework that let you execute more or less arbitrary code would let you add new sites or pages to a server that remain even after a restart.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 11/06/2013 12:55 PM, Les Mikesell wrote:
On Wed, Nov 6, 2013 at 11:01 AM, Daniel J Walsh dwalsh@redhat.com wrote:
SELinux blocks "confined" processes, but usually does not block the administrator who is running as unconfined_t, and is allowed to do everything he could do if SELinux was disabled.
Confined processes are targeted to system services. Stuff that is started at boot versus processes started by a logged in user.
Is there a way to configure things so tomcat or other java web containers can unpack the war files used for code deployment and compile/cache jsp code on the fly but not be able to write anything else (like from the several instances of struts vulnerabilities)?
We can control the directory that an application can write to and directories that they can execute. We can do this at the process level.
Not sure if we can do what you describe.
The problem is that web developers normally package sites as war files to deploy/update (basically a zip of the configs/jars/jsps, etc.) and the servers unpack them directly into the working locations, then execute them. Also as jsp pages are hit the first time, they are compiled into java byte code and cached for repeated executions. So unless you do some extra work like pre-building things on a host that isn't on line and rsyncing the results over to the live servers, the running process needs to be able to write in the same location where it will execute code. So, things like the vulnerabilities in the struts framework that let you execute more or less arbitrary code would let you add new sites or pages to a server that remain even after a restart.
yes that would be a problem. We have similar problems with python, but ship the compiled python inside the rpms.
-
Daniel J Walsh -
John R Pierce -
Keith Keller -
Les Mikesell -
m.roth＠5-cent.us -
Phil Gardner -
Wes James