[refpolicy] [PATCH/RFC] Add support for the skype_t domain

[domg472@gmail.com (Dominick Grift)]

On Wed, 2011-08-03 at 15:42 +0200, Sven Vermeulen wrote:
> On Fri, Jul 29, 2011 at 08:59:33AM -0400, Christopher J. PeBenito wrote:
> > On 07/24/11 11:38, Sven Vermeulen wrote:
> > > The skype application is a popular voice and video chat application.
> > > This patch adds preliminary support for skype on SELinux.
> [...]
> > > +userdom_manage_user_home_content_dirs(skype_t)
> > > +userdom_manage_user_home_content_files(skype_t)
> > 
> > Is this really necessary since there is skype_home_t?
> 
> Depends on the use case, but Skype can be used to send and receive files, so
> skype_t needs to be able to manage the users' home directory content.
> 
> Not that I'm happy with that, but it seems to be how most applications
> handle this. I personally prefer a specific type for interacting with the
> "outside" world (user_download_t or so) and have the apps be able to manage
> that type rather than user_home_t. But that does make it more difficult to
> explain to users (not really userfriendly).
> 
> Thanks for the feedback (also on the other RFC mail)!

Its pretty much me against the world but i will say it anyway:

In my experience one should not block access to generic user content but
rather prevent user agents from creating content with the generic user
content type, if it is not generic user content (e.g if it is a
communication channel, configuration, cache or any other kind of file
that is needed for the program to run).

So a program like skype should be able to manage user_home_t just fine.
Thats not the issue the issue is that i dont want it to have access to
protected files that are needed to make some user agent run properly
(atleast not if they dont need that access). (ssh_home_t, gpg_secret_t,
"any user app config files", gnome keyring db
etc, etc, etc.

Im my view we should be trying to improve the integrity of the user
applications their content. Not user content.

So what is generic user content then? Well for example the content of
~/Pictures, Music, Documents, Video, Pictures and any content in ~ that
is not configuration/cache etc content of some user application.

If that is implemented, then you can achieve pretty solid user space
integrity whilst keeping things practical.

Stuff i focussed on when confining user space was the above and
labelling the communication between user agents.

So when you see dbus chat by a user domain or you see a user domain
connecttingto a unix_stream_socket and writing to a sock file with a
user type then you should confine that agent as well and make sure it
objects get a private type itself.

> Wkr,
> 	Sven Vermeulen
> _______________________________________________
> refpolicy mailing list
> refpolicy at oss.tresys.com
> http://oss.tresys.com/mailman/listinfo/refpolicy
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
Url : http://oss.tresys.com/pipermail/refpolicy/attachments/20110803/f4ea11dc/attachment.bin