<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=Windows-1252">
</head>
<body>
<div dir="ltr">
<div></div>
<div>
<div>
<div dir="ltr">
<div dir="ltr" style="color: rgb(0, 0, 0); background-color: rgb(255, 255, 255);">
Hello Matthias,</div>
<div dir="ltr" style="color: rgb(0, 0, 0); background-color: rgb(255, 255, 255);">
<br>
</div>
<div dir="ltr" style="color: rgb(0, 0, 0); background-color: rgb(255, 255, 255);">
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.</div>
<div dir="ltr" style="color: rgb(0, 0, 0); background-color: rgb(255, 255, 255);">
<br>
</div>
<div dir="ltr" style="color: rgb(0, 0, 0); background-color: rgb(255, 255, 255);">
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.</div>
<div dir="ltr" style="color: rgb(0, 0, 0); background-color: rgb(255, 255, 255);">
<br>
</div>
<div dir="ltr" style="color: rgb(0, 0, 0); background-color: rgb(255, 255, 255);">
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)</div>
<div dir="ltr" style="color: rgb(0, 0, 0); background-color: rgb(255, 255, 255);">
<br>
</div>
<div dir="ltr" style="color: rgb(0, 0, 0); background-color: rgb(255, 255, 255);">
Having said that, I would actually prefer if you don’t support SELinux since it’s less testing and documenting for me ,)</div>
<div dir="ltr" style="color: rgb(0, 0, 0); background-color: rgb(255, 255, 255);">
</div>
<div dir="ltr" style="color: rgb(0, 0, 0); background-color: rgb(255, 255, 255);">
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).</div>
<div dir="ltr" style="color: rgb(0, 0, 0); background-color: rgb(255, 255, 255);">
<br>
</div>
<div dir="ltr" style="color: rgb(0, 0, 0); background-color: rgb(255, 255, 255);">
Gruss</div>
<div dir="ltr" style="color: rgb(0, 0, 0); background-color: rgb(255, 255, 255);">
Bernd</div>
</div>
</div>
<div><br>
</div>
<div class="ms-outlook-ios-signature">
<div><br>
</div>
<div style="direction: ltr;">-- </div>
<div style="direction: ltr;">http://bernd.eckenfels.net</div>
</div>
</div>
</div>
<hr style="display:inline-block;width:98%" tabindex="-1">
<div id="divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif" style="font-size:11pt" color="#000000"><b>Von:</b> Matthias G. Eckermann <mge@suse.com><br>
<b>Gesendet:</b> Sunday, May 16, 2021 10:51:23 PM<br>
<b>An:</b> Bernd Eckenfels <ecki@zusammenkunft.net>; sle-beta@lists.suse.com <sle-beta@lists.suse.com>; Neal Gompa <ngompa13@gmail.com>; Thorsten Kukuk <kukuk@suse.de><br>
<b>Betreff:</b> Re: 15.3 PRC: SE Linux Policy loading failed</font>
<div> </div>
</div>
<div class="BodyFragment"><font size="2"><span style="font-size:11pt;">
<div class="PlainText">Hello Bernd, Neal, and all,<br>
<br>
On 2021-05-16 T 18:09 +0000 Bernd Eckenfels wrote:<br>
<br>
> The aproperiate answer to somebody giving you his spare time to test<br>
> your beta product is not „you wrote my version number wrong“ but the<br>
> correct answer is „thank you“. <br>
<br>
agreed, and indeed we highly appreciate the time and efforts you are<br>
investing to contribute to the quality of our products.<br>
<br>
In that context we are also noticing that SELinux becomes more<br>
relevant, specifically for the use case of container isolation. That's<br>
why we support the SELinux stack in SUSE Linux Enterprise as a<br>
platform, and an SELinux policy for SUSE Linux Enterprise Micro 5.0.<br>
<br>
That said, and if your use case is different from container isolation,<br>
Bernd, I'd appreciate a use case description, either publically or<br>
privately (mge@suse.com) at your choice.<br>
<br>
> Anyway, this report is about the latest/only beta candidate of SLES<br>
> which is currently available, as my original Mail clearly stated.<br>
<br>
On 2021-05-16 T 14:21 -0400 Neal Gompa wrote:<br>
<br>
> While it is not commonly referenced that way in SUSE marketing, it<br>
> is accurate to call SUSE Linux Enterprise 15 SP3 as SUSE Linux<br>
> Enterprise 15.3.<br>
<br>
I am afraid, Neal, it is not: as you have seen in this case, referring<br>
to "15.3" most SUSE employees will connect to openSUSE Leap, while for<br>
SUSE Linux Enterprise we are only talking about "15 SP3", and this is<br>
an explicit decision, and followed through very thoroughly.<br>
<br>
Thus I recommend to stick to the "SPx" naming to avoid confusion, for<br>
SUSE Linux Enterprise 12 and 15 products.<br>
<br>
> After all, the machine-parseable name VERSION_ID value is set to<br>
> "15.3" because it's *sane* to handle it that way.<br>
<br>
<nitpick><br>
As you say, "machine-parseable", thus for machines, not for human<br>
beings. <br>
</nitpick><br>
<br>
However, ...<br>
<br>
> I personally wish we'd stop using the "service pack" terminology as<br>
> it's effectively pointless.<br>
<br>
... I do not disagree that re-visiting the naming scheme for new<br>
products is a good idea, and part of our work in product management.<br>
Hint: it is called SUSE Linux Enterprise Micro 5.0 :-)<br>
<br>
So long -<br>
MgE<br>
<br>
-- <br>
Matthias G. Eckermann, Head of Product Management Linux Platforms<br>
SUSE Software Solutions Germany GmbH - Maxfeldstr. 5 - 90409 Nürnberg <br>
(HRB 36809, AG Nürnberg) Geschäftsführer: Felix Imendörffer<br>
</div>
</span></font></div>
</body>
</html>