* Re: Labeling problem
2009-12-15 22:17 Labeling problem mina elnino
@ 2009-12-16 10:18 ` Dominick Grift
0 siblings, 0 replies; 2+ messages in thread
From: Dominick Grift @ 2009-12-16 10:18 UTC (permalink / raw)
To: selinux
[-- Attachment #1: Type: text/plain, Size: 3158 bytes --]
On Wed, Dec 16, 2009 at 01:47:26AM +0330, mina elnino wrote:
> dear list;
> I'd like to add new policies to a game using selinux policy generator. the
> result is four files generated, which one of them ["*.fc"] contains the
> labeling of game-related files and directories. but the fact is, after
> running the shell script generated by the tool, when i use :
> # ls -Z
> for those files, i get other labels, e.g because they are all in my home
> directory, they receive user_home_t labels except the executable file of the
> game which receives a *_exec_t type. i just used chcon to change contexts of
> files according to "*.fc" file, but the problem is game's process domain can
> access any file with type user_home_t. what should i do?
Specifying contexts for objects in $HOME may be an issue in older distro's i believe. What distro are you using? I use to workk around that issue by developing in the main policy. Meaning by integrating my policy modules in the source policy for the distribution selinux-policy RPM, and by installing that instead of seperate policy packages. The issue has to do with the way SELinux deals with contexts in $home as opposed to contexts elsewhere.
There may be ways other than integrating your models into the main selinux-policy rpm, like editing some files in /etc/selinux/targeted/{modules,contexts} but i never tried that.
Newer distros should probably have that issue solved. I know for example that Fedora 12 has no such issues.
Another thing that may or may not cause the issue is the use of restorecond. In for example Fedora 12, gnome session starts an instance of restorecond for the user which monitors objects in $home and if object labels do not match the system wide context specified contexts, then restorecond -u will reset them to the contexts that are defined system-wide.
That may (or may not) cause issues. For example if you load a policy package with a new context specification for a object in $home. Because restorecond -u was already running, it may not be aware of the change and it will reset the context of the object to what restorecond -u thinks is the specified context. If that is the case you can probably simple kill and restart restorecond to solve the issue.
So it kind of depends on your distro i think.
On the other hand, it is probably very hard to confine a graphical user application without giving it access to the user_home_t type ( and other generic user content). Examples are .pulse-cookie, or orbit. So depending on your security goal and possibilities, you may want to just give it access to user_home_t, user_tmp_t.
What i use to do for example was, when i found out my GUI app needed access to generic home content but i wanted to protect certain user home content from my user apps, to label the user content that should be protected with a special type and only give specified processes access to that type. That way the GUI app could just interact with user_home_t (which it needs) but the confine user app would not be able to access the data that i labeled with special type.
I guess the moral to all this is that the solution depends on the situation.
[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply [flat|nested] 2+ messages in thread