[lsb-discuss] LSB and SELinux

[Alan Cox]

> So I don't have very good network connectivity at the moment (cruise
> ship in the middle of the Mediterranean, actually), so I can't really

Oh you have my sympathy ;)

> google search on this ---- but what specifically do you mean by text
> relocation that breaks in the presence of SELinux being enabled?  I'm
> not aware of any such issue.

SELinux policies generally set the default protections to stop binaries
self patching. Thats normally a very good security decision, but one or
two apps do internal relocation stuff.

> enabled in its full "enforcing" mode, that most application will break
> until someone spends a huge amount of time trying to craft an SELinux
> policy --- which most SELinux proponents will first try to deny is
> difficult, and then when it is shown that configuring sendmail.cf

Oh yes .. its so mindnumbingly complicated ....

	# Mark the library allowed to do textrel
	chcon -t textrel_shlib_t $$
	# Update the database so relabels will preserve this
	semanage fcontext -a -t textrel_shlib_t $$

I wish sendmail.cf was so easy ;)

> files are easier, will admit that well, they is some interesting work
> in making meta-policy configuration tools to create SELinux policies,
> but it's all a research problem right now.... to which the responsec

I don't believe thats true. The one bit that is currently (enterprise
distro at least) hard is shipping additional policy items with a piece of
software. Thats hard because the tools on the enterprise products aren't
set up that way and doubly so as the LSB has nothing to say on how you do
this. You can ship with the right labels and use semanage in %pre/%post
scripts but thats not elegant.

> has been that most ISV's have an FAQ that can be easily given by Level
> 1 or Level 2 help desk personnel of the form, "Oh, you have SELinux
> enabled?  Turn it off; our product doesn't support SELinux."

And thankfully increasingly the more security concious deployers and
users of Linux have a standard FAQ response to that of "No. Our security
is more important than your sloppy support"

> standardize ways in which ISV installers can configure the system
> appropriately (e.g., an LSB interface to open up a particular hole in
> the firewall, etc.).

Applications should *never* automatically be allowed to open up firewall
holes. A lot of enterprise customers would go ballistic if that became
practice.

> > My first question now is whether or not my description is correct? Since I 
> > don't know the spec in great detail there is certainly a chance that we say 
> > something about TEXREL somewhere and what we expect to happen.
> 
> What do you mean by text relocations?  Do you mean some applicaiton
> where some parts of the object file was compiled -fPIC?  As I said
> earlier, this is the first time I've heard about any such thing
> conflicting with SELinux.  Can you say more about what the problem is?
> What is the impact of requiring ISV's to compile without text
> relocations?

Minimal, very few apps use textrels. The nasties are that some of them
inherit textrels from libraries they use. Eg fluendo appears to have this
problem right now because of some textrels inherited from a non-free
library they use and don't control.

Alan