Another selinux rant

[Ed Swierk]

Since someone asked, here's my little SELinux rant:

Yesterday I set up a new server running F8. It's replacing an old
server and all it does is run sshd and openvpn. I decided to give
SELinux a try after many years of ignoring it.

I copied user home directories, /etc/passwd, /etc/shadow, /etc/group,
and ssh host keys from the old server to the new one. That was easy
enough.

I couldn't log into the machine using ssh public key authentication,
though--ssh kept falling back to password authentication. I checked
all the usual suspects like directory permissions, to no avail. I
passed -v -v -v to ssh and got no useful information.

After some poking around I noticed a bunch of messages in
/var/log/messages along the lines of "audit denied sshd btmp" and
"audit denied sshd /home/eswierk/..." blah blah blah. I figured this
was due to SELinux (although heaven knows why the message doesn't
contain the word "selinux"). Spent some time searching Google and came
across fixfiles, so I ran "fixfiles restore /", restarted sshd, and
voila, I could log in with a public key.

Next I copied the openvpn configuration from the old server and tried
to start it up. No joy. Having learned my lesson I headed straight to
/var/log/messages and once again found messages from SELinux, like
"audit denied openvpn ipp.txt". I ran "fixfiles restore /" again, but
this time it didn't help. Back to Google, and dug up some mailing list
messages with all sorts of stuff about updating policies. I spent
about 10 minutes trying various things without really understanding
them before resorting to the solution I do understand: set
SELINUX=disabled in /etc/sysconfig/selinux, reboot, done.

For me learning SELinux seems as pointless as trying to remember
iptables commands, or AFS trivia back when I was a student--all cause
me trouble just infrequently enough to ensure I have to relearn them
from scratch every time. If I were a full-time sysadmin of course it
would be a different story, but I really don't have the brain cycles
to remember anything more complicated than chmod and chown, and I
suspect a large number of accidental sysadmins feel the same.

--Ed

[Eric Paris]

Could you explain how you 'copied' these configuration files?  Is this
tar/untar ?  I'm trying to figure out how the labels for stuff in ~/.ssh
got messed up for you.

as to ipp.txt i don't know what it is so I can't even begin to guess....

-Eric

On Thu, 2008-01-03 at 13:29 -0800, Ed Swierk wrote:
>  Since someone asked, here's my little SELinux rant:
>  
>  Yesterday I set up a new server running F8. It's replacing an old
>  server and all it does is run sshd and openvpn. I decided to give
>  SELinux a try after many years of ignoring it.
>  
>  I copied user home directories, /etc/passwd, /etc/shadow, /etc/group,
>  and ssh host keys from the old server to the new one. That was easy
>  enough.
>  
>  I couldn't log into the machine using ssh public key authentication,
>  though--ssh kept falling back to password authentication. I checked
>  all the usual suspects like directory permissions, to no avail. I
>  passed -v -v -v to ssh and got no useful information.
>  
>  After some poking around I noticed a bunch of messages in
>  /var/log/messages along the lines of "audit denied sshd btmp" and
>  "audit denied sshd /home/eswierk/..." blah blah blah. I figured this
>  was due to SELinux (although heaven knows why the message doesn't
>  contain the word "selinux"). Spent some time searching Google and came
>  across fixfiles, so I ran "fixfiles restore /", restarted sshd, and
>  voila, I could log in with a public key.
>  
>  Next I copied the openvpn configuration from the old server and tried
>  to start it up. No joy. Having learned my lesson I headed straight to
>  /var/log/messages and once again found messages from SELinux, like
>  "audit denied openvpn ipp.txt". I ran "fixfiles restore /" again,
> but
>  this time it didn't help. Back to Google, and dug up some mailing list
>  messages with all sorts of stuff about updating policies. I spent
>  about 10 minutes trying various things without really understanding
>  them before resorting to the solution I do understand: set
>  SELINUX=disabled in /etc/sysconfig/selinux, reboot, done.
>  
>  For me learning SELinux seems as pointless as trying to remember
>  iptables commands, or AFS trivia back when I was a student--all cause
>  me trouble just infrequently enough to ensure I have to relearn them
>  from scratch every time. If I were a full-time sysadmin of course it
>  would be a different story, but I really don't have the brain cycles
>  to remember anything more complicated than chmod and chown, and I
>  suspect a large number of accidental sysadmins feel the same.
>  
>  --Ed
>

[Ed Swierk]

On 1/3/08, Eric Paris <eparis(a)redhat.com&gt; wrote:
>  Could you explain how you 'copied' these configuration files?
>  Is this
>  tar/untar ?  I'm trying to figure out how the labels for stuff in ~/.ssh
>  got messed up for you. 
Yes, I used tar to copy /home and /etc/openvpn. Openvpn stores state
for active connections in a file specified by the
--ifconfig-pool-persist option. Since the openvpn configuration recipe
I found online uses /etc/openvpn/ipp.txt, that's what I use.
Presumably the SELinux policy wants me to store that file somewhere
else?

--Ed

[Tomasz Torcz]

Dnia 03-01-2008, czw o godzinie 13:49 -0800, Ed Swierk pisze:
>  On 1/3/08, Eric Paris <eparis(a)redhat.com&gt; wrote:
>  > Could you explain how you 'copied' these configuration files?  Is this
>  > tar/untar ?  I'm trying to figure out how the labels for stuff in ~/.ssh
>  > got messed up for you. 
tar with "--xattrs"?

>  Yes, I used tar to copy /home and /etc/openvpn. Openvpn stores state
>  for active connections in a file specified by the
>  --ifconfig-pool-persist option. Since the openvpn configuration recipe
>  I found online uses /etc/openvpn/ipp.txt, that's what I use.
>  Presumably the SELinux policy wants me to store that file somewhere
>  else? 
  SELinux don't care about file location. It cares about labels. Policy
for *labeling* files and assorted utilities care for paths, but they are
only additional utilities, not SELinux itself..
  In your situation, ipp.txt must be writable by openvpn daemon. You can
achieve it by labeling (man chcon) ipp.txt as openvpn_var_log_t. By
default files in /etc/openvpn are labeled as openvpn_etc_t (openvpn's
configuration files). Daemons cannot modify their configuration files.

-- 
Tomasz Torcz

[Ed Swierk]

On 1/4/08, Tomasz Torcz <tomek(a)crocom.com.pl&gt; wrote:
>  tar with "--xattrs"? 
No, I didn't realize --xattrs existed; the tar info page doesn't
mention it. Oh, there it is in the man page.

Is there some reason why storing extended attributes by default would
be undesirable? I normally expect tar to carry all relevant metadata
with it; that's sort of the point of using tar.

>   SELinux don't care about file location. It cares about labels.
> Policy
>  for *labeling* files and assorted utilities care for paths, but they are
>  only additional utilities, not SELinux itself..
>   In your situation, ipp.txt must be writable by openvpn daemon. You can
>  achieve it by labeling (man chcon) ipp.txt as openvpn_var_log_t. By
>  default files in /etc/openvpn are labeled as openvpn_etc_t (openvpn's
>  configuration files). Daemons cannot modify their configuration files. 
I see. I now notice ls has a -Z option that shows the SELinux security context.

It would be nice if ls -l would show the security context by default
when SELinux is enabled, as the context is apparently just as
important as file permissions.

People who already know about SELinux can of course just learn to type
ls -l --lcontext, but showing the extra information by default would
at least give clueless users like me a hint that files have these
extra attributes that might somehow be relevant to those strange
openvpn failures. IMHO this would be the single best usability
improvement to SELinux (despite the fact that it makes the output too
wide for an 80-column display).

--Ed

[John Dennis]

Ed Swierk wrote:
>  People who already know about SELinux can of course just learn to
> type
>  ls -l --lcontext, but showing the extra information by default would
>  at least give clueless users like me a hint that files have these
>  extra attributes that might somehow be relevant to those strange
>  openvpn failures. IMHO this would be the single best usability
>  improvement to SELinux 
Re SELinux usability issues:

We wrote the setroubleshoot package precisely to help SELinux novice
users so they wouldn't suffer with hidden obscure failures of the type
which have frustrated you. If it had been installed you would have
received notifications in real time on your desktop describing the
failure and suggestions on how to fix it.
-- 
John Dennis <jdennis(a)redhat.com&gt;

[Ed Swierk]

On 1/4/08, John Dennis <jdennis(a)redhat.com&gt; wrote:
>  Re SELinux usability issues:
>
>  We wrote the setroubleshoot package precisely to help SELinux novice
>  users so they wouldn't suffer with hidden obscure failures of the type
>  which have frustrated you. If it had been installed you would have
>  received notifications in real time on your desktop describing the
>  failure and suggestions on how to fix it. 
The machine in question is a server with no graphical applications; is
there a command-line version of setroubleshoot?

--Ed

[Arthur Pemberton]

On Jan 4, 2008 11:26 AM, Ed Swierk <eswierk(a)arastra.com&gt; wrote:
>  On 1/4/08, John Dennis <jdennis(a)redhat.com&gt; wrote:
>  > Re SELinux usability issues:
>  >
>  > We wrote the setroubleshoot package precisely to help SELinux novice
>  > users so they wouldn't suffer with hidden obscure failures of the type
>  > which have frustrated you. If it had been installed you would have
>  > received notifications in real time on your desktop describing the
>  > failure and suggestions on how to fix it.
>
>  The machine in question is a server with no graphical applications; is
>  there a command-line version of setroubleshoot? 

One would hope you would have installed it by now. There is a very
nice command-line usage of setroubleshoot. I have never used the UI
myself. Frankly, I don't know how you've been using SELinux without
setroubleshoot.

-- 
Fedora 7 : sipping some of that moonshine
( www.pembo13.com )

[Ed Swierk]

On 1/4/08, Arthur Pemberton <pemboa(a)gmail.com&gt; wrote:
>  One would hope you would have installed it by now. There is a very
>  nice command-line usage of setroubleshoot. I have never used the UI
>  myself. Frankly, I don't know how you've been using SELinux without
>  setroubleshoot. 
It wasn't installed by default and I don't know how I should have
known to look for it (again, the audit log messages don't even mention
SELinux). If this is considered a key part of SELinux then Anaconda
shouldn't enable SELinux without it.

I assumed it was graphics-only because yum wants to drag in all sorts
of gnome and gtk2-related packages when I install it.

--Ed

[Arthur Pemberton]

On Jan 4, 2008 12:01 PM, Ed Swierk <eswierk(a)arastra.com&gt; wrote:
>  On 1/4/08, Arthur Pemberton <pemboa(a)gmail.com&gt; wrote:
>  > One would hope you would have installed it by now. There is a very
>  > nice command-line usage of setroubleshoot. I have never used the UI
>  > myself. Frankly, I don't know how you've been using SELinux without
>  > setroubleshoot.
>
>  It wasn't installed by default and I don't know how I should have
>  known to look for it (again, the audit log messages don't even mention
>  SELinux). If this is considered a key part of SELinux then Anaconda
>  shouldn't enable SELinux without it. 
Well it's a key component to managing SELinux, it doesn't actually
help SELinux to work.

>  I assumed it was graphics-only because yum wants to drag in all
> sorts
>  of gnome and gtk2-related packages when I install it. 

Yah. I'm not fond of how it is packaged myself... but since I can't do
better, i don't complain about it... it really does drag in too much
stuff however.

-- 
Fedora 7 : sipping some of that moonshine
( www.pembo13.com )

[Rahul Sundaram]

Arthur Pemberton wrote:
>  
>  Yah. I'm not fond of how it is packaged myself... but since I can't do
>  better, i don't complain about it... it really does drag in too much
>  stuff however. 
Complaining in bugzilla would be a useful contribution.

Rahul

[Arthur Pemberton]

On Jan 4, 2008 12:03 PM, Rahul Sundaram <sundaram(a)fedoraproject.org&gt; wrote:
>  Arthur Pemberton wrote:
>  >
>  > Yah. I'm not fond of how it is packaged myself... but since I can't do
>  > better, i don't complain about it... it really does drag in too much
>  > stuff however.
>
>  Complaining in bugzilla would be a useful contribution. 
Not a big enough deal. I'm not pulling my weight enough to be
nitpicking about a few more files.

-- 
Fedora 7 : sipping some of that moonshine
( www.pembo13.com )

[John Dennis]

Arthur Pemberton wrote:
>  Yah. I'm not fond of how it is packaged myself... but since I
> can't do
>  better, i don't complain about it... it really does drag in too much
>  stuff however. 
That's why setroubleshoot-server is a separate package, so it doesn't 
drag in all the other cruft the GUI needs.
-- 
John Dennis <jdennis(a)redhat.com&gt;

[Arthur Pemberton]

On Jan 4, 2008 12:17 PM, John Dennis <jdennis(a)redhat.com&gt; wrote:
>  Arthur Pemberton wrote:
>  > Yah. I'm not fond of how it is packaged myself... but since I can't do
>  > better, i don't complain about it... it really does drag in too much
>  > stuff however.
>
>  That's why setroubleshoot-server is a separate package, so it doesn't
>  drag in all the other cruft the GUI needs. 

That's the point I was trying to make.


-- 
Fedora 7 : sipping some of that moonshine
( www.pembo13.com )

[John Dennis]

Ed Swierk wrote:
>  On 1/4/08, John Dennis <jdennis(a)redhat.com&gt; wrote:
> > Re SELinux usability issues:
> >
> > We wrote the setroubleshoot package precisely to help SELinux novice
> > users so they wouldn't suffer with hidden obscure failures of the type
> > which have frustrated you. If it had been installed you would have
> > received notifications in real time on your desktop describing the
> > failure and suggestions on how to fix it.
>  
>  The machine in question is a server with no graphical applications; is
>  there a command-line version of setroubleshoot? 
Yes, setroubleshoot-server.

You have two options for receiving the alerts from the headless server.
You can either run the gui on a machine with a head and point it at the 
headless server (requires modifying the config file to use TCP rather 
than the default Unix domain sockets).

On the headless server edit /etc/setroubleshoot/setroubleshoot.cfg and 
in the listen_for_client section set the address_list parameter to 
{inet}server.ip.addr. Then on the GUI system do the same thing except 
set the address_list in the client_connect_to section.

-OR-

You can choose to have the headless server send you emails with the 
alert by editing the file

/var/lib/setroubleshoot/email_alert_recipients

and adding a line like this:

user(a)example.com                       filter_type=after_first

The filter_type specifies whether to filter the email alert, the 3 
possible values are:

after_first	filter the email after the first notification
always		always filter, thus never send an email alert
never		never filter, thus always send an email alert
-- 
John Dennis <jdennis(a)redhat.com&gt;

[John Dennis]

John Dennis wrote:
>  You have two options for receiving the alerts from the headless
> server. 
Oh, forgot to mention, those will get you realtime alert sent to you. 
But you can use sealert in command line mode too.

The alert will be logged to syslog with an ID, then you can:

% sealert -l ID

-or-

You can scan the audit log file (or any other log file) with:

% sealert -a logfile

-- 
John Dennis <jdennis(a)redhat.com&gt;

[Ed Swierk]

On 1/4/08, John Dennis <jdennis(a)redhat.com&gt; wrote:
>  You have two options for receiving the alerts from the headless
> server.
>  You can either run the gui on a machine with a head and point it at the
>  headless server (requires modifying the config file to use TCP rather
>  than the default Unix domain sockets).
>
>  [truncated] 
I appreciate your taking the time to explain setroubleshoot but
anything that involves configuring daemons and email addresses is a
usability hurdle in itself.

If the mysterious audit log messages can't be made clearer, then can't
we have a simple command-line tool to translate a message into a
friendlier form?

--Ed

[Konstantin Ryabitsev]

On Jan 4, 2008 2:44 PM, Ed Swierk <eswierk(a)arastra.com&gt; wrote:
>  If the mysterious audit log messages can't be made clearer, then
> can't
>  we have a simple command-line tool to translate a message into a
>  friendlier form? 
Generally, audit2why and audit2allow are your best friends when making
first inroads with SELinux.

Regards,
-- 
Konstantin Ryabitsev
Montréal, Québec

[John Dennis]

Ed Swierk wrote:
>  If the mysterious audit log messages can't be made clearer, then
> can't
>  we have a simple command-line tool to translate a message into a
>  friendlier form? 
% sudo sealert -a /var/log/audit/audit.log

-- 
John Dennis <jdennis(a)redhat.com&gt;

[Arthur Pemberton]

On Jan 4, 2008 1:44 PM, Ed Swierk <eswierk(a)arastra.com&gt; wrote:
>  On 1/4/08, John Dennis <jdennis(a)redhat.com&gt; wrote:
>  > You have two options for receiving the alerts from the headless server.
>  > You can either run the gui on a machine with a head and point it at the
>  > headless server (requires modifying the config file to use TCP rather
>  > than the default Unix domain sockets).
>  >
>  > [truncated]
>
>  I appreciate your taking the time to explain setroubleshoot but
>  anything that involves configuring daemons and email addresses is a
>  usability hurdle in itself.
>
>  If the mysterious audit log messages can't be made clearer, then can't
>  we have a simple command-line tool to translate a message into a
>  friendlier form?
>
>  --Ed 

Please try setroubleshot.


-- 
Fedora 7 : sipping some of that moonshine
( www.pembo13.com )

[Matej Cepl]

On 2008-01-04, 19:44 GMT, Ed Swierk wrote:
>  If the mysterious audit log messages can't be made clearer, 
>  then can't we have a simple command-line tool to translate 
>  a message into a friendlier form? 
audit2why(8)

[Les Mikesell]

Ed Swierk wrote:
>  On 1/4/08, John Dennis <jdennis(a)redhat.com&gt; wrote:
> > Re SELinux usability issues:
> >
> > We wrote the setroubleshoot package precisely to help SELinux novice
> > users so they wouldn't suffer with hidden obscure failures of the type
> > which have frustrated you. If it had been installed you would have
> > received notifications in real time on your desktop describing the
> > failure and suggestions on how to fix it.
>  
>  The machine in question is a server with no graphical applications; is
>  there a command-line version of setroubleshoot? 
As long as you have the X client libs installed you should be able to 
run GUI programs with remote display if you 'ssh -Y' to the machine from 
a terminal window on your desktop.

-- 
   Les Mikesell
    lesmikesell(a)gmail.com

[Matej Cepl]

On 2008-01-04, 17:07 GMT, John Dennis wrote:
>  Re SELinux usability issues:
>
>  We wrote the setroubleshoot package precisely to help SELinux novice
>  users so they wouldn't suffer with hidden obscure failures of the type
>  which have frustrated you. If it had been installed you would have
>  received notifications in real time on your desktop describing the
>  failure and suggestions on how to fix it. 
But you should probably emphasize more that relabel needs to be 
done on systems where SELinux was not used before. I know it is 
in man page, but apparently there are still very smart people who 
didn't get the memo.

Matěj

[Jonathan Underwood]

On 04/01/2008, John Dennis <jdennis(a)redhat.com&gt; wrote:
>  Ed Swierk wrote:
>  > People who already know about SELinux can of course just learn to type
>  > ls -l --lcontext, but showing the extra information by default would
>  > at least give clueless users like me a hint that files have these
>  > extra attributes that might somehow be relevant to those strange
>  > openvpn failures. IMHO this would be the single best usability
>  > improvement to SELinux
>
>  Re SELinux usability issues:
>
>  We wrote the setroubleshoot package precisely to help SELinux novice
>  users so they wouldn't suffer with hidden obscure failures of the type
>  which have frustrated you. If it had been installed you would have
>  received notifications in real time on your desktop describing the
>  failure and suggestions on how to fix it. 
The problem is, the notifications don't tell you much more than the
obscure avc denial in most cases. But there's a bigger problem than
that. Here's what happens when most people have an avc denial:

1) setroubleshoot pops up detailing the denial. The only really
intelligible part of the information there to the non expert is
"please file a report in bugzilla".

2) User thinks "oh, must be yet another problem with the selinux
policy" and files a bug.

3) Dan or his team fix the problem with the policy extremely rapidly.
New policy packages are installed.

4) Goto 1.

The problem is: setroubleshoot teaches average users that avc denials
come about due to bugs in selinux policy. If there was some massive
security problem right now on my machine causing avc denials I'd
probably react by filing a stack of bug reports. This is the
fundamental problem as it stands with SElinux. If it was working, we
would be in a situation where the first responce to an avc denial is
"OMG there's a security issue with something running on my machine, I
must fix that".

[Arthur Pemberton]

On Jan 4, 2008 4:30 PM, Jonathan Underwood <jonathan.underwood(a)gmail.com&gt; wrote:
>  On 04/01/2008, John Dennis <jdennis(a)redhat.com&gt; wrote:
>  > Ed Swierk wrote:
>  > > People who already know about SELinux can of course just learn to type
>  > > ls -l --lcontext, but showing the extra information by default would
>  > > at least give clueless users like me a hint that files have these
>  > > extra attributes that might somehow be relevant to those strange
>  > > openvpn failures. IMHO this would be the single best usability
>  > > improvement to SELinux
>  >
>  > Re SELinux usability issues:
>  >
>  > We wrote the setroubleshoot package precisely to help SELinux novice
>  > users so they wouldn't suffer with hidden obscure failures of the type
>  > which have frustrated you. If it had been installed you would have
>  > received notifications in real time on your desktop describing the
>  > failure and suggestions on how to fix it.
>
>  The problem is, the notifications don't tell you much more than the
>  obscure avc denial in most cases. But there's a bigger problem than
>  that. Here's what happens when most people have an avc denial:
>
>  1) setroubleshoot pops up detailing the denial. The only really
>  intelligible part of the information there to the non expert is
>  "please file a report in bugzilla". 
I don't know how the GUI version works, maybe you should try the
console version.

>  2) User thinks "oh, must be yet another problem with the selinux
>  policy" and files a bug. 
Why wouldn't they think "oh the program I am using and which is being
denied by SELInux might have a bug" ?

>  3) Dan or his team fix the problem with the policy extremely
> rapidly.
>  New policy packages are installed. 
Are you referring to a specific policy?

>  4) Goto 1.
>
>  The problem is: setroubleshoot teaches average users that avc denials
>  come about due to bugs in selinux policy. 
I get the feeling you're refering to some specific incident(s) as I
have never had a avn denial due to a SELinux bug (as far as I can
remember)

>  If there was some massive
>  security problem right now on my machine causing avc denials I'd
>  probably react by filing a stack of bug reports. This is the
>  fundamental problem as it stands with SElinux. 
No offence, but you _really_ should check the message before you file
a bug as is often makes sense. Or has SELinux taken a nose dive in F8
that I don't know about?

> If it was working, we
>  would be in a situation where the first responce to an avc denial is
>  "OMG there's a security issue with something running on my machine, I
>  must fix that". 
Again, I'm maybe missing information...but that's my first response
when I see an SELinux denial, esp. after it saved me from being rooted
once.

-- 
Fedora 7 : sipping some of that moonshine
( www.pembo13.com )

[Jonathan Underwood]

On 04/01/2008, Arthur Pemberton <pemboa(a)gmail.com&gt; wrote:
>  > 2) User thinks "oh, must be yet another problem with the
> selinux
>  > policy" and files a bug.
>
>  Why wouldn't they think "oh the program I am using and which is being
>  denied by SELInux might have a bug" ?
>  
Because most of the time it's an selinux policy bug. Granted, not
always, but often enough to make ones first thought be "oh, must be an
selinux problem, Ill turn it off" or "must be an selinux polciy
problem I'll run audit2allow and report a bug" - both of which are
suggested EVERY TIME by setroubleshoot. A naive user is then led to
think that this is the right thing to do in all instances.

>  > 3) Dan or his team fix the problem with the policy extremely
> rapidly.
>  > New policy packages are installed.
>
>  Are you referring to a specific policy?
>  
Yep, the Fedora ones of the last few releases :)

>  > 4) Goto 1.
>  >
>  > The problem is: setroubleshoot teaches average users that avc denials
>  > come about due to bugs in selinux policy.
>
>  I get the feeling you're refering to some specific incident(s) as I
>  have never had a avn denial due to a SELinux bug (as far as I can
>  remember)
>
>  > If there was some massive
>  > security problem right now on my machine causing avc denials I'd
>  > probably react by filing a stack of bug reports. This is the
>  > fundamental problem as it stands with SElinux.
>
>  No offence, but you _really_ should check the message before you file
>  a bug as is often makes sense. 
Of course, I know that. Many users may not, however.

>  Or has SELinux taken a nose dive in F8
>  that I don't know about?
>  
No, things are improving all the time.:)

>  >If it was working, we
>  > would be in a situation where the first responce to an avc denial is
>  > "OMG there's a security issue with something running on my machine, I
>  > must fix that".
>
>  Again, I'm maybe missing information...but that's my first response
>  when I see an SELinux denial, esp. after it saved me from being rooted
>  once.
>  
I fear you're in the minority of users. Look over at the users
forum/lists and see how many times you see people turning off
selinux...

J.

[Arthur Pemberton]

On Jan 4, 2008 4:57 PM, Jonathan Underwood <jonathan.underwood(a)gmail.com&gt; wrote:
>  Because most of the time it's an selinux policy bug. Granted,
> not
>  always, but often enough to make ones first thought be "oh, must be an
>  selinux problem, Ill turn it off" or "must be an selinux polciy
>  problem I'll run audit2allow and report a bug" - both of which are
>  suggested EVERY TIME by setroubleshoot. A naive user is then led to
>  think that this is the right thing to do in all instances. 
I have to say, it appears that my experiences with SELinux have been
much different from yours. I must admit however, that I do not run
SELinux on my desktops, maybe that's the issue -- I don't connect my
desktop directly to the internet either however, nor do I store that
much data on them.

<snip>

>  I fear you're in the minority of users. Look over at the users
>  forum/lists and see how many times you see people turning off
>  selinux... 
Have you considered the possibility of a large silent majority for
whom it works most of the time and so need not complain? Not that
valid complaints are a bad thing.


-- 
Fedora 7 : sipping some of that moonshine
( www.pembo13.com )

[Ed Swierk]

On 1/4/08, Arthur Pemberton <pemboa(a)gmail.com&gt; wrote:
>  Have you considered the possibility of a large silent majority for
>  whom it works most of the time and so need not complain? Not that
>  valid complaints are a bad thing. 
Without actual data it's impossible to know what the silent majority
is doing (although I have my suspicions). Is this a statistic that the
automatic hardware profiling whatchamacallit can help collect?

--Ed

[Arthur Pemberton]

On Jan 4, 2008 5:24 PM, Ed Swierk <eswierk(a)arastra.com&gt; wrote:
>  On 1/4/08, Arthur Pemberton <pemboa(a)gmail.com&gt; wrote:
>  > Have you considered the possibility of a large silent majority for
>  > whom it works most of the time and so need not complain? Not that
>  > valid complaints are a bad thing.
>
>  Without actual data it's impossible to know what the silent majority
>  is doing (although I have my suspicions). Is this a statistic that the
>  automatic hardware profiling whatchamacallit can help collect? 
I don't know, just attempting to provide an alternate view point.

-- 
Fedora 7 : sipping some of that moonshine
( www.pembo13.com )

[Jonathan Underwood]

On 04/01/2008, Arthur Pemberton <pemboa(a)gmail.com&gt; wrote:
>  Have you considered the possibility of a large silent majority for
>  whom it works most of the time and so need not complain? Not that
>  valid complaints are a bad thing.
>  
That could be the case. Perhaps there's something that could be added
to Smolt to allow the history of avc denials to be uploaded as part of
the profile - that would allow some really interesting analysis.

My main point really is about the advice that setroubleshoot gives, as
detailed previously.

J.

[Michael Wiktowy]

On Jan 4, 2008 6:54 PM, Jonathan Underwood <jonathan.underwood(a)gmail.com&gt; wrote:
>  That could be the case. Perhaps there's something that could be
> added
>  to Smolt to allow the history of avc denials to be uploaded as part of
>  the profile - that would allow some really interesting analysis. 
That is a great idea!

Even just something that indicates the proportion of people using
enforcing/permissive/disabled. That would be useful to either support
or refute the periodic SELinux rant threads based on people's personal
usage patterns and seem to take on a life of their own and inevitably
lead to statistics being pulled out of thin air.

/Mike

[John Dennis]

Michael Wiktowy wrote:
>  On Jan 4, 2008 6:54 PM, Jonathan Underwood
> <jonathan.underwood(a)gmail.com&gt; wrote:
> > That could be the case. Perhaps there's something that could be added
> > to Smolt to allow the history of avc denials to be uploaded as part of
> > the profile - that would allow some really interesting analysis.
>  
>  That is a great idea!
>  
>  Even just something that indicates the proportion of people using
>  enforcing/permissive/disabled. That would be useful to either support
>  or refute the periodic SELinux rant threads based on people's personal
>  usage patterns and seem to take on a life of their own and inevitably
>  lead to statistics being pulled out of thin air. 
For what it's worth setroubleshoot was designed to allow sending it's 
analysis to a central server to coalesce all the reports to get a global 
view (and to allow notifications to be sent back to the reporter when 
their issue was fixed if it was a bug). This was never fully implemented 
for the following reasons:

* audit data is security sensitive, transmitting it to a central server 
raises a host of issues.

* we needed a host to run the server on, at the time none existed 
(fedoraproject might be a viable option today).

* no one thought it was important.

The code in setroubleshoot still has all the logic built into it to 
support central aggregation, as it has from day one. But we would have 
to build the central server and solve the security issues. But this 
would occur if and only if there was a consensus this was important and 
volunteers stepped forward to perform the work.

-- 
John Dennis <jdennis(a)redhat.com&gt;

[James Morris]

On Fri, 4 Jan 2008, Jonathan Underwood wrote:

>  On 04/01/2008, Arthur Pemberton <pemboa(a)gmail.com&gt; wrote:
>  > Have you considered the possibility of a large silent majority for
>  > whom it works most of the time and so need not complain? Not that
>  > valid complaints are a bad thing.
>  >
>  
>  That could be the case. Perhaps there's something that could be added
>  to Smolt to allow the history of avc denials to be uploaded as part of
>  the profile - that would allow some really interesting analysis. 
Smolt has been collecting this information, but it has not yet been 
published on the web site (hopefully soon).



- James
-- 
James Morris
<jmorris(a)namei.org&gt;

[Yaakov Nemoy]

On Jan 6, 2008 5:51 PM, James Morris <jmorris(a)namei.org&gt; wrote:
>  > That could be the case. Perhaps there's something that could
> be added
>  > to Smolt to allow the history of avc denials to be uploaded as part of
>  > the profile - that would allow some really interesting analysis.
>
>  Smolt has been collecting this information, but it has not yet been
>  published on the web site (hopefully soon). 
Smolt doesn't collect that information, and that seems like a bad idea
for something for Smolt to collect.  Well, if you wanted to make
something like kerneloops, but called selinuxoops, then maybe we can
link Smolt information together on an opt-in basis.  I'm not sure what
you would gain by knowing what kind of CPU generated an SELinux error,
it would be no different than diagnosing permissions problems
remotely.  It's all in the software.

-Yaakov

[Eric Paris]

On Sun, 2008-01-06 at 18:05 -0500, Yaakov Nemoy wrote:
>  On Jan 6, 2008 5:51 PM, James Morris <jmorris(a)namei.org&gt;
> wrote:
>  > > That could be the case. Perhaps there's something that could be added
>  > > to Smolt to allow the history of avc denials to be uploaded as part of
>  > > the profile - that would allow some really interesting analysis.
>  >
>  > Smolt has been collecting this information, but it has not yet been
>  > published on the web site (hopefully soon).
>  
>  Smolt doesn't collect that information, and that seems like a bad idea
>  for something for Smolt to collect.  Well, if you wanted to make
>  something like kerneloops, but called selinuxoops, then maybe we can
>  link Smolt information together on an opt-in basis.  I'm not sure what
>  you would gain by knowing what kind of CPU generated an SELinux error,
>  it would be no different than diagnosing permissions problems
>  remotely.  It's all in the software. 
I don't know all the details but I do know smolt is collecting the
number of users who are leaving selinux turned on vs off.  I haven't
heard anything about AVC denial counts and stuff like that.  Hopefully
we will soon have published numbers about how many people are 'happily'
running with selinux.

-Eric

[Les Mikesell]

James Morris wrote:
>  On Fri, 4 Jan 2008, Jonathan Underwood wrote:
>  
> > On 04/01/2008, Arthur Pemberton <pemboa(a)gmail.com&gt; wrote:
> >> Have you considered the possibility of a large silent majority for
> >> whom it works most of the time and so need not complain? Not that
> >> valid complaints are a bad thing.
> >>
> > That could be the case. Perhaps there's something that could be added
> > to Smolt to allow the history of avc denials to be uploaded as part of
> > the profile - that would allow some really interesting analysis.
>  
>  Smolt has been collecting this information, but it has not yet been 
>  published on the web site (hopefully soon). 
I'd expect these numbers to be overwhelmed by groups that (a) don't run 
any services that need special handling and (b) run 3rd party apps that 
aren't integrated in the policy and disable selinux so they work at all. 
  Do you have a way to distinguish these from people running something 
with a fixable policy issue or account for them if you try to draw 
conclusions from the reported values?

-- 
   Les Mikesell
    lesmikesell(a)gmail.com

[Andrew Farris]

Jonathan Underwood wrote:
>  The problem is: setroubleshoot teaches average users that avc
> denials
>  come about due to bugs in selinux policy. If there was some massive
>  security problem right now on my machine causing avc denials I'd
>  probably react by filing a stack of bug reports. This is the
>  fundamental problem as it stands with SElinux. If it was working, we
>  would be in a situation where the first responce to an avc denial is
>  "OMG there's a security issue with something running on my machine, I
>  must fix that". 
True enough, but that (trusting denials are legitimate breaches) is a goal that 
is not necessarily here yet... while there are still bugs being filed in policy 
you (or 'average users' such as me and most rawhide testers) have very little 
chance of knowing which is which.

That doesn't mean it is not working... a security problem thats generating 
denials is only a problem per se when you go and disable selinux thinking 'its 
just a bug I can ignore these and let it happen'.

As long as a bug is filed, and your machine is still enforcing, and someone 
hasn't found a way around the denials, either the policy will change or Dan is 
going to post back to that bug report that what is happening is definitely not 
going to be allowed by policy.  Thats when you go fishing for your security issue.

Most people probably just go and disable it, assuming denials were from 
something they were trying to do and a bug prevented them from doing it.  I 
think its very important that rawhide testers be using selinux though because 
there is no way to prevent policy bugs from getting to release (and the broad 
userbase from then disabling selinux...) otherwise.

-- 
Andrew Farris <lordmorgul(a)gmail.com&gt; <ajfarris(a)gmail.com&gt;
  gpg 0xC99B1DF3 fingerprint CDEC 6FAD BA27 40DF 707E A2E0 F0F6 E622 C99B 1DF3
No one now has, and no one will ever again get, the big picture. - Daniel Geer
----                                                                       ----

[Jonathan Underwood]

On 04/01/2008, Andrew Farris <lordmorgul(a)gmail.com&gt; wrote:
>  Jonathan Underwood wrote:
>  > The problem is: setroubleshoot teaches average users that avc denials
>  > come about due to bugs in selinux policy. If there was some massive
>  > security problem right now on my machine causing avc denials I'd
>  > probably react by filing a stack of bug reports. This is the
>  > fundamental problem as it stands with SElinux. If it was working, we
>  > would be in a situation where the first responce to an avc denial is
>  > "OMG there's a security issue with something running on my machine, I
>  > must fix that".
>
>  True enough, but that (trusting denials are legitimate breaches) is a goal that
>  is not necessarily here yet... while there are still bugs being filed in policy
>  you (or 'average users' such as me and most rawhide testers) have very little
>  chance of knowing which is which.
>
>  That doesn't mean it is not working... a security problem thats generating
>  denials is only a problem per se when you go and disable selinux thinking 'its
>  just a bug I can ignore these and let it happen'.
>
>  As long as a bug is filed, and your machine is still enforcing, and someone
>  hasn't found a way around the denials, either the policy will change or Dan is
>  going to post back to that bug report that what is happening is definitely not
>  going to be allowed by policy.  Thats when you go fishing for your security issue.
>  
Yep, exactly. And in fact that's exactly what's happening - a good
example is a bug I filed against the SElinux policy which turned out
to be another program leaking file descriptors.

I worry though, because setroubleshoot suggests, amongst other things,
running audit2allow to allow whatever behaviour prompted the avc
denial. That's obviously very dangerous if you do it without knowing
what you're allowing.

>  Most people probably just go and disable it, assuming denials were
> from
>  something they were trying to do and a bug prevented them from doing it.  I
>  think its very important that rawhide testers be using selinux though because
>  there is no way to prevent policy bugs from getting to release (and the broad
>  userbase from then disabling selinux...) otherwise.
>  
Agreed, certainly.

j.

[Casey Dahlin]

Andrew Farris wrote:
>  Jonathan Underwood wrote:
> > The problem is: setroubleshoot teaches average users that avc denials
> > come about due to bugs in selinux policy. If there was some massive
> > security problem right now on my machine causing avc denials I'd
> > probably react by filing a stack of bug reports. This is the
> > fundamental problem as it stands with SElinux. If it was working, we
> > would be in a situation where the first responce to an avc denial is
> > "OMG there's a security issue with something running on my machine, I
> > must fix that".
>
>  True enough, but that (trusting denials are legitimate breaches) is a 
>  goal that is not necessarily here yet... while there are still bugs 
>  being filed in policy you (or 'average users' such as me and most 
>  rawhide testers) have very little chance of knowing which is which.
>
>  That doesn't mean it is not working... a security problem thats 
>  generating denials is only a problem per se when you go and disable 
>  selinux thinking 'its just a bug I can ignore these and let it happen'.
>
>  As long as a bug is filed, and your machine is still enforcing, and 
>  someone hasn't found a way around the denials, either the policy will 
>  change or Dan is going to post back to that bug report that what is 
>  happening is definitely not going to be allowed by policy.  Thats when 
>  you go fishing for your security issue.
>  
Or instead of you going fishing, the bug is recategorized and someone 
else comes in to work with you on fixing the real problem (since odds 
are we are packaging whatever it is that does have the issue).
>  Most people probably just go and disable it, assuming denials were 
>  from something they were trying to do and a bug prevented them from 
>  doing it.  I think its very important that rawhide testers be using 
>  selinux though because there is no way to prevent policy bugs from 
>  getting to release (and the broad userbase from then disabling 
>  selinux...) otherwise.
>  
I still tell new linux users to disable selinux when they install. Its 
just too much to explain to someone who is already in uncomfortable 
territory.

--CJD

[Ralf Corsepius]

On Fri, 2008-01-04 at 12:07 -0500, John Dennis wrote:
>  Ed Swierk wrote:
>  > People who already know about SELinux can of course just learn to type
>  > ls -l --lcontext, but showing the extra information by default would
>  > at least give clueless users like me a hint that files have these
>  > extra attributes that might somehow be relevant to those strange
>  > openvpn failures. IMHO this would be the single best usability
>  > improvement to SELinux
>  
>  Re SELinux usability issues:
>  
>  We wrote the setroubleshoot package precisely to help SELinux novice
>  users so they wouldn't suffer with hidden obscure failures of the type
>  which have frustrated you. If it had been installed you would have
>  received notifications in real time on your desktop describing the
>  failure and suggestions on how to fix it. 
Well, honorable goal, but does it
actually achieve this goal?

* On one machine (FC8/x86_64), for me, all setroubleshoot does is to die
shortly after bootup and first-time login (I haven't tried to
investigate, but as it seems to me some serelated daemon is
segfaulting).

* Is it appropriate to inform arbitrary ordinary users about SELinux
issues? May-be this on single user/non-networked machines, but I don't
think this is the right concept for a networked environment in which
"ordinary user" normally isn't the system admin.

Ralf

[Tom Lane]

Ralf Corsepius <rc040203(a)freenet.de&gt; writes:
>  * Is it appropriate to inform arbitrary ordinary users about SELinux
>  issues? 
That's a real good point, as are the others made in this thread.
I think the bottom line here is that we are still working to get the
selinux policies to the point where they work 99% for 99% of users.
Once we're there we should switch over to operating behaviors that
assume that most violations represent real security problems --- but
for now I don't think we are there yet.  What the current behaviors
need to do is to encourage people to report results, so that we can
collect more data about real vs phony violations.

			regards, tom lane

[Arthur Pemberton]

On Jan 5, 2008 12:33 AM, Ralf Corsepius <rc040203(a)freenet.de&gt; wrote:
>  On Fri, 2008-01-04 at 12:07 -0500, John Dennis wrote:
>  > Ed Swierk wrote:
>  > > People who already know about SELinux can of course just learn to type
>  > > ls -l --lcontext, but showing the extra information by default would
>  > > at least give clueless users like me a hint that files have these
>  > > extra attributes that might somehow be relevant to those strange
>  > > openvpn failures. IMHO this would be the single best usability
>  > > improvement to SELinux
>  >
>  > Re SELinux usability issues:
>  >
>  > We wrote the setroubleshoot package precisely to help SELinux novice
>  > users so they wouldn't suffer with hidden obscure failures of the type
>  > which have frustrated you. If it had been installed you would have
>  > received notifications in real time on your desktop describing the
>  > failure and suggestions on how to fix it.
>  Well, honorable goal, but does it actually achieve this goal?
>
>  * On one machine (FC8/x86_64), for me, all setroubleshoot does is to die
>  shortly after bootup and first-time login (I haven't tried to
>  investigate, but as it seems to me some serelated daemon is
>  segfaulting). 
You don't possibly think that this is the regular behaviour of
setroubleshoot on which you cna judge it?

>  * Is it appropriate to inform arbitrary ordinary users about SELinux
>  issues? May-be this on single user/non-networked machines, but I don't
>  think this is the right concept for a networked environment in which
>  "ordinary user" normally isn't the system admin. 
I'm not sure i understand the criticism here.

-- 
Fedora 7 : sipping some of that moonshine
( www.pembo13.com )

[Ralf Corsepius]

On Sat, 2008-01-05 at 01:36 -0600, Arthur Pemberton wrote:
>  On Jan 5, 2008 12:33 AM, Ralf Corsepius <rc040203(a)freenet.de&gt;
> wrote:
>  >
>  > On Fri, 2008-01-04 at 12:07 -0500, John Dennis wrote:
>  > > Ed Swierk wrote:
>  > > > People who already know about SELinux can of course just learn to type
>  > > > ls -l --lcontext, but showing the extra information by default would
>  > > > at least give clueless users like me a hint that files have these
>  > > > extra attributes that might somehow be relevant to those strange
>  > > > openvpn failures. IMHO this would be the single best usability
>  > > > improvement to SELinux
>  > >
>  > > Re SELinux usability issues:
>  > >
>  > > We wrote the setroubleshoot package precisely to help SELinux novice
>  > > users so they wouldn't suffer with hidden obscure failures of the type
>  > > which have frustrated you. If it had been installed you would have
>  > > received notifications in real time on your desktop describing the
>  > > failure and suggestions on how to fix it.
>  > Well, honorable goal, but does it actually achieve this goal?
>  >
>  > * On one machine (FC8/x86_64), for me, all setroubleshoot does is to die
>  > shortly after bootup and first-time login (I haven't tried to
>  > investigate, but as it seems to me some serelated daemon is
>  > segfaulting).
>  
>  You don't possibly think that this is the regular behaviour of
>  setroubleshoot on which you cna judge it? 
No, I am pretty certain it's an
setroubleshoot and/or its infrastructure
bug.

>  > * Is it appropriate to inform arbitrary ordinary users about
> SELinux
>  > issues? May-be this on single user/non-networked machines, but I don't
>  > think this is the right concept for a networked environment in which
>  > "ordinary user" normally isn't the system admin.
>  
>  I'm not sure i understand the criticism here. 
The question behind this: To whom
are SELinux messages/is setroubleshoot
of interest and who is able to react upon them?

In production systems, it's the system admin and nobody else.

For example, think about an "ordinary (SMB) office" situation. 
Most of such a system's users will not administrate their machines by
themselves, many of these users will be computer illiterates. 
All setroubleshoot offers to them is "clutter" to their desktop for
issues which are "none of their business".

In a "Linux-geek@home"/"personal desktop" scenario, the situation is
different. IMO, this is the scenario Fedora's current setroubleshoot is
appropriate for.

Ralf

[Andrew Farris]

Ralf Corsepius wrote:
>  On Sat, 2008-01-05 at 01:36 -0600, Arthur Pemberton wrote:
> > On Jan 5, 2008 12:33 AM, Ralf Corsepius <rc040203(a)freenet.de&gt; wrote:
> >> On Fri, 2008-01-04 at 12:07 -0500, John Dennis wrote:
> >>> Ed Swierk wrote:
> >>>> People who already know about SELinux can of course just learn to type
> >>>> ls -l --lcontext, but showing the extra information by default would
> >>>> at least give clueless users like me a hint that files have these
> >>>> extra attributes that might somehow be relevant to those strange
> >>>> openvpn failures. IMHO this would be the single best usability
> >>>> improvement to SELinux
> >>> Re SELinux usability issues:
> >>>
> >>> We wrote the setroubleshoot package precisely to help SELinux novice
> >>> users so they wouldn't suffer with hidden obscure failures of the type
> >>> which have frustrated you. If it had been installed you would have
> >>> received notifications in real time on your desktop describing the
> >>> failure and suggestions on how to fix it.
> >> Well, honorable goal, but does it actually achieve this goal?
> >>
> >> * On one machine (FC8/x86_64), for me, all setroubleshoot does is to die
> >> shortly after bootup and first-time login (I haven't tried to
> >> investigate, but as it seems to me some serelated daemon is
> >> segfaulting).
> > You don't possibly think that this is the regular behaviour of
> > setroubleshoot on which you cna judge it?
>  No, I am pretty certain it's an setroubleshoot and/or its infrastructure
>  bug.
>  
> >> * Is it appropriate to inform arbitrary ordinary users about SELinux
> >> issues? May-be this on single user/non-networked machines, but I don't
> >> think this is the right concept for a networked environment in which
> >> "ordinary user" normally isn't the system admin.
> > I'm not sure i understand the criticism here.
>  The question behind this: To whom are SELinux messages/is setroubleshoot
>  of interest and who is able to react upon them?
>  
>  In production systems, it's the system admin and nobody else.
>  
>  For example, think about an "ordinary (SMB) office" situation. 
>  Most of such a system's users will not administrate their machines by
>  themselves, many of these users will be computer illiterates. 
>  All setroubleshoot offers to them is "clutter" to their desktop for
>  issues which are "none of their business". 
Naturally... which is the reason those users should not have setroubleshoot 
available to them... the name itself should make this obvious.  Its a tool made 
for the development phase of a technology, not for a production system in a 
typical office environment.

>  In a "Linux-geek@home"/"personal desktop"
> scenario, the situation is
>  different. IMO, this is the scenario Fedora's current setroubleshoot is
>  appropriate for. 
Yes, I've personally found it very helpful in testing rawhide in this scenario.

-- 
Andrew Farris <lordmorgul(a)gmail.com&gt; <ajfarris(a)gmail.com&gt;
  gpg 0xC99B1DF3 fingerprint CDEC 6FAD BA27 40DF 707E A2E0 F0F6 E622 C99B 1DF3
No one now has, and no one will ever again get, the big picture. - Daniel Geer
----                                                                       ----

[Casey Dahlin]

Ralf Corsepius wrote:
>  On Sat, 2008-01-05 at 01:36 -0600, Arthur Pemberton wrote:
>    
> > On Jan 5, 2008 12:33 AM, Ralf Corsepius <rc040203(a)freenet.de&gt; wrote:
> >     
> >> On Fri, 2008-01-04 at 12:07 -0500, John Dennis wrote:
> >>       
> >>> Ed Swierk wrote:
> >>>         
> >>>> People who already know about SELinux can of course just learn to type
> >>>> ls -l --lcontext, but showing the extra information by default would
> >>>> at least give clueless users like me a hint that files have these
> >>>> extra attributes that might somehow be relevant to those strange
> >>>> openvpn failures. IMHO this would be the single best usability
> >>>> improvement to SELinux
> >>>>           
> >>> Re SELinux usability issues:
> >>>
> >>> We wrote the setroubleshoot package precisely to help SELinux novice
> >>> users so they wouldn't suffer with hidden obscure failures of the type
> >>> which have frustrated you. If it had been installed you would have
> >>> received notifications in real time on your desktop describing the
> >>> failure and suggestions on how to fix it.
> >>>         
> >> Well, honorable goal, but does it actually achieve this goal?
> >>
> >> * On one machine (FC8/x86_64), for me, all setroubleshoot does is to die
> >> shortly after bootup and first-time login (I haven't tried to
> >> investigate, but as it seems to me some serelated daemon is
> >> segfaulting).
> >>       
> > You don't possibly think that this is the regular behaviour of
> > setroubleshoot on which you cna judge it?
> >     
>  No, I am pretty certain it's an setroubleshoot and/or its infrastructure
>  bug.
>
>     
And have you done with this bug what I'm sure we all know we are 
supposed to do with bugs we find? :P

--CJD

[Ralf Corsepius]

On Sun, 2008-01-06 at 18:49 -0500, Casey Dahlin wrote:
>  Ralf Corsepius wrote:
>  > On Sat, 2008-01-05 at 01:36 -0600, Arthur Pemberton wrote:
>  >   
>  >> On Jan 5, 2008 12:33 AM, Ralf Corsepius <rc040203(a)freenet.de&gt; wrote:
>  >>     
>  >>> On Fri, 2008-01-04 at 12:07 -0500, John Dennis wrote:
>  >>>       
>  >>>> Ed Swierk wrote:
>  >>>>         
>  >>>>> People who already know about SELinux can of course just learn to
> type
>  >>>>> ls -l --lcontext, but showing the extra information by default
> would
>  >>>>> at least give clueless users like me a hint that files have these
>  >>>>> extra attributes that might somehow be relevant to those strange
>  >>>>> openvpn failures. IMHO this would be the single best usability
>  >>>>> improvement to SELinux
>  >>>>>           
>  >>>> Re SELinux usability issues:
>  >>>>
>  >>>> We wrote the setroubleshoot package precisely to help SELinux novice
>  >>>> users so they wouldn't suffer with hidden obscure failures of the
> type
>  >>>> which have frustrated you. If it had been installed you would have
>  >>>> received notifications in real time on your desktop describing the
>  >>>> failure and suggestions on how to fix it.
>  >>>>         
>  >>> Well, honorable goal, but does it actually achieve this goal?
>  >>>
>  >>> * On one machine (FC8/x86_64), for me, all setroubleshoot does is to die
>  >>> shortly after bootup and first-time login (I haven't tried to
>  >>> investigate, but as it seems to me some serelated daemon is
>  >>> segfaulting).
>  >>>       
>  >> You don't possibly think that this is the regular behaviour of
>  >> setroubleshoot on which you cna judge it?
>  >>     
>  > No, I am pretty certain it's an setroubleshoot and/or its infrastructure
>  > bug.
>  >
>  >   
>  And have you done with this bug what I'm sure we all know we are 
>  supposed to do with bugs we find? :P 
Done right now. 

This morning's reboot gave me another opportunity to take a somewhat
deeper look ;)

https://bugzilla.redhat.com/show_bug.cgi?id=427721

Ralf

[John Dennis]

Ralf Corsepius wrote:
> > And have you done with this bug what I'm sure we all know we
> are 
> > supposed to do with bugs we find? :P
>  Done right now. 
>  
>  This morning's reboot gave me another opportunity to take a somewhat
>  deeper look ;)
>  
>  https://bugzilla.redhat.com/show_bug.cgi?id=427721 
Thank you Ralf, following up with a bugzilla is very much appreciated. 
The key to diagnosing the problem is right there in the syslog:

setroubleshoot: [program.ERROR] Can not handle AVC'S related to the 
dispatcher. exiting

tcontext=unconfined_u:system_r:setroubleshootd_t:s0 
scontext=unconfined_u:system_r:setroubleshootd_t:s0

This means setroubleshootd saw an AVC that it generated itself. This 
should never happen and to prevent infinite recursion the daemon shuts 
down. This is most likely due to a policy bug. There were some known 
policy bugs early in F8 (before GOLD) related to setroubleshoot but 
those should have been fixed. Is your policy up to date?

-- 
John Dennis <jdennis(a)redhat.com&gt;

[Michael Wiktowy]

On Jan 7, 2008 11:50 AM, John Dennis <jdennis(a)redhat.com&gt; wrote:
>  Ralf Corsepius wrote:
>  >> And have you done with this bug what I'm sure we all know we are
>  >> supposed to do with bugs we find? :P
>  > Done right now.
>  >
>  > This morning's reboot gave me another opportunity to take a somewhat
>  > deeper look ;)
>  >
>  > https://bugzilla.redhat.com/show_bug.cgi?id=427721
>
>  Thank you Ralf, following up with a bugzilla is very much appreciated.
>  The key to diagnosing the problem is right there in the syslog:
>
>  setroubleshoot: [program.ERROR] Can not handle AVC'S related to the
>  dispatcher. exiting
>
>  tcontext=unconfined_u:system_r:setroubleshootd_t:s0
>  scontext=unconfined_u:system_r:setroubleshootd_t:s0
>
>  This means setroubleshootd saw an AVC that it generated itself. This
>  should never happen and to prevent infinite recursion the daemon shuts
>  down. This is most likely due to a policy bug. There were some known
>  policy bugs early in F8 (before GOLD) related to setroubleshoot but
>  those should have been fixed. Is your policy up to date? 
I have been seeing the same thing very recently with a fully up to
date F8 installation that has never seen Rawhide. I thought that it
was related to my LiveCD creation but I had setroubleshoot applet
disconnect from the selinux deamon soon after my Sunday log rotation.
I will add my logs to this bug when I get a chance.

/Mike

[John Dennis]

Ralf Corsepius wrote:
>  * Is it appropriate to inform arbitrary ordinary users about SELinux
>  issues? May-be this on single user/non-networked machines, but I don't
>  think this is the right concept for a networked environment in which
>  "ordinary user" normally isn't the system admin. 
This is why setroubleshoot was designed to operate in a distributed 
network mode. At the time of setroubleshoot's initial release it was 
felt this was a corner case, that the most likely user of the tool would 
be developers and technically astute users both running locally. The 
distributed aspects of the tool were never promoted, although they 
continue to reside in the code.

In fairness the networked facilities need some enhancements to make them 
fully viable. For instance the network traffic is not encrypted, a 
critical feature when transmitting security sensitive data and it needs 
to be fronted by a more robust authentication mechanism.

-- 
John Dennis <jdennis(a)redhat.com&gt;

[Jeff MacDonald]

greetings,


On Mon, Jan 07, 2008 at 02:47:48PM -0500, John Dennis wrote:
[..snipped..]
>  In fairness the networked facilities need some enhancements to make
> them 
>  fully viable. For instance the network traffic is not encrypted, a 
>  critical feature when transmitting security sensitive data and it needs 
>  to be fronted by a more robust authentication mechanism.
>   
my use case would be in a private network environment (call center, noc,
etc) so the messages would not necessarily need to be encrypted.. my concern
would be that they get to the central server reliably.

>  -- 
>  John Dennis <jdennis(a)redhat.com&gt;
>   
regards,
 --jeff
-- 
http://zoidtechnologies.com/ -- websites that suck less

[Steve Grubb]

On Monday 07 January 2008 15:07:24 jam(a)zoidtechnologies.com wrote:
>  > In fairness the networked facilities need some enhancements to
> make them
>  > fully viable. For instance the network traffic is not encrypted, a
>  > critical feature when transmitting security sensitive data and it needs
>  > to be fronted by a more robust authentication mechanism.
>
>  my use case would be in a private network environment (call center, noc,
>  etc) so the messages would not necessarily need to be encrypted.. my
>  concern would be that they get to the central server reliably. 
There are plans to create a remote logging plugin for the audit system. This 
will handle more traffic than just the avc's. There are a number of issues 
that have to be resolved in order for this to work correctly. I hope that it 
will be done in time for F9.

-Steve

[Jason L Tibbitts III]

> >>>> "JD" == John Dennis
> <jdennis(a)redhat.com&gt; writes: 
JD> This is why setroubleshoot was designed to operate in a
JD> distributed network mode. At the time of setroubleshoot's initial
JD> release it was felt this was a corner case, that the most likely
JD> user of the tool would be developers and technically astute users
JD> both running locally. The distributed aspects of the tool were
JD> never promoted, although they continue to reside in the code.

Well, I for one would be happy to run a local server so that I can
keep an eye on selinux issues on the desktops here.  I've been
cautiously rolling selinux out on user desktops and try to run it on
servers whenever I can (which is becoming much more often as I
understand more about how it works) but the only way I know there are
issues is if something explicitly breaks or by reading logwatch
reports.

Of course, my users should never see any kind of setroubleshoot
applet; they have no idea what it would mean and they don't have
privileges to make changes anyway.

 - J<

[James Antill]

On Fri, 2008-01-04 at 08:40 -0800, Ed Swierk wrote:
>  On 1/4/08, Tomasz Torcz <tomek(a)crocom.com.pl&gt; wrote:
>  > tar with "--xattrs"?
>  
>  No, I didn't realize --xattrs existed; the tar info page doesn't
>  mention it. Oh, there it is in the man page. 
 If I do "info tar" on Fed-8 the second hit for a search on "selinux"
gives the --selinux option and the --xattrs option is visible just below
it (--xattrs includes --selinux).

>  Is there some reason why storing extended attributes by default
> would
>  be undesirable? I normally expect tar to carry all relevant metadata
>  with it; that's sort of the point of using tar. 
 Well we didn't want to do this until the patch for xattrs/ACLs/SELinux
is upstream as it changes the default tar format and GNU tars without
the patch will display a bunch of annoying warnings.
 Esp. given how much tar is used to distribute software, where
perms/xattrs aren't really wanted.

-- 
James Antill <james.antill(a)redhat.com&gt;
Red Hat

[Ed Swierk]

On 1/4/08, James Antill <james.antill(a)redhat.com&gt; wrote:
>   If I do "info tar" on Fed-8 the second hit for a search on
> "selinux"
>  gives the --selinux option and the --xattrs option is visible just below
>  it (--xattrs includes --selinux). 
Oh, I see. I was looking in the "All tar options" section (3.4).

--Ed

[Steve Grubb]

On Friday 04 January 2008 12:24:24 James Antill wrote:
>  > Is there some reason why storing extended attributes by default
> would
>  > be undesirable? I normally expect tar to carry all relevant metadata
>  > with it; that's sort of the point of using tar.
>
>   Well we didn't want to do this until the patch for xattrs/ACLs/SELinux
>  is upstream as it changes the default tar format and GNU tars without
>  the patch will display a bunch of annoying warnings. 
And furthermore...if you tar a directory up on Fedora 8 and untar it on 
OpenBSD machine...its not going to know what to do with the extended 
attributes for SE Linux. Since open source software is used across many 
platforms, its wasteful to turn it on by default.

-Steve

[Michael Wiktowy]

On Jan 4, 2008 11:40 AM, Ed Swierk <eswierk(a)arastra.com&gt; wrote:
>  On 1/4/08, Tomasz Torcz <tomek(a)crocom.com.pl&gt; wrote:
>  > tar with "--xattrs"?
>
>  No, I didn't realize --xattrs existed; the tar info page doesn't
>  mention it. Oh, there it is in the man page.
>  I see. I now notice ls has a -Z option that shows the SELinux security context.
>
>  It would be nice if ls -l would show the security context by default
>  when SELinux is enabled, as the context is apparently just as
>  important as file permissions. 
I started to use cp -P + rm rather than mv to shuffle around config
files and files between user directories and 99% of my selinux
attribute issues went away. I checked the man page for mv and didn't
see anything; is there an equivalent to cp's -P parameter for mv?

/Mike

[Arthur Pemberton]

On Jan 4, 2008 2:39 PM, Michael Wiktowy <michael.wiktowy(a)gmail.com&gt; wrote:
>  On Jan 4, 2008 11:40 AM, Ed Swierk <eswierk(a)arastra.com&gt;
> wrote:
>  > On 1/4/08, Tomasz Torcz <tomek(a)crocom.com.pl&gt; wrote:
>  > > tar with "--xattrs"?
>  >
>  > No, I didn't realize --xattrs existed; the tar info page doesn't
>  > mention it. Oh, there it is in the man page.
>  > I see. I now notice ls has a -Z option that shows the SELinux security context.
>  >
>  > It would be nice if ls -l would show the security context by default
>  > when SELinux is enabled, as the context is apparently just as
>  > important as file permissions.
>
>  I started to use cp -P + rm rather than mv to shuffle around config
>  files and files between user directories and 99% of my selinux
>  attribute issues went away. I checked the man page for mv and didn't
>  see anything; is there an equivalent to cp's -P parameter for mv?
>
>  /Mike 

This has suggested before in reply to past rants.


-- 
Fedora 7 : sipping some of that moonshine
( www.pembo13.com )

[Konstantin Ryabitsev]

On Jan 3, 2008 4:29 PM, Ed Swierk <eswierk(a)arastra.com&gt; wrote:
>  For me learning SELinux seems as pointless as trying to remember
>  iptables commands, or AFS trivia back when I was a student--all cause
>  me trouble just infrequently enough to ensure I have to relearn them
>  from scratch every time. If I were a full-time sysadmin of course it
>  would be a different story, but I really don't have the brain cycles
>  to remember anything more complicated than chmod and chown, and I
>  suspect a large number of accidental sysadmins feel the same. 
Well, if it's any consolation, there are those of us who really quite
appreciate SELinux. It's really not that intrusive in targeted mode --
I've been running my workstations in enforcing mode for the past 2
years, and it's only fairly rarely that I find something that's not
working because of SELinux. In these cases, if it's something that I
have to do on a one-off basis, I just do "setenforce 0" and then
"setenforce 1" when I'm done (or just leave it as is until next
reboot).

Yes, SELinux is very complex, but that's because what it's trying to
do is also very complex. However, it's not insurmountable to learn.
Take it from someone who had to write an SELinux policy -- it took me
a week worth of effort to get to the point where it worked as
intended, but I finally got there. Once you wrap your brain around it,
it's fairly straightforward.

Regards,
-- 
Konstantin Ryabitsev
Montréal, Québec

[Ed Hill]

On Thu, 3 Jan 2008 13:29:18 -0800 "Ed Swierk" wrote:

>  Since someone asked, here's my little SELinux rant: 
[ ...rant truncated... :-) ]
 
>  For me learning SELinux seems as pointless as trying to remember
>  iptables commands, or AFS trivia back when I was a student--all cause
>  me trouble just infrequently enough to ensure I have to relearn them
>  from scratch every time. If I were a full-time sysadmin of course it
>  would be a different story, but I really don't have the brain cycles
>  to remember anything more complicated than chmod and chown, and I
>  suspect a large number of accidental sysadmins feel the same. 

I run into similar problems every time I've tried to enable SELinux.  I
now run it in "permissive" mode on most of my machines and watch the
occasional warnings appear in /var/log/messages.

But I think the situation is improving since I'm seeing fewer warnings
in F8 than with F7 or FC6.  And you can install the "sealert" packages:

  setroubleshoot.noarch
  setroubleshoot-plugins.noarch
  setroubleshoot-server.noarch

which provide much more detailed and helpful diagnostic messages.

Ed

-- 
Edward H. Hill III, PhD  |  ed(a)eh3.com  |  http://eh3.com/

[Andrew Farris]

Ed Swierk wrote:
>  For me learning SELinux seems as pointless as trying to remember
>  iptables commands, or AFS trivia back when I was a student--all cause
>  me trouble just infrequently enough to ensure I have to relearn them
>  from scratch every time. If I were a full-time sysadmin of course it
>  would be a different story, but I really don't have the brain cycles
>  to remember anything more complicated than chmod and chown, and I
>  suspect a large number of accidental sysadmins feel the same. 
Selinux is (no argument) something that takes considerable time to start
figuring out... but basically you have to start by realizing nothing is going to
work right if the files aren't labeled as the policy expects them to be.  This
is precisely the same situation you have when file permissions are wrong and
nothing will work until you fix them (selinux policy is really just a more
complicated permissions system for who can use files and for what purpose).

When you started out with unices the permissions system probably took time but
it eventually sank in -- so will selinux unless you continue to ignore it.  Just
food for thought... I'm sure everyone knows it takes time, the question becomes
'is it important' and alot of people feel the answer is yes.

As the policies improve selinux will become hardly more complicated for general
use as chmod itself is... proper policy + proper label = just works.  Obviously
both of those need to be in place and are in progress; so disable it when you
must now but if you just ignore it long term its to your detriment.  Set it
permissive at minimum and keep the denial log messages for additional security
review if/when you really need it.  And finally, the ability to disable it is in
the distro precisely so that you can (so why the rant? you want to be forced to
enable it instead? you feel everyone should install without it enabled by
default forever and ever? you feel that selinux should disable itself when you
get denials that prevent you doing what you want? uhm that won't do).

-- 
Andrew Farris <lordmorgul(a)gmail.com&gt; <ajfarris(a)gmail.com&gt;
 gpg 0xC99B1DF3 fingerprint CDEC 6FAD BA27 40DF 707E A2E0 F0F6 E622 C99B 1DF3
No one now has, and no one will ever again get, the big picture. - Daniel Geer
----                                                                       ----

[Ed Swierk]

On 1/3/08, Andrew Farris <lordmorgul(a)gmail.com&gt; wrote:
>  As the policies improve selinux will become hardly more complicated
> for general
>  use as chmod itself is... proper policy + proper label = just works.  Obviously
>  both of those need to be in place and are in progress; so disable it when you
>  must now but if you just ignore it long term its to your detriment.  Set it
>  permissive at minimum and keep the denial log messages for additional security
>  review if/when you really need it.  And finally, the ability to disable it is in
>  the distro precisely so that you can (so why the rant? you want to be forced to
>  enable it instead? you feel everyone should install without it enabled by
>  default forever and ever? you feel that selinux should disable itself when you
>  get denials that prevent you doing what you want? uhm that won't do). 
No, no and no. Dimi raised the issue of gauging the usability of
SELinux, and the only point of my rant was to convey the experience
that led me to disable it.

--Ed

[Andrew Farris]

Ed Swierk wrote:
>  On 1/3/08, Andrew Farris <lordmorgul(a)gmail.com&gt; wrote:
> > As the policies improve selinux will become hardly more complicated for general
> > use as chmod itself is... proper policy + proper label = just works.  Obviously
> > both of those need to be in place and are in progress; so disable it when you
> > must now but if you just ignore it long term its to your detriment.  Set it
> > permissive at minimum and keep the denial log messages for additional security
> > review if/when you really need it.  And finally, the ability to disable it is in
> > the distro precisely so that you can (so why the rant? you want to be forced to
> > enable it instead? you feel everyone should install without it enabled by
> > default forever and ever? you feel that selinux should disable itself when you
> > get denials that prevent you doing what you want? uhm that won't do).
>  
>  No, no and no. Dimi raised the issue of gauging the usability of
>  SELinux, and the only point of my rant was to convey the experience
>  that led me to disable it.
>  
>  --Ed 
Ok I understand then, however I'd just comment that as a gauge of usability I
think your situation (moving configurations across platforms, from no selinux to
selinux) is somewhat of a fringe case.  I realize that MANY admins would be
doing just that in the process of adopting selinux since rewriting
configurations is a major pain, but its still something that can almost be
expected to cause headache (and requires labeling).  Just my 2c on usability, it
still seems to work best when you start out from install with selinux enabled
and avoid deliberately circumventing it.

Would you say that documentation on that specific issue (migrating
configurations) needs more attention?

The big thing is any file moved has to get labeled.  Your openvpn issue looks
like it might be a real policy problem.

-- 
Andrew Farris <lordmorgul(a)gmail.com&gt; <ajfarris(a)gmail.com&gt;
 gpg 0xC99B1DF3 fingerprint CDEC 6FAD BA27 40DF 707E A2E0 F0F6 E622 C99B 1DF3
No one now has, and no one will ever again get, the big picture. - Daniel Geer
----                                                                       ----

[Ed Swierk]

On 1/3/08, Andrew Farris <lordmorgul(a)gmail.com&gt; wrote:
>  Ok I understand then, however I'd just comment that as a gauge of
> usability I
>  think your situation (moving configurations across platforms, from no selinux to
>  selinux) is somewhat of a fringe case.  I realize that MANY admins would be
>  doing just that in the process of adopting selinux since rewriting
>  configurations is a major pain, but its still something that can almost be
>  expected to cause headache (and requires labeling).  Just my 2c on usability, it
>  still seems to work best when you start out from install with selinux enabled
>  and avoid deliberately circumventing it. 
Believe me, as an engineer I understand how annoying it is to learn
that a user has given up in frustration after 10 minutes just because
they ran into trivial issue like a bug in the installer. Unfortunately
the most luxuriously smooth freeway in the world will lie unused if
the on-ramps are full of land mines. :-)

>  Would you say that documentation on that specific issue (migrating
>  configurations) needs more attention? 
I think improving error messages and warnings and default behavior
(see my earlier comments on tar and ls) is more worthwhile than
writing documentation, as the latter tends not to get read.

--Ed

[Ray Van Dolson]

>  I think improving error messages and warnings and default behavior
>  (see my earlier comments on tar and ls) is more worthwhile than
>  writing documentation, as the latter tends not to get read. 
+1 for the error messages.  Msot of us are used to things not always
quite working in the world of Unix.  We're used to just taking a look
at /var/log/messages and getting a pretty good idea as to what the
problem is.

I guess the SELinux troubleshooter goes a long way to addressing this,
so maybe there's no point to making the syslog messages a bit better
for human consumption.

Ray

[Patrice Dumas]

On Thu, Jan 03, 2008 at 05:52:56PM -0800, Andrew Farris wrote:
>  
>  must now but if you just ignore it long term its to your detriment.  Set it 
Not necessarily. file permissions are only useful if you want privilege
separation. Likewise selinux is only useful if you want fine grained 
file access rights.

So far, I don't need the corresponding complexity, though I know tht it
is at the expense of some security.

--
Pat

[Matej Cepl]

On 2008-01-03, 21:29 GMT, Ed Swierk wrote:
>  For me learning SELinux seems as pointless as trying to 
>  remember iptables commands, or AFS trivia back when I was 
>  a student--all cause me trouble just infrequently enough to 
>  ensure I have to relearn them from scratch every time. If 
>  I were a full-time sysadmin of course it would be a different 
>  story, but I really don't have the brain cycles to remember 
>  anything more complicated than chmod and chown, and I suspect 
>  a large number of accidental sysadmins feel the same. 
When introducing SELinux on computer where it wasn't before, it 
is mandatory to

touch /.autorelabel
reboot

Matěj

[Ed Swierk]

On 1/4/08, Matej Cepl <mcepl(a)redhat.com&gt; wrote:
>  When introducing SELinux on computer where it wasn't before, it
>  is mandatory to
>
>  touch /.autorelabel
>  reboot 
...and when copying files from another machine not running SELinux,
and when copying files from a machine running SELinux without using
funny tar/cp options.

--Ed

[Daniel J Walsh]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Ed Swierk wrote:
>  On 1/4/08, Matej Cepl <mcepl(a)redhat.com&gt; wrote:
> > When introducing SELinux on computer where it wasn't before, it
> > is mandatory to
> >
> > touch /.autorelabel
> > reboot
>  
>  ...and when copying files from another machine not running SELinux,
>  and when copying files from a machine running SELinux without using
>  funny tar/cp options.
>  
>  --Ed
>   
restorecon on the files is a better solution.

restorecon -R -v /etc

for example.
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.8 (GNU/Linux)
> Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
>
> iEYEARECAAYFAkeDaLUACgkQrlYvE4MpobPXSACdGFqSw4JygcXU3utwR/At9SUB
> wLgAoM7GV+8bfvrcZbbnjTxf8St+gBlC
> =EnwM
> -----END PGP SIGNATURE-----