selinux May 2018

selinux@lists.fedoraproject.org

17 participants
14 discussions

C 7, selinux, and rpc.gssd
by m.roth＠5-cent.us 17 May '18

17 May '18

Folks, As systems are upgraded, we're getting a ton of complaints (fortunately, we're in permissive mode) that would break everything. All of them involve rpc.gssd, and I see a number of bugs listed when I search. Note that I first saw this on a RHEL system, but now I'm seeing it on CentOS 7. I'm bringing it up here, because, given that there are multiple reported, that there's some bigger picture involving policy and rpc.gssd. I'll note that some of the reported bugs were *closed last year, or before, so it seems to me an old issue resurfaced. Example. SELinux is preventing /usr/sbin/rpc.gssd from using the block_suspend capability. mark

2 1

The right way to deal with in-house development
by m.roth＠5-cent.us 16 May '18

16 May '18

Ok, what's the "correct" way to deal with systems developed in-house, that have their own sets up subdirectories. And why, for that matter, does running sealert give me the full path to the executable, like openjdk... but *not* the full path to the file it's trying to operate on, and I'm left going "ok, where was the file it deleted? (we're running in permissive mode - overwhelmingly, developers and subject matter experts no less than nothing about selinux). mark

5 5

Re: Packaging policycoreutils for OpenSUSE
by Stephen Smalley 14 May '18

14 May '18

On 05/13/2018 07:43 AM, Nicolas Iooss wrote: > On Sat, May 12, 2018 at 2:53 PM, Matěj Cepl <mcepl(a)cepl.eu> wrote: >> Hi, >> >> I am changing jobs (Red Hat -> SUSE; R&D, but not a security >> related job), and although I will be switching my workstation to >> OpenSUSE, I would love to keep SELinux working. Which meant I had >> to dig into the current situation of SELinux and it is … not >> good. So, I started to repackage all SELinux packages 2.7 for >> OpenSUSE in my home build area >> https://build.opensuse.org/project/show/home:mcepl:SELinux >> . So,far I have packaged successfully packages for libselinux, >> libselinux-bindings, checkpolicy, libsemanage, libsepol, and >> python-semanage. Mostly I use original OpenSUSE packages for 2.6, >> but if needed I seek inspiration in Fedora packages. >> >> Unfortunately, I have trouble to package policycoreutils. First >> of all, I don’t understand what’s the difference between two >> upstream tarballs for it: >> https://github.com/SELinuxProject/selinux/archive/policycoreutils >> -2.7.tar.gz >> (linked from https://github.com/SELinuxProject/selinux/releases) >> and >> https://raw.githubusercontent.com/wiki/SELinuxProject/selinux/fil >> es/releases/20170804/policycoreutils-2.7.tar.gz >> (linked from >> https://github.com/SELinuxProject/selinux/wiki/Releases). What’s >> the point of confusing users with two different tarballs of the >> same name? >> >> Second, I don’t understand the behavior of the installation >> scripts. Looking at https://is.gd/MivaE1 , why in the world that >> installation scripts tons of stuff which is not part of >> policycoreutils? Could anybody help me to get through this >> obstacle, please? >> >> Thank you for any suggestions, >> >> Matěj > > Hi, > After we have discussed about it on IRC (#selinux on freenode), I have > performed some tests on Github to better understand how its "Releases > page" work. The main issue here is that Github shows tags of the git > repository in the Releases page > (https://github.com/SELinuxProject/selinux/releases) and there is no > way to disabled this behavior. This has several consequences: > > * Each tarball in https://github.com/SELinuxProject/selinux/releases > contains the full tree of the project (which is why "that installation > scripts tons of stuff which is not part of policycoreutils"), whereas > the tarballs in the wiki page are created by properly splitting the > subdirectories. > * It is not possible to delete what is currently in Github's release > page without deleting the tags. > * It is possible to "upgrade" a tag to a release by adding release > notes and files to them. For example > https://github.com/gentilkiwi/mimikatz/releases uses this (you can see > the differences between "Releases" and "Tags" pages of this project). > When there are releases like this, it is possible to remove them all > (for example using > https://github.com/stevemao/github-remove-all-releases), which > transforms the release page back to a list of tags (I have tested this > today on a test repository). > > Moreover it seems that the Releases page can not be disabled (if it > can, I have not found how). > > If my analysis of Github's release system is correct, would it make > sense to change the way the releases are currently tagged to only > create one tag (like "selinux-2.8-rc3") instead of creating one tag > per sub-project? Would this break some tools? (If distribution > packagers use tools to automatically detect when a new release is > available, would such a change break these tools?) Not speaking for the distributions obviously, but I have no objection to dropping the per-component tags if they aren't being used and are causing confusion. A bit of historical context: originally, we released the selinux userspace as a single tarball with a single date-based version. When SELinux was first being integrated into Fedora, the Fedora packagers wanted releases to be split into separate source tarballs for each component each with its own independent version, so this was done for formal releases but the source continued to live in a single source code repository. (This all predates the move to GitHub, of course). The individual component versioning has limited utility in my view given that there is almost always at least one source level change to every component between any two releases and there tends to be a strong coupling among many of the components. In the past, we have considered either going back to a single source tarball with a single version, or splitting the source code repository itself to be per-component. Either approach would allow direct use of the github releases as the official release mechanism and avoid the need to separately create and maintain the release tarballs on the wiki pages.

1 0

Packaging policycoreutils for OpenSUSE
by Matěj Cepl 12 May '18

12 May '18

Hi, I am changing jobs (Red Hat -> SUSE; R&D, but not a security related job), and although I will be switching my workstation to OpenSUSE, I would love to keep SELinux working. Which meant I had to dig into the current situation of SELinux and it is … not good. So, I started to repackage all SELinux packages 2.7 for OpenSUSE in my home build area https://build.opensuse.org/project/show/home:mcepl:SELinux . So,far I have packaged successfully packages for libselinux, libselinux-bindings, checkpolicy, libsemanage, libsepol, and python-semanage. Mostly I use original OpenSUSE packages for 2.6, but if needed I seek inspiration in Fedora packages. Unfortunately, I have trouble to package policycoreutils. First of all, I don’t understand what’s the difference between two upstream tarballs for it: https://github.com/SELinuxProject/selinux/archive/policycoreutils -2.7.tar.gz (linked from https://github.com/SELinuxProject/selinux/releases) and https://raw.githubusercontent.com/wiki/SELinuxProject/selinux/fil es/releases/20170804/policycoreutils-2.7.tar.gz (linked from https://github.com/SELinuxProject/selinux/wiki/Releases). What’s the point of confusing users with two different tarballs of the same name? Second, I don’t understand the behavior of the installation scripts. Looking at https://is.gd/MivaE1 , why in the world that installation scripts tons of stuff which is not part of policycoreutils? Could anybody help me to get through this obstacle, please? Thank you for any suggestions, Matěj -- https://matej.ceplovi.cz/blog/, Jabber: mcepl(a)ceplovi.cz GPG Finger: 3C76 A027 CA45 AD70 98B5 BC1D 7920 5802 880B C9D8 A GOOD name is rather to be chosen than great riches. -- Proverbs 22:1

2 1

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

selinux May 2018