CentOS - Nov 2010 - SELinux - way of the future or good idea but !!!

Hi,

total newbie on CentOS. Just firing up an install of 5.5 on a development
webserver. Installed Webmin, Awstats, PHPMyAdmin and Drupal successfully. Yet to
work on Sendmail and Samba. SELinux in enforcing mode, reporting "SELinux
preventing ifconfig (ifconfig_t) "read write" to
/var/webminsessiondb.pag (var_t)".

Googled the error message without real success in finding fix - bug reports
showing. Question is whether worth pursuing as SELinux is the way of the future.
Or is SELinux a good idea that never really made it's way into the sun.
Thoughts please.

Alison
PS. Semi-retired. Cut my teeth as sys prog on RSX11-M systems eons ago.

2010/11/27 Alison <penguin at alisoncc.com>:
> Hi,
>
> total newbie on CentOS. Just firing up an install of 5.5 on a development
webserver. Installed Webmin, Awstats, PHPMyAdmin and Drupal successfully. Yet to
work on Sendmail and Samba. SELinux in enforcing mode, reporting "SELinux
preventing ifconfig (ifconfig_t) "read write" to
/var/webminsessiondb.pag (var_t)".
>
> Googled the error message without real success in finding fix - bug reports
showing. Question is whether worth pursuing as SELinux is the way of the future.
Or is SELinux a good idea that never really made it's way into the sun.
Thoughts please.
Just turn selinux off. setenforce "0" works without rebooting server,
but /etc/sysconfig/selinux is correct place to finalize setting..

--
Eero

On Sat, Nov 27, 2010 at 10:58:00AM +1100, Alison wrote:
> Hi,
> 
> total newbie on CentOS. Just firing up an install of 5.5 on a
> development webserver. Installed Webmin, Awstats, PHPMyAdmin and
> Drupal successfully. Yet to work on Sendmail and Samba. SELinux in
> enforcing mode, reporting "SELinux preventing ifconfig (ifconfig_t)
> "read write" to /var/webminsessiondb.pag (var_t)".
	There is a reason that control panels are effectively
	unsupported; you just hit on one of those reasons.  Although I
	must admit I don't fully grasp why webmin is referencing
	ifconfig_t.
> Googled the error message without real success in finding fix - bug
> reports showing. Question is whether worth pursuing as SELinux is the
> way of the future. Or is SELinux a good idea that never really made
> it's way into the sun. Thoughts please.
	There are only a small number of corner cases in which SElinux
	is not appropriate; for all other cases it should be enabled.

	It exists for a reason and is shipped fully enabled for a
	reason.  Being able to limit access based on contexts and roles
	is an incredibly powerful tool which greatly improves the
	security of your server and the integrity of your data.

	Following is a list of very useful SElinux resources.  

	http://wiki.centos.org/HowTos/SELinux
	http://wiki.centos.org/TipsAndTricks/SelinuxBooleans
	http://docs.fedoraproject.org/selinux-user-guide/f10/en-US/
	http://fedorasolved.org/security-solutions/selinux-module-building
	http://centoshelp.org/security/selinux-common-commands-troubleshooting

	Some quality time with these resources will allow you to correct
	the SElinux exception you listed above and also give you a much
	better understanding of SElinux as a whole.




							John
-- 
The best argument against democracy is a five minute conversation
with the average voter.

-- Winston Churchill
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL:
<http://lists.centos.org/pipermail/centos/attachments/20101126/4e2f1118/attachment-0001.sig>

>
> This is where, as a sysadmin, you need to invest just a little time and
> effort learning the system. Honestly, the vast majority of issues are
> trivial to solve if you just spend a few hours reading the docs/guides,
> and even if you really can't be bothered there are kind folks on this
> list (and others) that will likely solve your issues for you. How is
> that not worth the extra security SELinux affords?
>
In reality, I am not at all sure that a quantum leap in complexity
adds to security at all. Any proper use of old-school group
permissions can give as finely-grained a security policy as you would
like.
The time spent running SELinux in permissive mode to configure could
better be spent looking for holes in the operating system, or helping
patch the many bugs that the speedy Linux development schedule lets
through:

http://lwn.net/Articles/409954/

And then we could have real security, and not a false sense of
security generated by heavy-sounding phrases like "mandatory access
controls." :-)

On Sunday, November 28, 2010 10:39:22 am Bob McConnell
wrote:
> Maybe not, but the risks should be evaluated on a case by case basis. I 
> don't believe it can be considered a panacea either. Even with SE in 
> full protected mode, a simple SQL injection flaw can still expose much 
> of the sensitive data on your server.
That's when something like SEPostgreSQL can help.  Yeah, SELinux controls in
the database itself.  See http://wiki.postgresql.org/wiki/SEPostgreSQL for more
information.

If you have sensitive data, you need to be diligent.  The people behind SELinux
are the country's leading experts on information sensitivity and
compartmentalization.

Yeah, that sort of control can be a pain, but if the data is truly sensitive you
simply must take pains with it.

SELinux on the desktop is a great thing, too, especially if you want to thwart
drive-by web bugs and such (you set your controls to not allow Firefox access
but to specific areas of your home directory, and you set certain areas of your
home directory off limits except to certain programs: you're worm-proof
then, and, if you're careful, data-theft-proof).  But that fine-grained
control means you have to maintain those controls, and require due diligence.

It is and has always been a balance between convenience and security; truly
tight security, which SELinux can give you in droves, is a time-consuming and
not very convenient affair.

But if you think you're fully locked down without controls similar to
SELinux, you are simply wrong, and an attacker will prove that to you one day. 
Firewalls are not enough by themselves.  SELinux is likely not enough by itself;
layers do the trick, so that when an exploit in one layer occurs the other layer
catches it (and hopefully you find out about it).

Intrusion detection is good, but, once an intrusion is detected it might be too
late, depending upon the intrusion.  And intrusion 'signatures' (much
like virus signatures) are no good at all against previously undetected threats.
SELinux allows you (especially with permissive mode) to see the access footprint
of an application, and tailor the security to the normal access footprint. 
Allow only what is normal, and it's much harder (not impossible) to exploit
things.

No security is perfect; multiple layers of diverse security on multiple
platforms helps immensely.

On Sunday, November 28, 2010 10:37:29 pm Les Mikesell
wrote:
> But that means you were running software with vulnerabilities or a user
would
> not be able to become root anyway.  Is that due to not being up to date
(i.e.
> would normal, non-SELinux measures have been enough), or was this before a
fix
> was available?
By definition we are all running software with vulnerabilities.  Those
vulnerabilities may not be public knowledge yet, but they are there, and many
are likely known by the blackhats already, and kept 'mum.'

Fixing vulnerabilities and keeping up to date alone is insufficient to keep you
secure.  Can you say 'zero day?'

SELinux is a powerful tool in helping combat zero day exploits from succeeding,
in many cases.

Can it be a pain?  Sure it can.  It has improved greatly, in my experience,
thanks in no small part to the dedicated Fedora team working on selinux
packages.  This inlcudes the upstream developers, the Fedora packagers, the QA
team, and ESPECIALLY the Fedora users who take time to file informative and
useful reports while using the system with SELinux in enforcing mode.  No pain,
no gain.

I've run with SELinux in enforcing (targeted) mode on my laptop, now, since
Fedora 11, and have only had two issues that required some head-scratching.  One
was solved by a relabel.  The other was a little more devious, but a little
tweaking which in permissive mode showed me the solution.  I did learn a couple
of really good lessons from that, though.  The first was to always keep a Fedora
Live boot media with the laptop (CD or USB, or another partition on the hard
disk).  The second was that there are some updates that must occur in pairs, and
occasionally a relabel of at least part of the filesystem is going to be
required. But that's not hard to trigger, and isn't that inconvenient.

On Monday, November 29, 2010 11:29:31 am Les Mikesell
wrote:
> Agreed, but not everyone has time to do both - or to learn lots of 
> distribution-specific details in mixed environments.  My opinion is that 
> doing the simple stuff first is a win.  And that works the same on 
> systems that don't include SELinux.
The simple stuff on the Fedora box with SELinux is using the targeted policy in
enforcing mode.  Updates are easy, but there is always a lag from vulnerability
discovery to vulnerability patching.

Security isn't simple.  The mantra 'just disable SELinux, you don't
need it anyway because it's too big of a pain and apps that aren't part
of the tested distribution can break' is oversimplifying a complex issue. 
My opinion is that I'm not going to run third party apps that break in that
way, and I'm going to let the developers know why.
> > SELinux is a powerful tool in helping combat zero day exploits from
succeeding, in many cases.
> 
> And it also keeps most 3rd party software from working. 
I'd ask you to qualify most.  All of the third-party software I run seems to
run just fine, as long as the right contexts are applied.  The most difficult
was Scalix, but that wasn't too difficult, since the culprit (the embedded
PostgreSQL server running on a nonstandard port with a nonstandard file tree)
had a fairly simple policy change to be done, thanks to permissive mode.
> If you are 
> storing credit card numbers or personal information that would be 
> expensive to leak, then you obviously need to make every effort possible 
> to block intrusion, although the people who regulate this stuff don't 
> require SELinux explicitly.  But not all machines do that.
If I use my laptop to do my online banking, then my browser cache, cookies, and
other browser-stored data become critical.  Client-side data in this case, but
no less critical.
> > I've run with SELinux in enforcing (targeted) mode on my laptop,
now, since Fedora 11, and have only had two issues that required some
head-scratching.
> > 
> How much 3rd party software do you run where someone else has not 
> already spent the time to work out the policies needed to let it work?
A few things, and none were very hard to set up.  On the server side Scalix was
the most difficult, but still not hard.

On Monday, November 29, 2010 12:38:20 pm Les Mikesell
wrote:
> [Most thrid party apps qualify as]
> Pretty much anything that needs to write files outside of the home 
> directory of the owning user.  Certainly anything that uses apache with 
> its own data store.
Which is the prime target for SELinux anyway.  If it runs in-process in apache
you need better protection than the standard UNIX uid:gid.
> > All of the third-party software I run seems to run just fine, as long
as the right contexts are applied.
> 
> Well, obviously it will work after someone takes the time to make it 
> work.  
Exactly.  Proper information security is becoming more and more critical;
educating the executive suite on the need for good information security is a big
part; they're obviously going to want justification for the time spent.

If a particular app is so recalcitrant that SELinux needs to be turned off,
that's when I'd be doing some drastic things, much like windows lab
environments need done.  Things like automatic revert to known-good snapshot on
the production boxes for all but the data files.  Things like isolation in a VM
for those apps.  Of course, that's also work, and getting SELinux working
properly might be less work.  Everyone wants less work per project to get more
projects done, of course, but cutting corners is still cutting corners and one
day it will come back to haunt the corner-cutter.
> Now it is your turn to quantify:  How much would you charge to 
> teach someone to be able to make those changes and how long would it 
> take?  This has to include the ability to quickly diagnose and fix any 
> problem that might be caused by updates to the application or to the OS 
> distribution.
To teach, $50 per hour (if I were available to teach; at the moment I'm full
on my work hours).  The number of hours would depend upon the complexity of the
application; for Scalix, assuming no familiarity with either Scalix or SELinux,
eight to sixteen hours (one-two days).  Basic stuff wouldn't take more than
five to ten hours at most; but I've not done a full workup of an
'SELinux' course, either, and I bet Red Hat has; might even be something
they offer, I don't know.  Their instructors would likely do a much better
job than I, since they teach it more often and probably more rigorous, as I
don't really consider myself an expert in SELinux itself; I know enough to
get my stuff to work with SELinux in enforcing/targeted mode, that's all. 
And I can share that experience; I can also share the experience of having been
hacked once, and also the experience of multiple layers (including SELinux)
preventing a hack (or two).

But training in 'SELinux did this, do that' or 'here's common
symptoms of SELinux issues, and here's how to get into permissive mode so
you can figure out what's breaking, and here are your triage tools' is a
vital part of using SELinux to its potential.

But an ounce of prevention is worth a pound of cure; once an information theft
occurs, it cannot be undone.

On Tuesday, November 30, 2010 11:21:46 am Les Mikesell
wrote:
> I'm not talking about a particular app.  The thing I want quantified is
> what it will cost to train some number of people to be able to 
> troubleshoot any problem that SELinux might cause with any app, given 
> potential changes in updates to both the distribution provided stuff and 
> the 3rd party coding at any time.
That I wouldn't consider myself qualified to quantify.  I'm sure there
are those who are, however.

On Tuesday, November 30, 2010 12:18:26 pm Les Mikesell wrote:
 > But [what it will cost to train some number of people to be able
to
> troubleshoot any problem that SELinux might cause with any app, given
> potential changes in updates to both the distribution provided stuff and
> the 3rd party coding at any time] is the thing someone needs to be able 
> to estimate before considering enabling SELinux on an existing farm of 
> machines running complex, pre-existing applications where the team of
> operators has to be able to fix any potential problem quickly.
Before this can be done the analysts who perform such estimating as part of
their regular jobs need to become familiar with the overhead of setting up
SELinux, much like any other impacting technology the analysts already deal
with.

Such estimates have too many variables to state an easy answer in the general
sense, especially when unknowns such as the magnitude of potential updates is
factored in, or the degree of backporting of fixes into the pinned versions in
an Enterprise distribution.  For that matter, that is already the case in update
management for some apps, so there isn't any provably major overhead adding
SELinux to that mix for that particular criterion.

And is it the app causing problems with SELinux or is it SELinux causing
problems with the app?  Or is it the lack of integrator understanding in
marrying the two?  Or are the tools to configure the functionality to blame?

An integrator who as a matter of course sets SELinux to off or to permissive as
one of the first steps may be in for a rude awakening as pentesters wise up to
SELinux and specifically target penetration testing to that layer.  Especially
as empirical evidence to the utility of SELinux preventing exploitation of
vulnerabilities piles up ever higher.

Upstream and CentOS both ship with SELinux in the default 'more secure'
enforcing mode with the moderately strict targeted policy; to make a conscious
decision to reduce security for convenience would, at least in my shop, require
written justification.  An analysis of the time to take to implement the
controls in the app would be required at that time, as well as a risk analysis
of disabling the controls.  I would weigh the costs and the risks, and decide at
that time what to do (as I am the decision maker in my shop, I can do that, of
course).

It boils down to balancing 'it breaks my app that I can't or won't
fix' against 'you've been pwned!'

On Tuesday, November 30, 2010 02:04:12 pm Benjamin Franz
wrote:
> On 11/30/2010 10:42 AM, Lamar Owen wrote:
> >
> > It boils down to balancing 'it breaks my app that I can't or
won't fix' against 'you've been pwned!'
> 
> Actually, it boils down to 'what causes more total costs to the 
> business'. 
Not what causes, but what could cause, in the terms of the risk analysis.  The
probability of the cost is part of the equation, but in many cases it becomes
'what can a single breach cost me in the worst case' and that can
outweigh what seems to be large costs.  You might have a small probability of
infiltration, but the cost of a single infiltration (in some areas, like
healthcare and financial) can be so huge that a single infiltration could
bankrupt you.  If you do your online banking on your laptop, it is no stretch to
say that a single infiltration of your laptop has the potential to bankrupt you,
or worse.  Yeah, worse: the infiltrator might be malicious enough to plant
illegal material on your system and make your life really miserable, as the case
of Michael Fiola showed.

And in the main SELinux integration is not a high cost.  It may be in your area,
but it hasn't been in mine.  If it were that big of a problem, Red Hat
wouldn't include it in the upstream due to customer pressure.  SELinux, at
least for me and others, has a very positive benefit to cost ratio. YMMV.
> Security in not an end unto itself. It exists to support the business 
> making money. If a cost saving measure is costing the business more than 
> it is saving it, it is *not* a good idea no matter how technically 
> superior it is.
And that's a big if.  One must carefully define 'savings' in order
to make an informed decision.  It is a balance, that is sure.
> This in a very real sense is similar to the 'how much resources should 
> measures to prevent shoplifting be given' in a retail store. If the 
> anti-shoplifting measures are costing *more* than the shoplifting you 
> are preventing - you have lost sight of the actual reason for 
> anti-shoplifting measures in the first place.
As former loss-prevention for Kmart many years ago, I know that there's more
to that than economics, there's a significant public-relations piece
that's difficult to impossible to quantify.  And we found it difficult in
the extreme to determine how much theft the visible presence of loss-prevention
personnel and equipment actually prevented.

And there is an area where defense in depth is heavily practiced.

On Tuesday, November 30, 2010 04:52:42 pm Les Mikesell
wrote:
> I thought there was a security API in the kernel that was designed 
> specifically _not_ to lock it to an implementation.  
Yes; Linux Security Modules (LSM).  According to the wikipedia.org page on said
subject, the current 'officially' recognized modules are: AppArmor,
SELinux, SMACK, and TOMOYO Linux.
> Is there a 
> standards group for SELinux?  It's one thing to follow Posix, something
> else to be locked to a non-standard concept.
Hmmm, https://security.wiki.kernel.org/index.php/Projects seems to be the place
to look for information on the general topic of security (and lists more modules
than the Wikipedia article referenced above).  The SELinux site itself is
selinuxproject.org which has a lot of information; quite a bit updated since the
last time I looked.

It's as standard as pretty much any other open source project; there have
been several developer summits, for instance, and it has some well established
commercial players working together.  But if you're looking for an ISO or
ANSI or IEEE committee, no, none that I can tell.  Nor is there one for the
Linux kernel, or for glibc, for that matter.  Or TCP/IP, either.

On Tuesday, December 07, 2010 06:29:44 pm Les Mikesell
wrote:
> I think you've missed the point that 'all that stuff' (being
traditional unix
> security mechanisms) are not all that insecure.  It is only when you get
them
> wrong that you need to fall back on selinux as a safety net.   And if you
can't
> get the simple version right, how can you hope to do it right with
something
> wildly more complicated?
Alright, pray tell how I, a desktop Linux user, can, without VM's and
without having to switch users, protect my files from a PDF attack through Adobe
Reader?  Or a surf-by web infection (NoScript can help; NoScript is also a
pain)?  Or a flash bug?  Or any other exploit an attacker will try to use (and
the metasploit framework, among others, makes it trivial to set up these) that
doesn't require a root exploit to drop stuff in your .bashrc?

Real world: AJAX, Flash, and Java applets are required for many corporate web
sites.  They are also required for online banking and other online SaaS
applications, including cloud applications.  PDF fill-in forms are required in
many cases as well.  When one of those are compromised (not if, when), how will
standard user-based protections help you in a way that doesn't require
highly inconvenient solutions like switching users or running
'dangerous' apps in a VM?

(yes, I run plenty of servers, and I have been a VMware user for a very long
time.  But the desktop security use case often gets short shrift, and thus I
raise that banner, being that I have been a desktop Linux user for 13+ years)

On Wednesday, December 08, 2010 10:39:50 am Les Mikesell
wrote:
> On 12/8/2010 9:21 AM, Lamar Owen wrote:
> > Alright, pray tell how I, a desktop Linux user, can, without VM's
and without having to switch users, protect my files from a PDF attack through
Adobe Reader?
> 
> Don't run software you don't trust. Keep the software you run up to
> date.  Don't open files you don't trust.
That has nothing to do with user-id based security, Les.  And you're
intelligent enough to know that.

You cannot trust any file or software 100%; to trust 100% any file or software
over which you don't have 100% control is foolhardy.  The OS needs to be
able to execute untrusted software in a safe fashion in order to be usable in
this day and age, especially with SaaS and cloud computing becoming more and
more prevalent.  We're not in the 70's or 80's any more; we need
working controls that allow untrusted software to be run safely, even if the
user running that software is root.  Sorry, that's just a simple fact of
life in this connected age.  Of course, you then need to trust your OS, but the
fact that you run the OS is strong prima facie evidence that you trust it at
least to a degree (this is of course why I run Linux; I trust it more than the
others).
>  > Or a surf-by web infection (NoScript can help; NoScript is also a
pain)?
> 
> Don't visit web sites you don't trust with browsers that
auto-execute stuff.
Visit Linuxtoday.com and go to one of the linked articles; let your cursor roll
over a double-underlined word.  What happens?  What could happen?  What about
web caches in between?  Or rooted cisco routers sending your traffic to and from
a WCCP transparent webcache that poisons the stream, does MITM SSL funniness, or
worse.

Or a BPG AS hijack such as what was done back in April, that causes your
traffic, without your knowledge or awareness, to traverse an autonomous system
under potentially nefarious control (can happen, thanks to the nature of BGP)? 
How do you know for a fact that your packets to and from that trusted website
are not filtered, munged, and otherwise changed along the way?  Can you trust
SSL to not be vulnerable to MITM attacks?

You cannot trust any website 100% (no, you cannot trust 100% *any* website that
you don't personally have full control of its software, as well as any and
all caches/redirectors/accelerators/routers/switches/AS's in between).  The
only way to be 100% sure is to not visit any websites at all, ever, period. 
Wouldn't it easier to apply mandatory access controls to the web browser and
allow untrusted content to be rendered safely?
> >But the desktop security use case often gets short shrift, and thus I
raise that banner, being that I have been a desktop Linux user for 13+ years)
> 
> Does the default configuration cover the cases you present?  
I seriously doubt that it does; I would like to see it cover those cases, even
if that means me doing my own legwork and codework.
> Or are you 
> suggesting that every user needs the equivalent of a 4 day/$3K training 
> course to be able to secure their linux distribution?
No; what I'm suggesting is that the experts out there that have the corner
cases (and the time and inclination to help) try it, at least in testing, and
help out an open source effort, the fruits of which they're enjoying, in the
case of CentOS, for free, instead of being time-consuming gadflies.  I plan to
spend some time over the holidays in some autodidactic exercises on this
subject; the cost will be minimal, and I'll be the better admin for it.  And
I'll have a safer system on which to run untrusted software with less risk.

There are many things that need improvement; making a 'this is the way my
system runs normally; create a module that won't break when I update things
(and define what 'won't break' means)' module builder (for all I
know, one may exist already, and audit2allow in conjunction with permissive mode
does part of this for you).  Not breaking a working system is important to some;
failing safe (I'd rather it fail closed than open; YMMV) is also important
to others, depending upon the use case of the system.

But the developers of the system cannot possibly nor reasonably be expected to
know all the corner cases that people seem overly concerned with (any third
party app is by definition a corner case relative to the OS as shipped).  They
have to have bug reports and help in finding these cases.  Simply saying 'I
fixed it by turning it off, and, no I don't have time to send you a bug
report, you just have to guess what went wrong because I'm not turning it
back on until you fix your bug' is just unproductive.

If you want to disable SELinux, then of course by all means go ahead; the risk
is all yours.  The problem I and others have with the attitude of then making
that the default advice sent to the list is that it doesn't help fix the
underlying issues, and since the upstream does in fact ship SELinux on by
default it is more useful in the default case to try to help fix the actual
problem instead of griping about it being junk.

If you prefer to not provide useful information, well, that is of course your
right.  But that doesn't change my opinion that 'Disable SELinux, do it
the Old Unix Way and all will be well' as default advice is useless, and
does not help make the default CentOS experience any better.

On Wednesday, December 08, 2010 12:17:40 pm Les Mikesell
wrote:
> But your question was what to do if you choose to ignore the simple and 
> available tools - things available and well understood on many platforms.
VM = complex.  Not to mention proprietary (for all but KVM) and
resource-wasteful.
Switch User = inconvenient to the extreme, and disruptive of normal workflow.

I've done both, and neither are workable solutions for the majority of
users, especially on the desktop.  Both are more complex than SELinux *could*
be, with some effort.

SELinux is available for every major Linux distribution (including Ubuntu). 
It's on by default in RHEL/Fedora and most derivatives.  And there's the
TrustedBSD project's SEBSD port.

Sounds like a budding standard to me, and something worth learning.  Time to
expand your horizons, not put your head in the sand.

On Wednesday, December 08, 2010 01:02:10 pm Les Mikesell
wrote:
> Standards committees have their ways of breaking all previous existing 
> implementations with their final decrees.  Let me know when they are 
> finished.
Standards committees are never finished.

Linux is not standardized, either; in the case of CentOS, SELinux is a de facto
standard as it's in the default install set.  Linux != posix.

The inertia of the installed set means what you learn now will still be usable
in the future.  Much like with Linux itself.

On Wednesday, December 08, 2010 01:47:07 pm Daniel J Walsh
wrote:
> Sandbox -X might help solve some of these problems.  Available in RHEL6
> http://danwalsh.livejournal.com/31146.html?thread=212906
Looks interesting, Dan.  Thanks much.  And thanks much for the sometimes
thankless work of trying to make the power of SELinux more easily accessible.

On Wednesday, December 08, 2010 05:11:23 pm Warren Young
wrote:
> Let's not drag the desktop user into this discussion, too.
Why not?  Are there no CentOS desktop users out there?  Are the needs of the
desktop just to be ignored?  I support desktop Linux users who are not power
users; works great for them.  They're thrilled to not have viruses.
> Long experience has shown that when Joe User tries to do Thing X and is 
> prevented, then a popup appears that in effect says "run this command
to
> make this popup go away and allow Thing X to happen", THEY WILL RUN
THE
> COMMAND.  It's so reliable an effect that you could make a killing if 
> any bookie were stupid enough to let you bet on it.
Exactly.  That is precisely why you want controls to restrict what some random
program can do, and thus remove the danger. In my three teenage childrens'
vernacular, 'Well, duh!'
> Please, let's keep this thread centered on professionally-managed 
> servers, the focus of CentOS, and thus hopefully this list.  
Who says that's the focus?  While I'm sure the majority of CentOS
installs are for servers, the CentOS desktop does exist.  I know I have plenty
of CentOS servers; I also have Linux desktops of more than one distribution
scattered all over.

On Wednesday, December 08, 2010 10:06:34 pm Warren Young
wrote:
> That's great if you are wise enough to forsee all problems that an 
> automatic update can cause.
> I am not that wise.
Nor am I; that's why I have testing server VM's on which to stage
updates.  Even on the production servers, thanks to them being VMware guests I
can pull a snapshot prior to doing the updates, and if the update breaks things
badly enough I can roll back the snapshot from VMware and triage the problem. 
Updates should never be blind, IMHO, especially for production servers.

That's also why I keep regular backups of my laptop; in that case I'm
tracking Fedora (although I'm seriously considering purchasing RHEL
Workstation), and even then I have a test desktop to see if anything major
breaks.  While the test desktop is not identically configured, it is close
enough to be a valid test case, all the way down to the nVidia graphics.

On Thursday, December 09, 2010 12:02:44 am Robert Nichols
wrote:
> On 12/07/2010 05:11 PM, Rob Kampen wrote:
> > Daniel J Walsh wrote:
> >
http://people.fedoraproject.org/~dwalsh/SELinux/Presentations/selinux_four_things.pdf
> >>
> > I am having difficulty with the pdf file - both adobe and kpdf have
> > problems with the pages with screen shots - any chance of a fix?
> Those pages don't display properly with Adobe Reader (9.4.1) either. 
Confirmed with Okular on F14:
lowen at localhost:~$ okular --version
Qt: 4.7.1
KDE Development Platform: 4.5.3 (KDE 4.5.3)
Okular: 0.11.2
lowen at localhost:~$

Am 27.11.10 00:58, schrieb Alison:
> total newbie on CentOS. 
Nothing against you, you asked a completely valid question.

All others: Can this insanity please stop now? I'm really thinking about
setting a subject moderation filter on this subject.

Ralph