All of lore.kernel.org
 help / color / mirror / Atom feed
From: domg472@gmail.com (Dominick Grift)
To: refpolicy@oss.tresys.com
Subject: [refpolicy] Basic policy for KDE and Konqueror
Date: Sun, 06 Sep 2009 15:16:41 +0200	[thread overview]
Message-ID: <1252243011.2689.16.camel@notebook1.grift.internal> (raw)
In-Reply-To: <200909061422.27551.Nicky726@gmail.com>

On Sun, 2009-09-06 at 14:22 +0200, Nicky726 wrote:
> Hello,
> 
> Dominick Grift wrote:
>  
> > looks like dbus_connect_session_bus() is not (yet) implemented in f11 and
> >  upstream refpolicy. Basically it facilitates the acquire_svc on user bus.
> >  You could create it yourself or add the local policy above as a workaround
> >  until the interface is implemented.
>  
> I'll use the workaround then, and when I have time, I'll try to look at 
> implementing the interface.
> 
> > The reason that dbus_connect_session_bus is not implemented is that
> >  confining GUI user apps does not have much priority and it presents some
> >  complications which minimize the benefits of confined gui user apps.
> 
> Could you write more about those complications which minimize benefits of 
> confined gui user apps? Or could you reffer me to some article?

Well the main objective for using selinux is to prevent privilege
escalation. In the the GUI user environment this is hard to prevent
fully. Basically because of how desktop enviroments work.

For example gnome. If you confine a GUI user app for Gnome than you will
run into issues where your program needs to interact with the desktop.
Some of those objects get created with the user content type. So that
means that your gui must interact with generic user content
(user_home_t, user_tmp_t) This is a form of escalation that is not
desirable.

It would be better if you can restrict your programs so that it cannot
interact with user content. because else your program may be able to
read/write to user files.

Fortunately this issue can be for a large part anticipated by creating a
special type for private user files. So that although a program can
interact with user_home_t files, it cannot read the special type for
example my_private_files_t.

Other then that its also a matter of security priorities. I guess many
in the community prioritize on restricting root as opposed to
unprivileged users. Since compromizing root can lead to a compromized
system more easily.

However in my view user content is also important to protect because
users use computers to store confidenial data etc.

So in short, i think we are not quite to the point of confining the user
environment. There are some difficulties to overcome like gui desktops
and also not everyone agree on the benefits of selinux in the user
environment, e.g. it makes operating a system much more complicated/
requires much more maintenance, and it is bug-prone.

> Thanx for cooperation,
> Ondrej Vadinsky
> 

  reply	other threads:[~2009-09-06 13:16 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <mailman.3.1252170002.16620.refpolicy@oss.tresys.com>
2009-09-06 12:22 ` [refpolicy] Basic policy for KDE and Konqueror Nicky726
2009-09-06 13:16   ` Dominick Grift [this message]
2009-09-05 15:39 Nicky 726
2009-09-05 15:48 ` Dominick Grift
  -- strict thread matches above, loose matches on Subject: below --
2009-09-04 14:52 Nicky 726
2009-09-04 15:19 ` Dominick Grift
2009-08-12 12:40 Nicky726
2009-08-12 18:58 ` Dominick Grift
2009-08-17 14:40   ` Nicky726
2009-08-17 15:01     ` Mike Edenfield
2009-08-27 16:07   ` Nicky726
2009-08-27 16:42     ` Dominick Grift
2009-08-27 16:47     ` Dominick Grift
2009-09-03 20:15   ` Nicky726
2009-09-03 20:36     ` Dominick Grift
2009-08-14 17:37 ` Christopher J. PeBenito

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1252243011.2689.16.camel@notebook1.grift.internal \
    --to=domg472@gmail.com \
    --cc=refpolicy@oss.tresys.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.