On 11/14/05, Peter Farrow peter@farrows.org wrote:

/etc/selinux/config

Change this line:

SELINUX=enforcing

to this:

SELINUX=disabled

It always amazes me how quick people are to suggest that you just switch selinux off, without balancing the suggestion with an explanation of what they are losing by doing this. Would you switch a firewall off because it keeps filling your log files up with packet info? An English expression involving babies and bathwater springs to mind ;-)

-- Cheers,

Tony

Thats because its entirely possible to make a system secure without Selinux, it was only born in Centos from Version 4.

While I would never recommend turning off a firewall, I would recommend turning off Selinux: a firewall doesn't stop stuff on the box working properly as it ships, Selinux does.

For example anything that would stop squid running properly out of the box (as Selinux does) is of limited value, in this instance its not required, it gets in the way, it IS easily possible to have a secure system without Selinux, whereas that is doubtful without a firewall. Chalk and cheese springs to mind.

If Selinux is the "baby" in your metaphor, then the best thing to with it is hold it under the water until it stops moving....

For those of us who know how to configure secure systems (and I'm not suggesting you don't Tony by any stretch) Selinux is additionaly bloat I (we) don't really need. It just slows the system down...

I''ve never needed it......

Pete

Tony wrote:

On 11/14/05, *Peter Farrow* <peter@farrows.org mailto:peter@farrows.org> wrote:

/etc/selinux/config

Change this line:

SELINUX=enforcing

to this:

SELINUX=disabled

It always amazes me how quick people are to suggest that you just switch selinux off, without balancing the suggestion with an explanation of what they are losing by doing this. Would you switch a firewall off because it keeps filling your log files up with packet info? An English expression involving babies and bathwater springs to mind ;-)

-- Cheers,

Tony

---

---

CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos

On Mon, 2005-11-14 at 11:18 +0000, Peter Farrow wrote:

We've been here before by the way

http://lists.centos.org/pipermail/centos/2005-May/006303.html

Peter Farrow wrote:

...

Thats because its entirely possible to make a system secure without Selinux, it was only born in Centos from Version 4.

While I would never recommend turning off a firewall, I would recommend turning off Selinux: a firewall doesn't stop stuff on the box working properly as it ships, Selinux does.

For example anything that would stop squid running properly out of the box (as Selinux does) is of limited value, in this instance its not required, it gets in the way, it IS easily possible to have a secure system without Selinux, whereas that is doubtful without a firewall. Chalk and cheese springs to mind.

If Selinux is the "baby" in your metaphor, then the best thing to with it is hold it under the water until it stops moving....

For those of us who know how to configure secure systems (and I'm not suggesting you don't Tony by any stretch) Selinux is additionaly bloat I (we) don't really need. It just slows the system down...

I''ve never needed it......

---- and it appears still that your confidence that you can secure systems without it gets in the way of any efforts to learn how it may benefit you.

Thanks for the chatter...I know how to turn it off. I am trying to learn to live with the beast.

Craig

Peter Farrow peter@farrows.org wrote:

Thats because its entirely possible to make a system secure without Selinux, it was only born in Centos from Version 4.

There is _no_ possible way to make a system secure _except_ for yanking the plug. Furthermore, anytime you offer networking services, you open up holes in the system.

While I would never recommend turning off a firewall,

This is far too broad of a statement.

First off, "firewalls" can actually not only be a _false_ sense of security, but they are quite _indifferent_ at times. Most people assume firewalls must be turned on because many platforms have so many services that _always_ run, _regardless_ of configuration. That is a leftover from the Windows world.

A UNIX/Linux system with select networking services that are known to be running and accepting all packets from any source IP benefit virtually _little_ from source address packet inspection (let alone TCP Wrappers becomes useless). At that point, you're talking more about intrusion detection than anything. And that's typically at layer 5+. The new focus is on IDS/IPS at layer 7 in today's world of unifying HTTP services.

The overwhelming majority of firewalls only address layer-3/4 security, layer-2 if you're lucky, but virtually _never_ layer 5+.

I would recommend turning off Selinux:

I would recommend _against_ that.

That's _exactly_ saying that you don't need different user logins if you have groups defined, because you've entrusted people in a group of the same access. You're ignoring many, many things accountability-wise.

a firewall doesn't stop stuff on the box working properly

Of course not because it only deals with (largely) blocking layer-3/4 communcation. It does absolutely nothing to deal with layer-5+ exploits -- let alone local issues.

as it ships, Selinux does.

Of course! Anytime you implement RBAC/MAC, you're going to break things. But the answer is _not_ to merely turn it off, it's to write the software to work with RBAC/MAC.

Like it or not, Linux software is going to have to "grow up" and face the RBAC/MAC music. In addition to software, that requires administrators learning to deal with it.

To do less is to leave Linux _well_behind_ other OSes in the Common Criteria certifications -- certifications that _do_ exist for damn good reasons.

For example anything that would stop squid running properly out of the box (as Selinux does) is of limited value,

Value to whom? The person who is trying to secure the server? Or someone who just wants Squid to work?

REALITY:

SELinux is no different than any other security mechanism, or any other troubleshooting. If something doesn't work, you turn off all sorts of constraints. If it starts working suddenly because you turned something off, that doesn't necessarily mean whatever you turned off is the "problem," but that its current configuration prevents something from working.

You can either choose to find out why, or you can turn it off. But make no mistake, SELinux is _not_ just "going away" because people don't want to deal with it. Just like NPTL, just like ANSI C++ compliance before that and just like GLibC 2 before that. I have continually agreed with Red Hat's insistence on certain technologies because without them, Linux is seriously _not_ moving forward.

Heck, look at Windows! 99.9% of Windows applications won't run with the full NT security model enabled. In the Linux world, you start enforcing the full security of the OS, and the applications fall in-line. SELinux is just another set of hurdles to overcome in Linux -- things that _other_ UNIX flavors _have_.

Linux needs to join them or people like myself _will_ be running Solaris on our next server purchase (there is already the filesystem argument I've blabbed about prior, with RBAC/MAC being an increasing consideration. ;-)

in this instance its not required,

"Not required" in what context? That's the problem.

it gets in the way, it IS easily possible to have a secure system without Selinux, whereas that is doubtful without a firewall.

I _disagree_ entirely, and that is an overly broad statement. One might argue that a layer-3/4 packet inspector is rather "false security" when it comes to a layer-7 proxy service. ;->

Now SELinux is not a layer-7 packet inspector. But it _does_ prevent applications from accessing parts of the system that should not be allowed to access. It's not perfect and God knows Red Hat begs for new rules everyday to deal with things, but the headaches don't stop _until_ people start getting serious about putting SELinux in the fore-front of their considerations.

Chalk and cheese springs to mind. If Selinux is the "baby" in your metaphor, then the best thing to with it is hold it under the water until it stops moving....

No offense, but Solaris continues to gain back Linux mindshare for this, and other reasons. No, it's not GPL-like, but it's MPL-like. If SELinux isn't adopted, Red Hat _knows_ it's going to be a serious mark against Solaris.

For those of us who know how to configure secure systems (and I'm not suggesting you don't Tony by any stretch) Selinux is additionaly bloat I (we) don't really need.

Fine for you'all. But I do want and need SELinux.

Yes, I disable it on some systems. But at other times, I've caught a few things that should not access things.

It just slows the system down... I''ve never needed it......

But lack of SELinux adoption will slow Linux down. Red Hat knows this.

Peter Farrow peter@farrows.org wrote:

Additionally, if loads of people say "turn it off" doesn't that tell you something about it.... the writing is on the wall ;-)

Just like "deny all _outgoing_" firewalls? I mean, they do the same thing, get rid of having to deal with outgoing Internet incompatibilities.

Result? Oh I don't know, how about stuff like the Half-Life 2 code on the Internet?

Locking down just _outgoing_ layer-3/4 access is difficult enough that many companies don't do that either. And that's just layer-3/4, we're not talking application-level!

And that's just -- to use your example -- a "firewall." Saying "firewall" is like saying "3D accelerator."

SELinux is just another filter, done at the OS to prevent application access to where it should not -- _or_ require applications to be properly setup for select access.

It's a PITA, but when you need it, it's worth it. If you don't, turn it off, by all means!

The only writing on the wall is that companies Sun is actually making other UNIX flavors, such as Solaris, attractive versus Linux again. God knows many of us left Solaris for Linux years ago, yet Solaris 10 is making many of us rethink that move.

If people like yourself get your way, I'll have no choice.

"Giovanni P. Tirloni" gpt@tirloni.org wrote:

I'm all for SELinux.. just not it's deployment without planning. That's why I've inclued a URL to the unofficial SELinux FAQ, so he could disable it but read about what it was later.

Two most _excellent_ statements on SELinux. Apparently other people think you have to be for/against SELinux. The reality is that if you don't know what to do with SELinux, by all means, disable it.

The only "writing on the wall" is the reality that many Linux professionals keep laughing at Sun. I'm not laughing. I used to be. I'm not anymore.

One might argue that while Ghandi was right, I'm sure he didn't have a bias in that thought. ;->

Peter Farrow peter@farrows.org wrote:

We've been here before by the way

http://lists.centos.org/pipermail/centos/2005-May/006303.html

And I noted you also griped about ACLs in a filesystem where the filesystem dump doesn't know how to handle them. Now if we could get Red Hat behind XFS like it is SELinux, then we _might_ have a chance.

Otherwise, did I mention Solaris? ;->

[ Please don't bash me for mentioning Solaris. I'm just saying, if we don't get serious about such things, Solaris _will_ capture a signficant number of Linux systems back. ]

On Mon, 2005-11-14 at 05:04, Tony wrote:

It always amazes me how quick people are to suggest that you just switch selinux off, without balancing the suggestion with an explanation of what they are losing by doing this.

What you get without it is the well-understood unix permission system that served everyone well for several decades. Exploits involving buggy code have happened, but If we've learned anything along the way it is that adding new and less-tested code to a working system doesn't necessarily make it more secure.

Would you switch a firewall off because it keeps filling your log files up with packet info? An English expression involving babies and bathwater springs to mind ;-)

I'd need some reason to think that the firewall code was less likely to be exploited than the rest of the system it is supposed to be protecting to consider it important.

Furthermore, why people believe adding complexity to a system "makes it more secure" baffles me,

We enter into the realms of "security by obscurity", and Bill Gates' "bloat and crash ware" epitomises that....

Peter Farrow wrote:

I agree Les,

Selinux just adds bloat that we've managed without for many many years.

Another layer of complexity to allow another layer of holes/backdoors/exploits.

NOT NEEDED!!!!

Regards

Pete

Les Mikesell wrote:

...

On Mon, 2005-11-14 at 05:04, Tony wrote:

...

It always amazes me how quick people are to suggest that you just switch selinux off, without balancing the suggestion with an explanation of what they are losing by doing this.

What you get without it is the well-understood unix permission system that served everyone well for several decades. Exploits involving buggy code have happened, but If we've learned anything along the way it is that adding new and less-tested code to a working system doesn't necessarily make it more secure.

...

Would you switch a firewall off because it keeps filling your log files up with packet info? An English expression involving babies and bathwater springs to mind ;-)

I'd need some reason to think that the firewall code was less likely to be exploited than the rest of the system it is supposed to be protecting to consider it important.

---

CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos

SELinux is actually obscure because I've not yet studied it (like most of us I think) that's why I'm disabling it for now. But it will be a necessary move just because it's a major evolution (as exploits are evolving equally). It's bringing new concepts and it may become as usual as the Unix rights are. I've played a little with GRsecurity kernel patch and found it as a good security enhancement for boxes who needed it and I'm happy to see that something "more standard" is coming as it should remove some complexity in the implementation process.

Peter Farrow wrote:

Furthermore, why people believe adding complexity to a system "makes it more secure" baffles me,

We enter into the realms of "security by obscurity", and Bill Gates' "bloat and crash ware" epitomises that....

Peter Farrow wrote:

...

I agree Les,

Selinux just adds bloat that we've managed without for many many years.

Another layer of complexity to allow another layer of holes/backdoors/exploits.

NOT NEEDED!!!!

Regards

Pete

Les Mikesell wrote:

...

On Mon, 2005-11-14 at 05:04, Tony wrote:

...

It always amazes me how quick people are to suggest that you just switch selinux off, without balancing the suggestion with an explanation of what they are losing by doing this.

What you get without it is the well-understood unix permission system that served everyone well for several decades. Exploits involving buggy code have happened, but If we've learned anything along the way it is that adding new and less-tested code to a working system doesn't necessarily make it more secure.

...

Would you switch a firewall off because it keeps filling your log files up with packet info? An English expression involving babies and bathwater springs to mind ;-)

I'd need some reason to think that the firewall code was less likely to be exploited than the rest of the system it is supposed to be protecting to consider it important.

---

CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos

---

CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos

On Mon, 2005-11-14 at 08:29, Jim Perrin wrote:

...

Selinux just adds bloat that we've managed without for many many years.

We used to manage just fine with telnet for many many years also, and these days I wouldn't think of running accessing a machine via telnet. If you don't change with the times, you're going to get steamrolled by them.

But note that there have been times that having ssh enabled exposed your system to additional exploits.

Another layer of complexity to allow another layer of

...

holes/backdoors/exploits.

Given the organization who gave us selinux and their dire need for security, I get the feeling it'll block many more problems that it allows, just as ssh did.

Except for the versions of ssh that allowed exploits...

Les Mikesell lesmikesell@gmail.com wrote:

Except for the versions of ssh that allowed exploits...

_All_ versions of SSH allow for exploits in a variety of ways.

Ironically, the best way to kill them has worked for years now, through numerous exploits! But sysadmins won't adopt it.

And that's to require public key authentication.

On Mon, 2005-11-14 at 08:29 -0200, Giovanni P. Tirloni wrote:

Craig White wrote:

...

I am getting tons of these messages since I updated to 4.2

Nov 12 12:21:39 srv1 dbus: Can't send to audit system: USER_AVC pid=2839 uid=81 loginuid=-1 message=avc: denied { send_msg } for scontext=user_u:system_r:unconfined_t tcontext=user_u:system_r:initrc_t tclass=dbus

Now I can see this process...

# ps aux|grep 2839 dbus 2839 0.0 0.3 16168 1888 ? Ssl Nov11 0:13 dbus- daemon-1 --system root 17173 0.0 0.1 3748 668 pts/2 S+ 12:22 0:00 grep 2839

but I'm wondering how do I fix selinux so that it doesn't 'deny' this?

Thanks

Craig

RHEL update 2 has introduced some changes in the audit system. Please read the release notes (kernel changes) and it'll tell you how to disable that.

http://www.redhat.com/docs/manuals/enterprise/RHEL-4-Manual/release- \ notes/as-amd64/RELEASE-NOTES-U2-x86_64-en.html

http://www.crypt.gen.nz/selinux/faq.html

---- I have read through the SELinux manual several times and I am not that smart.

I did do a relabel of the system but that didn't fix it.

I tried... # cat /etc/selinux/targeted/contexts/users/root system_r:unconfined_t system_r:unconfined_t

# cat /etc/selinux/targeted/contexts/users/dbus system_r:unconfined_t system_r:unconfined_t

(copying the file for root and making a file for the user dbus)

Since this is my home system - the one I use to learn stuff on, this isn't a huge problem like if it were a clients system but that's why I do this...to learn.

I didn't mean to spark off a useless debate about the value of SELinux because at this stage, most of everything has already been said and I want to learn it, not debate it.

I don't know if this stems from my compiling my own appletalk and megaraid modules or some other stupid thing that I have done and thus somehow wasn't covered in the upgrade from 4.1 to 4.2 or if everyone who upgraded from 4.1 to 4.2 sees these messages in their logs.

Anyway, thanks for the response...I joined the fedora-selinux mail list to see if I can get some help there as this crew seems to want to debate rather than learn.

Craig

On Mon, 2005-11-14 at 17:46 -0500, William L. Maltby wrote:

On Mon, 2005-11-14 at 08:37 -0700, Craig White wrote:

...

On Mon, 2005-11-14 at 08:29 -0200, Giovanni P. Tirloni wrote:

...

Craig White wrote:

...

<snip>

...

I don't know if this stems from my compiling my own appletalk and megaraid modules or some other stupid thing that I have done and thus somehow wasn't covered in the upgrade from 4.1 to 4.2 or if everyone who upgraded from 4.1 to 4.2 sees these messages in their logs.

I also received these new messages in the message log. Did what Peter Farrow suggested and the messages stopped after reboot.

From rom my quick scanning of the docs we were pointed to, I saw no *obvious* solution jump out at me. I'm begging to suspect that there is a user or domain addition needed to prevent the messages.

But that's only suspicion until I do more research, if I do.

---- No - are you having the problem? do you want the solution?

Craig

On Mon, 2005-11-14 at 18:09 -0500, William L. Maltby wrote:

On Mon, 2005-11-14 at 16:01 -0700, Craig White wrote:

...

On Mon, 2005-11-14 at 17:46 -0500, William L. Maltby wrote:

...

On Mon, 2005-11-14 at 08:37 -0700, Craig White wrote:

...

On Mon, 2005-11-14 at 08:29 -0200, Giovanni P. Tirloni wrote:

...

Craig White wrote:

...

<snip>

...

I don't know if this stems from my compiling my own appletalk and megaraid modules or some other stupid thing that I have done and thus somehow wasn't covered in the upgrade from 4.1 to 4.2 or if everyone who upgraded from 4.1 to 4.2 sees these messages in their logs.

I also received these new messages in the message log. Did what Peter Farrow suggested and the messages stopped after reboot.

From rom my quick scanning of the docs we were pointed to, I saw no *obvious* solution jump out at me. I'm begging to suspect that there is a user or domain addition needed to prevent the messages.

But that's only suspicion until I do more research, if I do.

---

No - are you having the problem? do you want the solution?

Craig

I was hoping that you might p[ost or offer it. Yes, I would enjoy that. I'm a big believer in .... >:-) Philosophy almost started.

Please post the solution. I was having the same messages you complained about. Peter's solution suppressed the messages, but I planned on "doing the right thing" at some point when I could read, understand, ...

TIA

BTW: Don't be too hard on folks about the philosophy things, al;though it is an inconvenience for the more pragmatic among us. I have never seen a good tech list that doesn't have them.

---- I was a bit ticked off about it actually. I asked a simple question about the messages I was getting and find 30 messages debating the value of selinux on my thread and one response to tell me to look at the documentation that I had read through a million times and understood very little.

It probably wouldn't have been so bad if the topic hadn't been debated monthly and the same people saying the same things and thus no enlightenment.

Anyway...the solution...(Note - I also included my solution to MySQL) for the record...

# cat /etc/selinux/config # This file controls the state of SELinux on the system. # SELINUX= can take one of these three values: # enforcing - SELinux security policy is enforced. # permissive - SELinux prints warnings instead of enforcing. # disabled - SELinux is fully disabled. SELINUX=Enforcing # SELINUXTYPE= type of policy in use. Possible values are: # targeted - Only targeted network daemons are protected. # strict - Full SELinux protection. SELINUXTYPE=targeted

# yum install selinux-targeted-policy-sources

# cat /etc/selinux/targeted/src/policy/domains/local.te ## http to mysql allow httpd_t initrc_t:unix_stream_socket connectto;

## dbus allow unconfined_t initrc_t:dbus send_msg;

# cd /etc/selinux/targeted/src/policy # make reload

Now all of those arrogant people who want to just shut off SELinux because they either: a. Feel they can secure their systems without it b. Don't understand enough of it to justify using it c. Can't be bothered

Please don't advise people to just shut it off. Tell them to set SELinux to 'permissive'

You may all resume your debate now... ;-)

Trust me it won't solve anything.

Craig

Craig White wrote:

The apparent lack of people bitching about this on nahant list or centos list makes me think that a large amount of RHEL 4 (or clone) users have simply turned SELinux off. I guess that puzzles me as much as anything.

What's with the bug up your nether regions? People turn it off because they feel they don't need it. For many people it is simply a broken distraction. It should be turned off by default, but it isn't. Are you also going to lecture people for turning off other software packages that come bundled "on" by default? Why does this bother you so much?

Cheers,

On Mon, 2005-11-14 at 19:38 -0700, Craig White wrote:

I'm not sure why you would interpret my expressing puzzlement as meaning that it's a bug up my nether regions. Do you take all statements to their extreme extension? In any event, when users use the stuff, report back their issues things get fixed, things improve, it's the pattern of open source. Of course are free to opt out by turning it off. I don't want to tell a client that their system was compromised and that one of the security mechanisms delivered with the system was shut off because I didn't understand it.

Craig, meet the usual suspects. If you cross their absolutist views on something, expect to be so engaged -- especially if you have any views that are even remotely associated with mine (which can be far worse at times, I fully admit ;-).

Whomever originally suggested that a UT2004/Quake4 fragfest was a far better battlefield for this than the CentOS was dead-on! Until then, seek the appropriate enlightenment on the respective Fedora list when it comes to Red Hat defaults on specific technologies:

http://www.redhat.com/mailman/listinfo/

My A64/7800GTX system is still waiting for a challenge! I normally don't have time to game, but I'm always game for a CentOS absolutist!

On Mon, 2005-11-14 at 22:07 -0500, Chris Mauritz wrote:

Craig White wrote:

Is there a particular feature of SELinux that this client needs to use? Or will SELinux simply be turned on because it's there? If you don't explicitly need functionality provided by SELinux, perhaps it might be more prudent to exclude it...especially since you say you don't understand it. And that's not a jibe at you. It's by no means an easy subject.

---- In the above, you are telling me what I should do and the previous paragraphs which I clipped out, you suggested that I was doing the same to you which I didn't.

- I don't want to debate the value of SELinux with you or anyone else.

- You can choose to use it or turn it off as you please.

Knowledge often comes in bits and pieces. I don't thoroughly understand openldap, netfilter, cyrus-imapd, apache configuration and probably a great many other things but I use them anyway. I learn as I go. I fix problems that my knowledge allows and seek help where I can't readily figure it out from available information.

No matter how many times you repeat your philosophy, you still contribute nothing to furthering security, understanding or usage of the avaialble tools. When I am confronted with that set of circumstances, I generally stay quiet.

Craig

On Mon, 2005-14-11 at 18:49 -0700, Craig White wrote:

The apparent lack of people bitching about this on nahant list or centos list makes me think that a large amount of RHEL 4 (or clone) users have simply turned SELinux off. I guess that puzzles me as much as anything.

I have first hand experience with this. I did some sub-contract work for a client. Their client was having a horrible time with a custom app and SElinux, and was overall very unhappy with RHEL 4. So, here's what they did: they blew away the server and installed RH9.

*smacks forehead*

Many other clients of my own customer have simply disabled SElinux. It is definitely being turned off left, right and centre.

Regards,

Ranbir