15.3 PRC: SE Linux Policy loading failed

[Bernd Eckenfels]

Hello Matthias,

I actually don’t have a usecase for SELinux, but in the past (not sure if this was only by customers of the other enterprise Linux) we had customer ask for compatibility with SELinux as a general hardening mechanism on their machines.

So we do not ship a policy with our software since it is a pain to maintain, especially for multiple target platforms (and rhe interest is low). However when I do testing of operating systems and I see that they support hardening settings like SELinux, AppArmor, FIPS or the „paranoid file permissions“ Settings I do test them so we can document how to run on such environments (like with unconfined app user). That’s why I tried out the installer setting.

This might change for containers, where it is a bit easier to control the required policies, but I don’t have concrete plans yet. (I will look at SLE Micro separately)

Having said that, I would actually prefer if you don’t support SELinux since it’s less testing and documenting for me ,)

I did not yet had a look at the GMC but I suspect it doesn’t have much differences for my tests. (Still needing a solution for my sftp problem mentioned in the other mail).

Gruss
Bernd


--
http://bernd.eckenfels.net
________________________________
Von: Matthias G. Eckermann <mge at suse.com>
Gesendet: Sunday, May 16, 2021 10:51:23 PM
An: Bernd Eckenfels <ecki at zusammenkunft.net>; sle-beta at lists.suse.com <sle-beta at lists.suse.com>; Neal Gompa <ngompa13 at gmail.com>; Thorsten Kukuk <kukuk at suse.de>
Betreff: Re: 15.3 PRC: SE Linux Policy loading failed

Hello Bernd, Neal, and all,

On 2021-05-16 T 18:09 +0000 Bernd Eckenfels wrote:

> The aproperiate answer to somebody giving you his spare time to test
> your beta product is not „you wrote my version number wrong“ but the
> correct answer is „thank you“.

agreed, and indeed we highly appreciate the time and efforts you are
investing to contribute to the quality of our products.

In that context we are also noticing that SELinux becomes more
relevant, specifically for the use case of container isolation. That's
why we support the SELinux stack in SUSE Linux Enterprise as a
platform, and an SELinux policy for SUSE Linux Enterprise Micro 5.0.

That said, and if your use case is different from container isolation,
Bernd, I'd appreciate a use case description, either publically or
privately (mge at suse.com) at your choice.

> Anyway, this report is about the latest/only beta candidate of SLES
> which is currently available, as my original Mail clearly stated.

On 2021-05-16 T 14:21 -0400 Neal Gompa wrote:

> While it is not commonly referenced that way in SUSE marketing, it
> is accurate to call SUSE Linux Enterprise 15 SP3 as SUSE Linux
> Enterprise 15.3.

I am afraid, Neal, it is not: as you have seen in this case, referring
to "15.3" most SUSE employees will connect to openSUSE Leap, while for
SUSE Linux Enterprise we are only talking about "15 SP3", and this is
an explicit decision, and followed through very thoroughly.

Thus I recommend to stick to the "SPx" naming to avoid confusion, for
SUSE Linux Enterprise 12 and 15 products.

> After all, the machine-parseable name VERSION_ID value is set to
> "15.3" because it's *sane* to handle it that way.

<nitpick>
As you say, "machine-parseable", thus for machines, not for human
beings.
</nitpick>

However, ...

> I personally wish we'd stop using the "service pack" terminology as
> it's effectively pointless.

... I do not disagree that re-visiting the naming scheme for new
products is a good idea, and part of our work in product management.
Hint: it is called SUSE Linux Enterprise Micro 5.0 :-)

So long -
        MgE

--
Matthias G. Eckermann,     Head of Product Management Linux Platforms
SUSE Software Solutions Germany GmbH - Maxfeldstr. 5 - 90409 Nürnberg
(HRB 36809, AG Nürnberg)           Geschäftsführer: Felix Imendörffer
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.suse.com/pipermail/sle-beta/attachments/20210517/52b8bf9f/attachment.htm>