Discussion:
SeLinux - is it worth it?
David Lloyd
2014-09-09 17:45:59 UTC
Permalink
Usually SeLinux stops me from doing what I intended to do and makes my systems UNUSABLE as opposed to SECURE.

If a system is UNUSABLE it is USELESS.

DISCUSS.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.linuxsa.org.au/pipermail/linuxsa/attachments/20140910/950a078e/attachment.html
Kim Hawtin
2014-09-09 21:11:54 UTC
Permalink
Post by David Lloyd
Usually SeLinux stops me from doing what I intended to do and makes my
systems UNUSABLE as opposed to SECURE.
If a system is *UNUSABLE**// *it is _USELESS_.
DISCUSS.
There is a sublte difference between trolling and ...

Oh what the hell, yes selinux is a PITA.

Its only really useful on systems that only do one thing and you can
spend the hours/days/months to tweak all the things that cause
exceptions. Setting everything with chattr, etc

There is also AppArmour on Ubuntu, same levels of headfsck. I moved to
Debian to avoid it.

Kim
Paul Shirren
2014-09-10 00:36:53 UTC
Permalink
Post by Kim Hawtin
Post by David Lloyd
Usually SeLinux stops me from doing what I intended to do and makes my
systems UNUSABLE as opposed to SECURE.
If a system is *UNUSABLE**// *it is _USELESS_.
DISCUSS.
There is a sublte difference between trolling and ...
Oh what the hell, yes selinux is a PITA.
I think these ACL/capabilities type systems are tackling things at the
wrong level for the average person. Far too much complexity to manage.

Jails/virtualisation seem much easier given the right tools to manage
them. "Hey lxc/docker/whatever, give me an instance of a base system.
Install my app. Deploy it."
Daniel Sobey
2014-09-10 03:14:53 UTC
Permalink
Selinux works when you have clear expectations on what a program should and
should not be able to do.

If you know that Apache stores all documents under /var/www, runs on port
80, can make a tcp connection to a database port you have a reasonable
chance of getting things right.
For things like samba where configuration is more flexible and you do want
to share a random folder it becomes more of a pain to work out how to tell
selinux that samba should be able to read these additional directories.

For android this makes perfect sense to have selinux running as each
application asks for permissions. Selinux can then be used to deny anything
that has not been requested and help protect against some operating system
bugs.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.linuxsa.org.au/pipermail/linuxsa/attachments/20140910/d9d27bf0/attachment.html
Peter Gossner
2014-09-09 22:23:10 UTC
Permalink
On Wed, 10 Sep 2014 03:15:59 +0930
Post by David Lloyd
Usually SeLinux stops me from doing what I intended to do and makes
my systems UNUSABLE as opposed to SECURE.
If a system is UNUSABLE it is USELESS.
DISCUSS.
I was going to say much the same as Kim.
Unusable != Secure. Pretty much grabs it.

Buying into the culture is also a pain.
AppArmor is also um unevenly approached.
I was under the impression that 'Buntu was walking slowly away from it..
but I'm usually wrong about that sort of thing)

Security is not a wallpaper.
Pasting it on is (self) delusional.
But hey it makes the folks feel better and has some real utility so why
not :)

(sorry my bad and jaded and pre caffeinated)

We do have choice.
You want a secure system drive a toaster.
Else plan on an invasion, even corrosion over time.


-- Pete <gossner at internode.on.net>
Wednesday 10 September 07:43:01 ACST 2014
As long as there are sovereign nations possessing great power,
war is inevitable.
--Albert Einstein "Einstein on the Atomic Bomb"
Andrew Galdes
2014-09-10 00:10:25 UTC
Permalink
My 2c.

If SELinux is an option, don't turn it off.

SELinux controls what a system can and cannot do regardless of the
application's intentions. EG, SELinux wont let something, say a rogue
proxy, use ports unexpectedly. It works in conjunction with other good
practices.

Also keep in mind that if you use the system and it's applications as
intended, you shouldn't have any issues. It's when you step outside of the
norm that you encounter strange goings-on. And even then, there are simple
ways to make exceptions. SELinux has come a long way and it's worth using.

I troubleshoot SELinux like this:

1. Turn SELinux on from the start. It's better to troubleshoot one thing
at a time rather than everything at the once at the end.
2. If something strange is happening (or not happening), turn SELinux
into Permissive mode and see if it still happens. This will tell you if
SELinux is involved.
3. If SELinux is involved, change back to Enforcing mode and check logs
for both the application experiencing the issue and the SELinux logs. You
need a few extra package for the SELinux tools available via YUM
(policycoreutils is one that i can remember right now).

Ta,


-Andrew Galdes
Managing Director

RHCE, LPI, CCENT

AGIX Linux

Ph: 08 7324 4429
Mb: 0422 927 598

Find us: Website <http://www.agix.com.au> | LinkedIn
<http://au.linkedin.com/in/andrewgaldes> | Blog <http://agix.com.au/blog> |
YouTube <http://www.youtube.com/user/andrewgaldes> | Google+
<http://google.com/+AndrewGaldes>



On Wed, Sep 10, 2014 at 7:53 AM, Peter Gossner <gossner at internode.on.net>
Post by Peter Gossner
On Wed, 10 Sep 2014 03:15:59 +0930
Post by David Lloyd
Usually SeLinux stops me from doing what I intended to do and makes
my systems UNUSABLE as opposed to SECURE.
If a system is UNUSABLE it is USELESS.
DISCUSS.
I was going to say much the same as Kim.
Unusable != Secure. Pretty much grabs it.
Buying into the culture is also a pain.
AppArmor is also um unevenly approached.
I was under the impression that 'Buntu was walking slowly away from it..
but I'm usually wrong about that sort of thing)
Security is not a wallpaper.
Pasting it on is (self) delusional.
But hey it makes the folks feel better and has some real utility so why
not :)
(sorry my bad and jaded and pre caffeinated)
We do have choice.
You want a secure system drive a toaster.
Else plan on an invasion, even corrosion over time.
-- Pete <gossner at internode.on.net>
Wednesday 10 September 07:43:01 ACST 2014
As long as there are sovereign nations possessing great power,
war is inevitable.
--Albert Einstein "Einstein on the Atomic Bomb"
--
LinuxSA WWW: http://www.linuxsa.org.au/ IRC: #linuxsa on irc.freenode.net
http://www.linuxsa.org.au/mailman/listinfo/linuxsa
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.linuxsa.org.au/pipermail/linuxsa/attachments/20140910/379d3cb8/attachment.html
Kim Hawtin
2014-09-10 06:45:11 UTC
Permalink
Post by Andrew Galdes
1. Turn SELinux on from the start. It's better to troubleshoot one
thing at a time rather than everything at the once at the end.
yep
Post by Andrew Galdes
2. If something strange is happening (or not happening), turn SELinux
into Permissive mode and see if it still happens. This will tell you
if SELinux is involved.
in permissive it generates enourmous logs of cruft you have to trawl
through. eventually you find the files it "can't" write to or similar and
Post by Andrew Galdes
3. If SELinux is involved, change back to Enforcing mode and check logs
for both the application experiencing the issue and the SELinux
logs. You need a few extra package for the SELinux tools available
via YUM (policycoreutils is one that i can remember right now).
rince, lather, repeat; 2,3, for ages and ages until it works or you give
up because $DEADLINES and turn it off and push it to production...

or move to a vm/chroot/jail/container model instead, with regular backups ;)

cheers,

Kim
Andrew Galdes
2014-09-10 07:03:01 UTC
Permalink
Post by Kim Hawtin
Post by Andrew Galdes
1. Turn SELinux on from the start. It's better to troubleshoot one
thing at a time rather than everything at the once at the end.
yep
Post by Andrew Galdes
2. If something strange is happening (or not happening), turn SELinux
into Permissive mode and see if it still happens. This will tell you
if SELinux is involved.
in permissive it generates enourmous logs of cruft you have to trawl
through. eventually you find the files it "can't" write to or similar and
Post by Andrew Galdes
3. If SELinux is involved, change back to Enforcing mode and check logs
for both the application experiencing the issue and the SELinux
logs. You need a few extra package for the SELinux tools available
via YUM (policycoreutils is one that i can remember right now).
rince, lather, repeat; 2,3, for ages and ages until it works or you give
up because $DEADLINES and turn it off and push it to production...
or move to a vm/chroot/jail/container model instead, with regular backups ;)
Fair enough, but...

The pros our way the cons. If it protects a client's server/data (or yours,
whoever) then it was 10 minutes well spent. Or an hour, whatever. I'd
rather say "I made every reasonable effort, followed industry
best-practices, etc... to protect against such things." than something like
"I didn't know how to use it so i turned it off.".

SELinux has cost me time and money on occasions but i know for a fact that
it's saved my bacon plenty of times over by being the fence the baddy
couldn't get over.

AG
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.linuxsa.org.au/pipermail/linuxsa/attachments/20140910/9a0cff49/attachment.html
Ant
2014-09-10 05:06:57 UTC
Permalink
In my current job there is a culture to use selinux where it makes
sense. Nearly all applications run on dedicated VMs, and with selinux
enabled.

Today in the RedHat world (maybe beyond) the default policy is targeted
and the provided default rules are good. You get a working system with
selinux enabled out of the box. Good place to start.

Most tools eg ls have a -Z flag to display selinux info. You need to be
aware that copying a file from one place to another does not update its
context to be correct for the new location, so it is advisable to be
mindful of moves and run restorecon on the destination path after moving
files around. restorecon will update selinux permissions that need to be
updated and report what was changed when in verbose mode.

Other than that, you can get most apps working by running the system in
permissive mode for testing or in production with real users hammering
it until you know the application has been solidly used. Then use tools
like audit2why to provide some clearer insight as to whats been logged
to the audit log (things which would have been blocked, but wernt) and
audit2allow to generate policies which will allow the behaviour
observed. Probably the rules wont be too complex and you can tweak by
hand if something looks too restrictive.

For example, a light weight monitoring cgi which runs under apache and
reports if a process is alive. This needs more access than apache has
out of the box. Without a deep understanding of selinux internals you
can make a policy and get it working with:

# disable enforcement of selinux so the app will run in full
[root at process01 ~]# setenforce 0

# check the existing context on new file(s)
[root at process01 ~]# ls -Z /var/www/cgi-bin/status.cgi
-rw-rw-r--. root root
unconfined_u:object_r:user_home_t:s0 /var/www/cgi-bin/status.cgi

# see if they are correct for the system, and fix if they arn't
[root at process01 ~]# restorecon -rv /var/www/cgi-bin/
restorecon reset /var/www/cgi-bin/status.cgi context
unconfined_u:object_r:user_home_t:s0->unconfined_u:object_r:httpd_sys_script_exec_t:s0

# optionally inspect he new context
[root at process01 ~]# ls -Z /var/www/cgi-bin/status.cgi
-rw-rw-r--. root root
unconfined_u:object_r:httpd_sys_script_exec_t:s0 /var/www/cgi-bin/status.cgi

#Use the app, make it do what it needs to, while gathering the denials

[root at process01 ~]# tail -f /var/log/audit/audit.log > denials

# have a look at what would have been denied:
[root at process01 ~]# audit2why < denials |grep denied
type=AVC msg=audit(1403496601.298:59710): avc: denied { getattr } for pid=13593 comm="appname" path="/var/run/appname.pid" dev=dm-2 ino=1249 scontext=unconfined_u:system_r:httpd_sys_script_t:s0 tcontext=unconfined_u:object_r:initrc_var_run_t:s0 tclass=file
type=AVC msg=audit(1403496601.298:59711): avc: denied { read } for pid=13593 comm="appname" name="appname.pid" dev=dm-2 ino=1249 scontext=unconfined_u:system_r:httpd_sys_script_t:s0 tcontext=unconfined_u:object_r:initrc_var_run_t:s0 tclass=file
type=AVC msg=audit(1403496601.298:59712): avc: denied { open } for pid=13593 comm="appname" name="appname.pid" dev=dm-2 ino=1249 scontext=unconfined_u:system_r:httpd_sys_script_t:s0 tcontext=unconfined_u:object_r:initrc_var_run_t:s0 tclass=file
type=AVC msg=audit(1403496601.298:59713): avc: denied { ioctl } for pid=13593 comm="appname" path="/var/run/appname.pid" dev=dm-2 ino=1249 scontext=unconfined_u:system_r:httpd_sys_script_t:s0 tcontext=unconfined_u:object_r:initrc_var_run_t:s0 tclass=file
type=AVC msg=audit(1403496601.298:59714): avc: denied { getattr } for pid=13593 comm="appname" path="/proc/21465" dev=proc ino=2347059 scontext=unconfined_u:system_r:httpd_sys_script_t:s0 tcontext=unconfined_u:system_r:initrc_t:s0 tclass=dir

# generate a policy with just enough access for this app:
[root at process01 ~]# audit2allow -M statusapp < denials

******************** IMPORTANT ***********************
To make this policy package active, execute:

semodule -i statusapp.pp

# inspect the rules
[root at process01 ~]# cat statusapp.te

module statusapp 1.0;

require {
type initrc_var_run_t;
type httpd_sys_script_t;
type initrc_t;
class dir getattr;
class file { read getattr open ioctl };
}

#============= httpd_sys_script_t ==============

#!!!! This avc is allowed in the current policy
allow httpd_sys_script_t initrc_t:dir getattr;

#!!!! This avc is allowed in the current policy
allow httpd_sys_script_t initrc_var_run_t:file { read getattr open ioctl };

# install the policy
[root at process01 ~]# semodule -i statusapp.pp

# re-enable enforcement, and retest the app
[root at process01 ~]# setenforce 1

# re-test the app, it should now work with no denials logged.

And for that you get the warm fuzzy feeling that your system is still locked down tight with an additional layer of defence.

Ant


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.linuxsa.org.au/pipermail/linuxsa/attachments/20140910/685aef22/attachment.html
Francesco Peeters
2014-09-10 06:40:04 UTC
Permalink
Post by Ant
In my current job there is a culture to use selinux where it makes
sense. Nearly all applications run on dedicated VMs, and with selinux
enabled.
Today in the RedHat world (maybe beyond) the default policy is
targeted and the provided default rules are good. You get a working
system with selinux enabled out of the box. Good place to start.
Most tools eg ls have a -Z flag to display selinux info. You need to
be aware that copying a file from one place to another does not update
its context to be correct for the new location, so it is advisable to
be mindful of moves and run restorecon on the destination path after
moving files around. restorecon will update selinux permissions that
need to be updated and report what was changed when in verbose mode.
Other than that, you can get most apps working by running the system
in permissive mode for testing or in production with real users
hammering it until you know the application has been solidly used.
Then use tools like audit2why to provide some clearer insight as to
whats been logged to the audit log (things which would have been
blocked, but wernt) and audit2allow to generate policies which will
allow the behaviour observed. Probably the rules wont be too complex
and you can tweak by hand if something looks too restrictive.
For example, a light weight monitoring cgi which runs under apache and
reports if a process is alive. This needs more access than apache has
out of the box. Without a deep understanding of selinux internals you
# disable enforcement of selinux so the app will run in full
[root at process01 <mailto:root at process01> ~]# setenforce 0
# check the existing context on new file(s)
[root at process01 <mailto:root at process01> ~]# ls -Z
/var/www/cgi-bin/status.cgi
-rw-rw-r--. root root unconfined_u:object_r:user_home_t:s0
/var/www/cgi-bin/status.cgi
# see if they are correct for the system, and fix if they arn't
[root at process01 <mailto:root at process01> ~]# restorecon -rv
/var/www/cgi-bin/
restorecon reset /var/www/cgi-bin/status.cgi context
unconfined_u:object_r:user_home_t:s0->unconfined_u:object_r:httpd_sys_script_exec_t:s0
# optionally inspect he new context
[root at process01 <mailto:root at process01> ~]# ls -Z
/var/www/cgi-bin/status.cgi
-rw-rw-r--. root root unconfined_u:object_r:httpd_sys_script_exec_t:s0
/var/www/cgi-bin/status.cgi
#Use the app, make it do what it needs to, while gathering the denials
[root at process01 <mailto:root at processing01> ~]# tail -f /var/log/audit/audit.log > denials
[root at process01 ~]# audit2why < denials |grep denied
type=AVC msg=audit(1403496601.298:59710): avc: denied { getattr } for pid=13593 comm="appname" path="/var/run/appname.pid" dev=dm-2 ino=1249 scontext=unconfined_u:system_r:httpd_sys_script_t:s0 tcontext=unconfined_u:object_r:initrc_var_run_t:s0 tclass=file
type=AVC msg=audit(1403496601.298:59711): avc: denied { read } for pid=13593 comm="appname" name="appname.pid" dev=dm-2 ino=1249 scontext=unconfined_u:system_r:httpd_sys_script_t:s0 tcontext=unconfined_u:object_r:initrc_var_run_t:s0 tclass=file
type=AVC msg=audit(1403496601.298:59712): avc: denied { open } for pid=13593 comm="appname" name="appname.pid" dev=dm-2 ino=1249 scontext=unconfined_u:system_r:httpd_sys_script_t:s0 tcontext=unconfined_u:object_r:initrc_var_run_t:s0 tclass=file
type=AVC msg=audit(1403496601.298:59713): avc: denied { ioctl } for pid=13593 comm="appname" path="/var/run/appname.pid" dev=dm-2 ino=1249 scontext=unconfined_u:system_r:httpd_sys_script_t:s0 tcontext=unconfined_u:object_r:initrc_var_run_t:s0 tclass=file
type=AVC msg=audit(1403496601.298:59714): avc: denied { getattr } for pid=13593 comm="appname" path="/proc/21465" dev=proc ino=2347059 scontext=unconfined_u:system_r:httpd_sys_script_t:s0 tcontext=unconfined_u:system_r:initrc_t:s0 tclass=dir
[root at process01 ~]# audit2allow -M statusapp < denials
******************** IMPORTANT ***********************
semodule -i statusapp.pp
# inspect the rules
[root at process01 <mailto:root at processing01> ~]# cat statusapp.te
module statusapp 1.0;
require {
type initrc_var_run_t;
type httpd_sys_script_t;
type initrc_t;
class dir getattr;
class file { read getattr open ioctl };
}
#============= httpd_sys_script_t ==============
#!!!! This avc is allowed in the current policy
allow httpd_sys_script_t initrc_t:dir getattr;
#!!!! This avc is allowed in the current policy
allow httpd_sys_script_t initrc_var_run_t:file { read getattr open ioctl };
# install the policy
[root at process01 <mailto:root at process01> ~]# semodule -i statusapp.pp
# re-enable enforcement, and retest the app
[root at process01 <mailto:root at process01> ~]# setenforce 1
# re-test the app, it should now work with no denials logged.
And for that you get the warm fuzzy feeling that your system is still locked down tight with an additional layer of defence.
Ant
As stated earlier: It's too complex for the average user! Your example
clearly demonstrates that, unfortunately... These things should be in a
single tool...

Start monitoring with a single command, e.g. "sepolicy monitor -start
statusapp"
After a while stop monitoring with (again) a single command, e.g.
"sepolicy monitor -stop statusapp"
It then comes up with something like:

"Observed activities which would have been denied:

{ getattr } for path="/var/run/appname.pid" dev=dm-2 ino=1249 scontext=unconfined_u:system_r:httpd_sys_script_t:s0 tcontext=unconfined_u:object_r:initrc_var_run_t:s0 tclass=file
{ read } for name="appname.pid" dev=dm-2 ino=1249 scontext=unconfined_u:system_r:httpd_sys_script_t:s0 tcontext=unconfined_u:object_r:initrc_var_run_t:s0 tclass=file
{ open } for name="appname.pid" dev=dm-2 ino=1249 scontext=unconfined_u:system_r:httpd_sys_script_t:s0 tcontext=unconfined_u:object_r:initrc_var_run_t:s0 tclass=file
{ ioctl } for path="/var/run/appname.pid" dev=dm-2 ino=1249 scontext=unconfined_u:system_r:httpd_sys_script_t:s0 tcontext=unconfined_u:object_r:initrc_var_run_t:s0 tclass=file
{ getattr } for path="/proc/21465" dev=proc ino=2347059 scontext=unconfined_u:system_r:httpd_sys_script_t:s0 tcontext=unconfined_u:system_r:initrc_t:s0 tclass=dir

Would you like to allow these activities? (Yes, No, Specify - Y/n/s):"

And that's it...

WHY is it so difficult for linux developers to think user-friendly? I'm
a geek and (ex-)programmer myself, but I always started with the desired
users experience, and would then try to get as close as possible while
doing the hard work under the covers... (But usually also provided
'expert' options...)
--
Francesco
Ant
2014-09-10 08:40:38 UTC
Permalink
Post by Francesco Peeters
As stated earlier: It's too complex for the average user! Your example
clearly demonstrates that, unfortunately... These things should be in a
single tool...
I agree.
Post by Francesco Peeters
Would you like to allow these activities? (Yes, No, Specify - Y/n/s):"
And that's it...
Well, to be fair, with my example the next step was to package the
policy file with the rest of the app in to an rpm so all the user needs
to do is "yum localinstall appname-1.0-1.rpm" and it pulls in the
dependencies, installs the lot and just works. If your building and
packaging an app the process does not stand out that much from makefiles
and other tools (maybe thats part of your point). Then theres always
places like linuxsa to ask. Someone might just post a howto for you ;)
Post by Francesco Peeters
WHY is it so difficult for linux developers to think user-friendly? I'm
a geek and (ex-)programmer myself, but I always started with the desired
users experience, and would then try to get as close as possible while
doing the hard work under the covers... (But usually also provided
'expert' options...)
I agree to some extent with this, but sometimes complex problems can not
be simplified as much as you'd like, especially if the concept is
evolving at the same time as the tools. If people are allready using
them you might not want to change the API as differences between
versions can create more complexity and problems. Perhaps there is room
for a higher level selinux tool to be created which wraps the process in
to what you suggested? This could happen without breaking other peoples
processes. Look at the major distros packaging systems for an example.
debian and redhat both have a low level tool from way back, wrapped with
a more modern higher level tool to improve the user friendlyness. You
can use one or the other or both depending how deep you need to go.
Perhaps there allready is a higher level tool for selinux? (I havnt
checked).

Ant
that_isridiculous
2014-09-10 11:12:33 UTC
Permalink
I'll add to that. One thing I don't enjoy about Linux is having to constantly enter sudo and a password to do certain things. It feels like a self punative act. Or when a permissions issue appears to be breakage.

One thing Netbsd does right is the same thing Lindows got right...make root the default user.

:p

J

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.linuxsa.org.au/pipermail/linuxsa/attachments/20140910/07d92bbb/attachment.html
Loading...