Bug 196877 - gaim2 needs to be mono_exec_t
Summary: gaim2 needs to be mono_exec_t
Status: CLOSED DEFERRED
Alias: None
Product: Fedora
Classification: Fedora
Component: selinux-policy (Show other bugs)
(Show other bugs)
Version: rawhide
Hardware: All Linux
medium
medium
Target Milestone: ---
Assignee: Daniel Walsh
QA Contact:
URL:
Whiteboard:
Keywords:
Depends On:
Blocks: FC6Blocker
TreeView+ depends on / blocked
 
Reported: 2006-06-27 14:16 UTC by Jeremy Katz
Modified: 2007-11-30 22:11 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-07-17 19:30:27 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

Description Jeremy Katz 2006-06-27 14:16:46 UTC
With gaim2, there's the possibility of writing plugins in C#.  This then means
that we end up needing to label /usr/bin/gaim as mono_exec_t for execmem permissions

This does scare me a little, though, as given gaim's less than stellar security
record, I'm not 100% sure that we really want to be doing this.  Thoughts?

Comment 1 Warren Togami 2006-06-27 17:13:28 UTC
Adding Bressers, who may have security related opinions on this matter.

Comment 2 Josh Bressers 2006-06-27 17:35:12 UTC
Gaim has had a fairly decent security track record as of late, but this still
worries me.  Could it be possible to have the first packaged plugin that needs
this to set the label?

I imagine most gaim users do not install random plugins, which would make this
change more secuirty risk than feature.

Comment 3 Warren Togami 2006-06-27 17:51:53 UTC
For now Jeremy recommended that we disable mono in our build temporarily until
we decide, or come up with a better solution.


Comment 4 Tom "spot" Callaway 2006-06-27 17:55:51 UTC
I don't care either way, as I disable selinux by default.

Comment 5 Warren Togami 2006-06-29 19:17:03 UTC
Upstream says that mono support is currently very non-functional, so it is
probably a good idea that we have this disabled for now anyway.


Note You need to log in before you can comment on or make changes to this bug.