Jóhann, 
Why do you think this is a bug?  None of the suggestions in the alert satisfied your needs?

Well yes but setting up irc account in empathy should not trigger selinux alert if this was aunt tilly then she would be scratching her head what the alert meant..

Unfortunately if the Selinux-GUI is going to be noop proof you'll need to add a large green button that says allow with the unfortunet site affect that all users that would encounter selinux report probably would just click allow...

But should telepathy_idle_t be able to connect to port 8001 by default, or did you setup a strange port.

 grep 8001 /etc/services 
vcom-tunnel     8001/tcp                # VCOM Tunnel
vcom-tunnel     8001/udp                # VCOM Tunnel

We could label port 8001 as ircd_port_t or we could add a new port type.  The goal with SELinux is to get the out of the box settings right, and make people with strange setups have to fiddle with the controls.  We really do not want Aunt Tilly to see an alert screen.

Hum.. 

This is just stock Fedora14 Livecd install upgraded to rawhide without any modification other then few missing applications I use that i have installed. 

I only added the irc account empathy for testing to see how it works and it did not work better than so that I could not figure out how to join a channel so I just fired up xchat-gnome which btw did not trigger any selinux-alert 

I have Selinux running in permissive mode but I might have one time booted with selinux=0 thou I cant be certain of it since I sometimes I have a hard time to keep track on what I'm doing on what machine when testing rawhide. 

I did not setup it to run on any strange port and you probably need to contact Brian Pepple? I believe to get any answers on how telepathy/empathy is expected to be doing.

I would just add a boolean ( i thought we had it there already ) allowing "telepathy_domain" to connect to all ports.

This is some irc server listening on 8001. Next we will encounter irc servers listening on yet other ports.. Cannot go and label all ports ircd_port_t just because someone decides to configure his ircd to listen to some random port.

o actually it did suggest:

setsebool -P telepathy_tcp_connect_generic_network_ports 1

So this is not a bug in my view.

It is from my my perspective since I think that anything that trigger selinux-alert from any application we ship in it's default configured state should not happen. 

If we want end users to use, trust and rely on selinux we cannot be responsible for triggering false positives alerts to the end user. . .

I kind of agree, and in my view this should not have happened.

This domain should have been unconfined since it is most likely initiated by an unconfined domain.

The issue is a bit more complicated than it appears on the surface.

1. we need to make prefixes work so that we can specificy which calling domain can and which cannot transition to other domain upon executing an entry file (this currently does not work on Fedora. its all or nothing.)

2. we need prefixes and allow unconfined_dbusd_t to transition to unconfined_telepathy_idle_t, and make this an unconfined_domain. (again in my view we need prefixes)

This is in my view a design flaw, and there is no consensus in the community about the definition of unconfined users and confined users, and how to deal with them.

My view is that unconfined users should always be unconfined. I mean totally exempted. No matter what they run.

Yes we would run into labelling issues. But in my view we can deal with this by using role prefixes.

If you prefix all user applications then you can make distinction between the various classes of users.

Example unconfined_t runs telepathy_idle, it transitions to unconfined_telepathy_idle_t so that we can define file type transitions and whatnot, but on the other hand we make unconfined_telepathy_idle_t an unconfined_domain so that it is still exempted.

This should, in my view be done for all applications, and services that need to create files with proper types.

you run httpd manually from unconfined_t? Transition to unconfined_httpd_t etc.

Bottom line: unconfined_u should not be restricted by selinux in any way. Not even execmem, execmod, execstack, execheap. Nothing.

But hey, that is just my view...

I tend to agree with you on unconfined_t and at the time that we ship F15, I will remove the transition on telepathy.  I just wanted to get as much exposure on this policy as possible.  So that confined users would get better coverage.

The problem with unconfined_t is that almost everyone uses it, so some of the other confinements do not get the wide coverage that I believe they need.

We are slowly being defeated on the execmem,execmod, execstack,execheap coverage and usually these get turned off at release.  The benefit of these is again bad apps get fixed if we have lots of people complaining.

Certainly if a lot of people complain it might put enough pressure on developers to fix their application but nothing is certain in this world so it might be better to escalate the issue to FESCO and get them to decide a certain release/date that developers need to have this fixed before or their application will get dropped out of the distribution. 

This might sound as a rather drastic proposal but it goes without saying that we cant endlessly be pushing the problem to $Next_release and turning things off those application wont get fixed that way.

Well what I am not necessarily saying the app is broken, but we are collecting data on how the application actually runs in the real world.  In this case we found out that somewhere telepathy_idle connects to tcp port 8001.  Then we have to figure out if this is a custom setup or not.  If not custom, then we might want to add the rule to the database.

dwalsh, you can disable the telepathy transition for unconfined users and allow execmem etc. but this does not solve the root issue.

Ive encountered similar issues with people trying to manually run for example, shorewall, iptables, and maybe bridge control.

In the case above they are able to run it in the unconfined domain, sure, but file transitions may not work properly.

I had a guy the other day that ran shorewall manually for unconfined_t and he was complaining about the mislabelled log file that was created because shorewall was running in the unconfined_t domain.

I helped him fix that issue, but as he rightfully said: "I'am sure that other apps/services have these same issues."

Yes I know of the problem, though it is not as easily solved as you think.  You would need to add a rule that says all domains that talk to shorewall_t now need to talk to unconfined_shorewall_t.  Then we have the security problem of a confined domain able to manipulate an unconfined domain.

If you want to submit some patches say for shorewall or another domain to transition unconfined_t to unconfined_shorewall_t and then make sure the file labels get created correctly, I would take a look.  We actually do this for unconfined_sendmail_t, so there is some precedence.

I like this idea. I was thinking about that many times ... but

not sure whether we really want to do it. I can imagine when people (maintainers/developers) will say ... you have this for shorewall so why not for my/this/other service(s)/app(s).

Can we then control it?

And still how Dan said

... confined domain able to manipulate an unconfined domain.

substitute unconfined by unprotected and then it does not matter anymore..

want to be exempt from selinux policy enforcement by running unconfined? Fine but don't expect selinux to come save you when shed hits the fan.

and sure we should do it for all confined domains not just shorewall imho.

You say all confined domains would have own domain type and unconfined_* domain type. Sounds like a revolution.

That is exactly what i am saying yes, and yes it would be a revolution.

Basically it would be part of a complete selinux-policy rewrite.

If you look at f15, a lot has changed and a lot of policy is obsolete and some is broken. El6 release is just behind us. This would be a good time in my view to rewrite policy. without all the backward compatibility stuff in it, and a fresh look on user domains and work toward facilitating a confined user space.

But i guess its wishful thinking on my part. That is why i started building my own policy for f15 > from scratch. leaving out all the legacy stuff, revisiting, rewriting old policy, removing deprecated policy, policy for compatibility etc.

The goals for my new policy are:

truely modular
unconfined_t is really unconfined
no unconfined domains by default unless they are started by unconfined_t.
truely confined user space.
cleaning out legacy stuff etc. Revisiting all policy.

At least I totally agree with the last point.

* cleaning out legacy stuff etc. Revisiting all policy.

And of course all points are nice idea. But unfortunately the reality is cruel.

For example

* no unconfined domains by default unless they are started by unconfined_t

rgmanager - I really don't see any way how this domain could work without unconfined_domain(). 

And what would you tell people?

Please start the domain by hand, not using init script.

But I like unconfined_* idea. We could try to write some examples for some domains and see how this works. Step by step.

Let me clarify this point:

* no unconfined domains by default unless they are started by unconfined_t

Please note the by default. I am well aware that some domain eventually probably should be unconfined_domains (for example rpm_t)

But i mean they should no longer be by default. So until a fedora release gets released, the unconfined_domain() calls are removed. That way we keep working on improving their functionality in a confined domain.

Now we have a shedload of unconfined_domains (way to many in my view) and aslong as they stay unconfined we can not improve them. We do not get feedback because it just works.

So i am saying, remove the unconfined_domain except when its started by unconfined_t and when a release is deployed we can add unconfined_domains (as little as possible) as failover only.

Yes, I understand your arguments and I try to say people to run 

# semodule -r unconfined

if they use rawhide. But I think some domains we really want to leave as unconfined because we would need to write really a lot of rules and the domain would end up as unconfined anyway.

Its not that simple in my view. There is no unconfined module in selinux-policy-mls and so in those cases we must resort to "a lot of rules" instead.

I tried that one of the rawhide releases by changing the calls to unconfined_domain to permissive, to gather avc messages during the rawhide run.  

I agree we should look at removing more of the unconfined_domains from the policy altogether.  I would like to also remove the legacy stuff from the policy although attempting to merge upstream gets more difficult.