Linux Archive

Linux Archive (http://www.linux-archive.org/)
-   Fedora Development (http://www.linux-archive.org/fedora-development/)
-   -   Another selinux rant (http://www.linux-archive.org/fedora-development/28120-another-selinux-rant.html)

Eric Paris 01-03-2008 08:36 PM

Another selinux rant
 
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
>

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

"Ed Swierk" 01-03-2008 08:49 PM

Another selinux rant
 
On 1/3/08, Eric Paris <eparis@redhat.com> 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

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

"Konstantin Ryabitsev" 01-03-2008 08:55 PM

Another selinux rant
 
On Jan 3, 2008 4:29 PM, Ed Swierk <eswierk@arastra.com> 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

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Ed Hill 01-03-2008 08:57 PM

Another selinux rant
 
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@eh3.com | http://eh3.com/
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Andrew Farris 01-04-2008 12:52 AM

Another selinux rant
 
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@gmail.com> <ajfarris@gmail.com>
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
---- ----

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

"Ed Swierk" 01-04-2008 01:33 AM

Another selinux rant
 
On 1/3/08, Andrew Farris <lordmorgul@gmail.com> 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

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Andrew Farris 01-04-2008 02:05 AM

Another selinux rant
 
Ed Swierk wrote:
> On 1/3/08, Andrew Farris <lordmorgul@gmail.com> 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@gmail.com> <ajfarris@gmail.com>
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
---- ----

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Tomasz Torcz 01-04-2008 07:22 AM

Another selinux rant
 
Dnia 03-01-2008, czw o godzinie 13:49 -0800, Ed Swierk pisze:
> On 1/3/08, Eric Paris <eparis@redhat.com> 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

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Patrice Dumas 01-04-2008 08:39 AM

Another selinux rant
 
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

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

"Ed Swierk" 01-04-2008 03:40 PM

Another selinux rant
 
On 1/4/08, Tomasz Torcz <tomek@crocom.com.pl> 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

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list


All times are GMT. The time now is 07:40 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.