Hi,
how do I allow exim access to a socket in order to be able to do local deliveries to cyrus?
type=AVC msg=audit(1521179280.845:1920270): avc: denied { name_connect } for pid=319 comm="exim" dest=24 scontext=system_u:system_r:exim_t:s0 tcontext=system_u:object_r:lmtp_port_t:s0 tclass=tcp_socket
Yet again I could not find any documentation explaining how to do basic things like this :( Selinux is more like a curse than anything else :( Why is there not even a good documentation?
On 03/16/2018 12:14 PM, Richard Grainger wrote:
Yet again I could not find any documentation explaining how to do basic things like this :( Selinux is more like a curse than anything else :( Why is there not even a good documentation?
More trolling?
Show me a good documentation and/or name good reasons not to disable selinux. Considering how much trouble it gives, there have to be *very* good reasons to keep it enabled.
Am 16.03.2018 um 13:09 schrieb hw:
On 03/16/2018 12:14 PM, Richard Grainger wrote:
Yet again I could not find any documentation explaining how to do basic things like this :( Selinux is more like a curse than anything else :( Why is there not even a good documentation?
More trolling?
Show me a good documentation and/or name good reasons not to disable selinux. Considering how much trouble it gives, there have to be *very* good reasons to keep it enabled.
Useful resources for SELinux:
http://wiki.centos.org/HowTos/SELinux
http://wiki.centos.org/TipsAndTricks/SelinuxBooleans
http://docs.fedoraproject.org/en-US/Fedora/13/html/Security-Enhanced_Linux/
http://www.youtube.com/watch?v=bQqX3RWn0Yw
http://opensource.com/business/13/11/selinux-policy-guide
Alexander
On 16/03/18 18:37, Alexander Dalloz wrote:
Am 16.03.2018 um 13:09 schrieb hw:
On 03/16/2018 12:14 PM, Richard Grainger wrote:
Yet again I could not find any documentation explaining how to do basic things like this :( Selinux is more like a curse than anything else :( Why is there not even a good documentation?
More trolling?
Show me a good documentation and/or name good reasons not to disable selinux. Considering how much trouble it gives, there have to be *very* good reasons to keep it enabled.
Would you turn off your firewall because you don't understand how it works? Or any security feature for that matter?
Invest a few hours of your life reading the documentation. There are plenty of good examples listed below.
I've never had an SELinux problem I couldn't solve or work around in 2 minutes. Sometimes figuring out the *right* solution might take a little longer, but turning it off is very rarely going to be the right solution.
Useful resources for SELinux:
http://wiki.centos.org/HowTos/SELinux
http://wiki.centos.org/TipsAndTricks/SelinuxBooleans
http://docs.fedoraproject.org/en-US/Fedora/13/html/Security-Enhanced_Linux/
https://lists.centos.org/mailman/listinfo/centos
and don't forget the definitive Red Hat documentation here:
https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/
SELinux User's and Administrator's Guide at the bottom of the page. Download it and read it.
On 03/16/2018 10:38 PM, Phil Perry wrote:
On 16/03/18 18:37, Alexander Dalloz wrote:
Am 16.03.2018 um 13:09 schrieb hw:
On 03/16/2018 12:14 PM, Richard Grainger wrote:
Yet again I could not find any documentation explaining how to do basic things like this :( Selinux is more like a curse than anything else :( Why is there not even a good documentation?
More trolling?
Show me a good documentation and/or name good reasons not to disable selinux. Considering how much trouble it gives, there have to be *very* good reasons to keep it enabled.
Would you turn off your firewall because you don't understand how it works? Or any security feature for that matter?
That depends. If the anti-theft system of your car prevents you from driving it, wouldn´t you turn it off so you can drive to work?
Invest a few hours of your life reading the documentation. There are plenty of good examples listed below.
You can´t read documentation when you can´t find it.
I've never had an SELinux problem I couldn't solve or work around in 2 minutes. Sometimes figuring out the *right* solution might take a little longer, but turning it off is very rarely going to be the right solution.
I don´t believe that. First you need to figure out if it´s a selinux related thing, and to do that, you need to figure out how to figure that out. Once you figured it out, you need to figure out how to solve it. That usually takes hours or even days.
Useful resources for SELinux:
http://wiki.centos.org/HowTos/SELinux
http://wiki.centos.org/TipsAndTricks/SelinuxBooleans
http://docs.fedoraproject.org/en-US/Fedora/13/html/Security-Enhanced_Linux/
I´ve seen some of those, finding a hint here and there, but not a really good documentation yet.
and don't forget the definitive Red Hat documentation here:
https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/
SELinux User's and Administrator's Guide at the bottom of the page. Download it and read it.
That looks promising, though it seems to make quite a hype of it. It even says wrong things, like: Mandatory access control "enables information to be protected from legitimate users with limited authorization as well as from authorized users who have unwittingly executed malicious applications."[1] Perhaps there are implementations of MAC which do that; selinux does not. It´s even a thing I´ve asked about quite a while ago, and there didn´t seem to be a way to achieve it with selinux.
So what do you really gain from selinux, and is that worthwhile all the trouble and the hours spent to fix the problems it creates? What about the impact on performance?
[1]: https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/htm...
On Tue, 20 Mar 2018, hw wrote:
That depends. If the anti-theft system of your car prevents you from driving it, wouldn´t you turn it off so you can drive to work?
How many of us tape the immobiliser transponder to the base of the lock?
I don´t believe that. First you need to figure out if it´s a selinux related thing, and to do that, you need to figure out how to figure that out. Once you figured it out, you need to figure out how to solve it. That usually takes hours or even days.
If you don't learn how to use SELinux, it takes ages to solve anything. If you learn it, it takes a short while to get things working, and a little longer to configure things as you want. When was security supposed to be zero cost? I'm not sure when I last spent an hour solving an SELinux issue, and I'm not claiming to be highly proficient.
That looks promising, though it seems to make quite a hype of it. It even says wrong things, like: Mandatory access control "enables information to be protected from legitimate users with limited authorization as well as from authorized users who have unwittingly executed malicious applications."[1]
Perhaps there are implementations of MAC which do that; selinux does not. It´s even a thing I´ve asked about quite a while ago, and there didn´t seem to be a way to achieve it with selinux.
When you confine an unconfined process, is that not what you're doing?
What is it you're trying to do that you believe SELinux can't do?
So what do you really gain from selinux, and is that worthwhile all the trouble and the hours spent to fix the problems it creates? What about the impact on performance?
In the general case, you'd struggle to point your finger convincingly at the SELinux performance hit. Probably the worst performance hit you're likely to see is with a badly configured permissive configuration, due to excessive logging.
jh
On Tue, 20 Mar 2018 13:07:12 +0100 hw hw@gc-24.de wrote:
...
So what do you really gain from selinux, and is that worthwhile all the trouble and the hours spent to fix the problems it creates? What about the impact on performance?
The main feature is that lots of software is indeed confined (even though your normal login or desktop remains unconfined).
This is exactly what happens to exim in your case. It is exim_t not unconfined_t which means when/if it goes crazy (or is exploited) the damage can be limited.
For some people it's also useful that it provides the ability to define user types (see "semanage user --list").
/Peter K
On 03/20/2018 01:42 PM, Peter Kjellström wrote:
On Tue, 20 Mar 2018 13:07:12 +0100 hw hw@gc-24.de wrote:
...
So what do you really gain from selinux, and is that worthwhile all the trouble and the hours spent to fix the problems it creates? What about the impact on performance?
The main feature is that lots of software is indeed confined (even though your normal login or desktop remains unconfined).
This is exactly what happens to exim in your case. It is exim_t not unconfined_t which means when/if it goes crazy (or is exploited) the damage can be limited.
which is what access rights are for
For some people it's also useful that it provides the ability to define user types (see "semanage user --list").
How is this useful? It makes things much more complicated and more unmanageable.
It still doesn´t allow me as a user to make it so that a program I´m running can only access the files I want it to access. Why isn´t that a common thing for users to do? Gimp doesn´t need to have access to my emails and fvwm doesn´t need to access anything but it´s configuration, etc.. Since those are common things, why doesn´t selinux do it --- and in such a way that it is easy to manage?
On Tue, 20 Mar 2018, hw wrote:
which is what access rights are for
Yes and no. You can run firefox and let it download files into the Downloads directory, but not elsewhere. You can run apache on port 80/443 but not let it open up a different port. You can stop apache reading files outside of its webroot even though they're readable by all users.
You can't do all that with simple file permissions.
It still doesn´t allow me as a user to make it so that a program I´m running can only access the files I want it to access. Why isn´t that a common thing for users to do? Gimp doesn´t need to have access to my emails and fvwm doesn´t need to access anything but it´s configuration, etc.. Since those are common things, why doesn´t selinux do it --- and in such a way that it is easy to manage?
You want a *user* to be able to confine applications in this way, not an administrator?
jh
Am 16.03.2018 um 13:09 schrieb hw hw@gc-24.de:
On 03/16/2018 12:14 PM, Richard Grainger wrote:
Yet again I could not find any documentation explaining how to do basic things like this :( Selinux is more like a curse than anything else :( Why is there not even a good documentation?
More trolling?
Show me a good documentation and/or name good reasons not to disable selinux. Considering how much trouble it gives, there have to be *very* good reasons to keep it enabled.
$ rpm -q --qf "%{URL}\n" libselinux
-- LF
-
Alexander Dalloz -
hw -
John Hodrien -
Leon Fauster -
Peter Kjellström -
Phil Perry -
Richard Grainger