Hi,
i am the package maintainer of boomaga and users told me that there is a problem with access rights, when writing to ~/.cache directory. A selinux package already exists for testing in: https://martinkg.fedorapeople.org/Review/test/boomaga/ And a bugzilla bug report also exists: https://bugzilla.redhat.com/show_bug.cgi?id=1409115 Bugreport on the boomaga developer site: https://github.com/Boomaga/boomaga/issues/43
Can someone help to write the correct selinux rules ?
On 01/03/2017 11:53 AM, Martin Gansser wrote:
Hi,
i am the package maintainer of boomaga and users told me that there is a problem with access rights, when writing to ~/.cache directory. A selinux package already exists for testing in: https://martinkg.fedorapeople.org/Review/test/boomaga/ And a bugzilla bug report also exists: https://bugzilla.redhat.com/show_bug.cgi?id=1409115 Bugreport on the boomaga developer site: https://github.com/Boomaga/boomaga/issues/43
Can someone help to write the correct selinux rules ?
Well, rpms are not suppose to touch anything below $HOME at all.
I.e. $HOME rsp. ~/ is out of rpm's (and SELinux's) business
If packages requires special treatment of such files, this probabyl means they are suffering from mal-design or are broken (in the sense of them doing something "illegal").
Ralf
On Tuesday, 03 January 2017 at 13:18, Ralf Corsepius wrote:
On 01/03/2017 11:53 AM, Martin Gansser wrote:
i am the package maintainer of boomaga and users told me that there is a problem with access rights, when writing to ~/.cache directory. A selinux package already exists for testing in: https://martinkg.fedorapeople.org/Review/test/boomaga/ And a bugzilla bug report also exists: https://bugzilla.redhat.com/show_bug.cgi?id=1409115 Bugreport on the boomaga developer site: https://github.com/Boomaga/boomaga/issues/43
Can someone help to write the correct selinux rules ?
Well, rpms are not suppose to touch anything below $HOME at all.
I.e. $HOME rsp. ~/ is out of rpm's (and SELinux's) business
While the above is correct for rpm, SELinux does have business in protecting $HOME. Just run ls -lZ in your home directory and see for yourself. For example, ~/public_html has httpd_user_content_t context, ~/bin has home_bin_t, ~/.config has config_home_t, etc.
In this particular case, ~/.cache has cache_home_t context, so the application needs a policy update to have write access to that context. You should be able to create a policy semi-automatically using audit2allow when running in permissive mode.
Regards, Dominik
On 01/03/2017 01:33 PM, Dominik 'Rathann' Mierzejewski wrote:
On Tuesday, 03 January 2017 at 13:18, Ralf Corsepius wrote:
On 01/03/2017 11:53 AM, Martin Gansser wrote:
i am the package maintainer of boomaga and users told me that there is a problem with access rights, when writing to ~/.cache directory. A selinux package already exists for testing in: https://martinkg.fedorapeople.org/Review/test/boomaga/ And a bugzilla bug report also exists: https://bugzilla.redhat.com/show_bug.cgi?id=1409115 Bugreport on the boomaga developer site: https://github.com/Boomaga/boomaga/issues/43
Can someone help to write the correct selinux rules ?
Well, rpms are not suppose to touch anything below $HOME at all.
I.e. $HOME rsp. ~/ is out of rpm's (and SELinux's) business
While the above is correct for rpm, SELinux does have business in protecting $HOME. Just run ls -lZ in your home directory and see for yourself. For example, ~/public_html has httpd_user_content_t context, ~/bin has home_bin_t, ~/.config has config_home_t, etc.
Jikes, what a messy design!
People seem to have forgotten that homes are completely out of a distro's control. They are not guaranteed to be on a local filesystem or on an SELinux-enabled filesystem and are not standardized by any standard ....
Ralf
On Jan 3, 2017 8:00 AM, "Ralf Corsepius" rc040203@freenet.de wrote:
On 01/03/2017 01:33 PM, Dominik 'Rathann' Mierzejewski wrote:
On Tuesday, 03 January 2017 at 13:18, Ralf Corsepius wrote:
On 01/03/2017 11:53 AM, Martin Gansser wrote:
i am the package maintainer of boomaga and users told me that there is a problem with access rights, when writing to ~/.cache directory. A selinux package already exists for testing in: https://martinkg.fedorapeople.org/Review/test/boomaga/ And a bugzilla bug report also exists: https://bugzilla.redhat.com/sh ow_bug.cgi?id=1409115 Bugreport on the boomaga developer site: https://github.com/Boomaga/boo maga/issues/43
Can someone help to write the correct selinux rules ?
Well, rpms are not suppose to touch anything below $HOME at all.
I.e. $HOME rsp. ~/ is out of rpm's (and SELinux's) business
While the above is correct for rpm, SELinux does have business in protecting $HOME. Just run ls -lZ in your home directory and see for yourself. For example, ~/public_html has httpd_user_content_t context, ~/bin has home_bin_t, ~/.config has config_home_t, etc.
Jikes, what a messy design!
People seem to have forgotten that homes are completely out of a distro's control. They are not guaranteed to be on a local filesystem or on an SELinux-enabled filesystem and are not standardized by any standard ....
Not really, there are standards and conventions for how apps store user specific settings inside the user's home directory. It's not even distro specific.
With respect to non-SELinux enabled filesystem, they are not affected by these policies. But if the filesystem is SELinux enabled then having the distro specific policy is important.
"RC" == Ralf Corsepius rc040203@freenet.de writes:
RC> People seem to have forgotten that homes are completely out of a RC> distro's control. They are not guaranteed to be on a local RC> filesystem or on an SELinux-enabled filesystem and are not RC> standardized by any standard ....
Hence the use_*_home_dirs booleans.
It's certainly a great idea to provide a security model where the home directory can be protected. It's also a great idea to provide a knob to turn that off. Fortunately we have both.
Also, with NFSv4.2, selinux works across an NFS mount. Which was quite a surprise when RHEL7.3 turned it on by default, but now I have selinux labeling for home directories across NFS. That's useful for a relatively narrow range of situations but, again, it's something you can disable.
- J<