So it works in permissive mode.

I think you need to run

# restorecon -R -v /usr/lib/chromium-browser

If this does not work, please try to run

# service auditd restart
# run chromium
# ausearch -m avc -ts recent

(In reply to comment #1)
> So it works in permissive mode.

Yep.

> I think you need to run
> 
> # restorecon -R -v /usr/lib/chromium-browser
> 
> If this does not work, please try to run
> 
> # service auditd restart
> # run chromium
> # ausearch -m avc -ts recent

No luck - with the stable Google release I did:

# restorecon -R -v /usr/lib/chromium-browser/
# restorecon -R -v /opt/google
# service auditd restart
Restarting audtid (via systemctl):          [OK]
$ google-chrome &  (plugin crashed)
# ausearch -m avc -ts recent
<no matches>
# setenforce 0
$ pgrep -f chrome | xargs kill -9
$ google-chrome &  (plugin worked)
# ausearch -m avc -ts recent
<no matches>
# ausearch -m avc
[...]
time->Thu Apr 28 08:45:41 2011
type=SYSCALL msg=audit(1303994741.500:708): arch=40000003 syscall=5 success=yes exit=9 a0=9883c28 a1=241 a2=1b6 a3=0 items=0 ppid=1 pid=19423 auid=1000 uid=1000 gid=1000 euid=1000 suid=1000 fsuid=1000 egid=1000 sgid=1000 fsgid=1000 tty=(none) ses=41 comm="mission-control" exe="/usr/libexec/mission-control-5" subj=unconfined_u:unconfined_r:telepathy_mission_control_t:s0-s0:c0.c1023 key=(null)
type=AVC msg=audit(1303994741.500:708): avc:  denied  { open } for  pid=19423 comm="mission-control" name=".mc_connections" dev=sda3 ino=657221 scontext=unconfined_u:unconfined_r:telepathy_mission_control_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:user_home_t:s0 tclass=file
type=AVC msg=audit(1303994741.500:708): avc:  denied  { write } for  pid=19423 comm="mission-control" name=".mc_connections" dev=sda3 ino=657221 scontext=unconfined_u:unconfined_r:telepathy_mission_control_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:user_home_t:s0 tclass=file

(I just inlucde the above to show that ausearch is working, telepathy had some issue with ~/.cache/.mc_connections and I did a restorecon there.)

I suspect that this crash happened because of a mislabelled ~/.config

This directory should have type config_home_t and not user_home_t. (verify whether it works when you did restorecon -R -v ~/.config and when you have confirmed that this directory is type config_home_t)

the chrome sandbox is not allowed to read generic user_home_t type files but it is allowed to read config_home_t files.

Also see if this directory , stays labelled properly. I have heard of instances where for some strange reason ~/.config ended up with a wrong type again after a while.

By default you wont see an AVC denial about this issue because chrome sandboxes attempts to get attributes or search user_home_t directories are hidden ( they can be exposed when you unload the "dontaudit" rules. )

The main issue here is why does ~/.config not get labelled properly, and why does it, even if it labelled properly, sometimes get reset to a bad type seemingly.

Bob 

If you run

ps -eZ | grep restorecond

What does it return?

Great, restorecon -R -v ~/.config does re-enable chrome plugin functionality.

Nothing from ps command -- restorecond doesn't appear to be running... or installed:

$ rpm -qa policycoreutils-restorecond
$

Shall I install it?

I am not sure if just installing the package will also tell gnome-session to enable it when you start a session. 

How did you install Fedora? From a LiveCD/USB?

Are you Running Gnome at all?

I guess i have an idea why this is happening. I wonder if this restorecond -u functionality works in anything but Gnome...

I installed from an F15 Alpha DVD (Fedora-15-Alpha-i386-DVD.iso) that I downloaded on April 9, with upgrades via yum since then.  I am using Gnome.  I started with the Gnome 3 shell, then I went back to fallback for a while, then back to the shell -- though I noticed the problem before I tried switching.

I suspect that you have encountered a bug in the upgrade path alpha to current.

restorecond -u should be running in your gnome session. I guess you could configure gnome-session-properties and tell it to run "restorecond -u" when your session starts.

You could also create a test login user to see whether "restorecond" -u is started when you login there. If it is then i guess there may be some stray configuration file somewhere in your home directory.

Well, as I mentioned before, restorecond wasn't installed previously for whatever reason.  I did install it then restart gnome and it's running now without my editing any config.  

My guess is that I wiped out labels when restoring the home directory from backup so I'm satisfied with restorecon and restorecond as fixes here.  I'll keep an eye on it and let you know if I see any change.

PS Not sure if it matters, but my /etc/selinux/restorecond_user.conf doesn't have a specific entry for ~/.config/* unlike, e.g. ~/.gnome2/*.  It does have ~/*, though.

As long as it watches the top level directories it should be fine (like it does by default). That is provided that your home is properly labelled (so once restorecond -u is running, you could run restorecon -R -v ~ once more to make sure everything is labelled properly and then you should be fine)

I has same issue, lastpass plugin crashed in chromium, but after running (not as root but as regular user):

restorecon -R -v ~/.config

everything now works great.

install policycoreutils-restorecond and relogin. after you relogged in and have determined that restorecond is running in your session, restorecon -R -v ~