[refpolicy] Basic policy for KDE and Konqueror

[refpolicy] Basic policy for KDE and Konqueror

[Nicky 726]

Hello,

> Date: Fri, 4 Sep 2009 17:19:02 +0200
> From: Dominick Grift <domg472@gmail.com>
> Subject: Re: [refpolicy] Basic policy for KDE and Konqueror
> To: refpolicy at oss.tresys.com
> Message-ID: <20090904151901.GB21615@notebook3.grift.internal>
> Content-Type: text/plain; charset="iso-8859-1"
>
> On Fri, Sep 04, 2009 at 04:52:37PM +0200, Nicky 726 wrote:
>> Hello,
>>
>> > Date: Thu, 3 Sep 2009 22:36:17 +0200
>> > From: Dominick Grift <domg472@gmail.com>
>> > Subject: Re: [refpolicy] Basic policy for KDE and Konqueror
>> > To: refpolicy at oss.tresys.com
>> > Message-ID: <20090903203617.GA2709@notebook3.grift.internal>
>> > Content-Type: text/plain; charset="us-ascii"
>> >
>> > On Thu, Sep 03, 2009 at 10:15:23PM +0200, Nicky726 wrote:
>> >> Hello,
>> >>
>> >> I've been reviewing and testing my policy for Konqueror according to Dominick
>> >> Grift's comments. Now I've got confused with the dbus affair:
>> >>
>> >> Dne St 12. srpna 2009 20:58:03 Dominick Grift napsal(a):
>> >> > use proper dbus interfaces (not dbus unconfined)
>> >>
>> >> The thing is that Konqueror starts only with dbus_unconfined(). If I use
>> >> dbus_system_bus_client() I got message, that Konqueror can't be registered
>> >> with dbus, as there is already another one registered. If I use
>> >> dbus_session_bus_client() I got absolutely no output. In both cases Konqueror
>> >> won't start and no AVC denials are displayed.
>> >>
>> >> As I looked into Evolution and Mozilla policies sources, there are only this
>> >> two interfaces used. Are there some other steps needed for it to work? Or is
>> >> there some better suited interfaces? Do you have other suggestions?
>> > dbus policy is a bit "underdeveloped". are you looking in the right places for avc denials?
>> >
>> > ausearch -m user_avc -ts today
>> > grep -i dbus /var/log/messages
>> >
>> > dbus throws its denials all around the place. some stuff goes to audit.log other stuff goes to messages.
>> >
>> > can you show us your dbus related avc denials?
>> >>
>> >> Thanks for your time,
>> >> Ondrej Vadinsky
>>
>> This is what I get from /var/log/messages:
>>
>> In the mean time:
>> Sep ?4 16:23:44 tsubaki dbus: avc: ?received policyload notice (seqno=5)
>> Sep ?4 16:23:44 tsubaki dbus: Can't send to audit system: USER_AVC
>> avc: ?received policyload notice (seqno=5)#012: exe="?" (sauid=81,
>> hostname=?, addr=?, terminal=?)
>> Sep ?4 16:23:44 tsubaki dbus: Reloaded configuration
>> Sep ?4 16:23:44 tsubaki dbus: avc: ?received policyload notice (seqno=5)
>>
>> With no dbus interface called:
>> Sep ?4 16:23:59 tsubaki dbus: avc: ?denied ?{ send_msg } for
>> msgtype=method_call interface=org.freedesktop.DBus member=Hello
>> dest=org.freedesktop.DBus spid=2807
>> scontext=unconfined_u:unconfined_r:konqueror_t:s0-s0:c0.c1023
>> tcontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
>> tclass=dbus
>
> This may work for the issue above:
>
> userdom_dbus_send_all_users(konqueror)

yes it worked for send_msg but only triggered acquire_svc denyal

>
>>
>> With dbus_system_bus_client:
>> Sep ?4 16:45:35 tsubaki dbus: avc: ?denied ?{ acquire_svc } for
>> service=org.kde.konqueror-2869 spid=2869
>> scontext=unconfined_u:unconfined_r:konqueror_t:s0-s0:c0.c1023
>> tcontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
>> tclass=dbus
> I ' am not sure which distro (version) you are using but on recent version you can probably use for this:
>
> dbus_connect_session_bus(konqueror_t)

With up-to-date fedora 11 it sadly didn't do anything for me

>
>>
>> With dbus_session_bus_client:
>> Sep ?4 16:48:52 tsubaki dbus: avc: ?denied ?{ send_msg } for
>> msgtype=method_call interface=org.freedesktop.DBus member=Hello
>> dest=org.freedesktop.DBus spid=2897
>> scontext=unconfined_u:unconfined_r:konqueror_t:s0-s0:c0.c1023
>> tcontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
>> tclass=dbus
>
> Dbus is a bit tricky, especially when it comes to GUI user apps. You may need /want to create a:
>
> konqueror_dbus_chat()

Created and called from konqueror_run(), it solves the send_msg stuff too.

>
> And you may also need dbusd_session/system_bus_client templates.

Theese didn't work for me either, I end up with acquire_svc denyal too

> Try it out a bit and when it comes to dbus remember to check both ausearch -m user_avc, as well as /var/log/messages

I searched dbus related interfaces again and it worked with
unconfined_dbus_connect() which I guess ain't much clean sollution or
is it?

The other thing which works fine is adding:

allow konqueror_t $2:dbus acquire_svc;

into konqueror_run().
Don't know how much cleaner this is, but seems to me as better
solution since it works with current user domain and not only and
always with unconfined. But fix me if I'm wrong. Can I consider this
dbus issue solved or should I try something else? In that case, what
would you suggest?



Thanks for your time,
Ondrej Vadinsky

-- 
"Don't it always seem to go
That you don't know what you've got
Till it's gone."

                                         (Joni Mitchell)

[refpolicy] Basic policy for KDE and Konqueror

[Dominick Grift]

On Sat, Sep 05, 2009 at 05:39:24PM +0200, Nicky 726 wrote:
> Hello,
> 
> > Date: Fri, 4 Sep 2009 17:19:02 +0200
> > From: Dominick Grift <domg472@gmail.com>
> > Subject: Re: [refpolicy] Basic policy for KDE and Konqueror
> > To: refpolicy at oss.tresys.com
> > Message-ID: <20090904151901.GB21615@notebook3.grift.internal>
> > Content-Type: text/plain; charset="iso-8859-1"
> >
> > On Fri, Sep 04, 2009 at 04:52:37PM +0200, Nicky 726 wrote:
> >> Hello,
> >>
> >> > Date: Thu, 3 Sep 2009 22:36:17 +0200
> >> > From: Dominick Grift <domg472@gmail.com>
> >> > Subject: Re: [refpolicy] Basic policy for KDE and Konqueror
> >> > To: refpolicy at oss.tresys.com
> >> > Message-ID: <20090903203617.GA2709@notebook3.grift.internal>
> >> > Content-Type: text/plain; charset="us-ascii"
> >> >
> >> > On Thu, Sep 03, 2009 at 10:15:23PM +0200, Nicky726 wrote:
> >> >> Hello,
> >> >>
> >> >> I've been reviewing and testing my policy for Konqueror according to Dominick
> >> >> Grift's comments. Now I've got confused with the dbus affair:
> >> >>
> >> >> Dne St 12. srpna 2009 20:58:03 Dominick Grift napsal(a):
> >> >> > use proper dbus interfaces (not dbus unconfined)
> >> >>
> >> >> The thing is that Konqueror starts only with dbus_unconfined(). If I use
> >> >> dbus_system_bus_client() I got message, that Konqueror can't be registered
> >> >> with dbus, as there is already another one registered. If I use
> >> >> dbus_session_bus_client() I got absolutely no output. In both cases Konqueror
> >> >> won't start and no AVC denials are displayed.
> >> >>
> >> >> As I looked into Evolution and Mozilla policies sources, there are only this
> >> >> two interfaces used. Are there some other steps needed for it to work? Or is
> >> >> there some better suited interfaces? Do you have other suggestions?
> >> > dbus policy is a bit "underdeveloped". are you looking in the right places for avc denials?
> >> >
> >> > ausearch -m user_avc -ts today
> >> > grep -i dbus /var/log/messages
> >> >
> >> > dbus throws its denials all around the place. some stuff goes to audit.log other stuff goes to messages.
> >> >
> >> > can you show us your dbus related avc denials?
> >> >>
> >> >> Thanks for your time,
> >> >> Ondrej Vadinsky
> >>
> >> This is what I get from /var/log/messages:
> >>
> >> In the mean time:
> >> Sep ?4 16:23:44 tsubaki dbus: avc: ?received policyload notice (seqno=5)
> >> Sep ?4 16:23:44 tsubaki dbus: Can't send to audit system: USER_AVC
> >> avc: ?received policyload notice (seqno=5)#012: exe="?" (sauid=81,
> >> hostname=?, addr=?, terminal=?)
> >> Sep ?4 16:23:44 tsubaki dbus: Reloaded configuration
> >> Sep ?4 16:23:44 tsubaki dbus: avc: ?received policyload notice (seqno=5)
> >>
> >> With no dbus interface called:
> >> Sep ?4 16:23:59 tsubaki dbus: avc: ?denied ?{ send_msg } for
> >> msgtype=method_call interface=org.freedesktop.DBus member=Hello
> >> dest=org.freedesktop.DBus spid=2807
> >> scontext=unconfined_u:unconfined_r:konqueror_t:s0-s0:c0.c1023
> >> tcontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
> >> tclass=dbus
> >
> > This may work for the issue above:
> >
> > userdom_dbus_send_all_users(konqueror)
> 
> yes it worked for send_msg but only triggered acquire_svc denyal
> 
> >
> >>
> >> With dbus_system_bus_client:
> >> Sep ?4 16:45:35 tsubaki dbus: avc: ?denied ?{ acquire_svc } for
> >> service=org.kde.konqueror-2869 spid=2869
> >> scontext=unconfined_u:unconfined_r:konqueror_t:s0-s0:c0.c1023
> >> tcontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
> >> tclass=dbus
> > I ' am not sure which distro (version) you are using but on recent version you can probably use for this:
> >
> > dbus_connect_session_bus(konqueror_t)
> 
> With up-to-date fedora 11 it sadly didn't do anything for me
> 
> >
> >>
> >> With dbus_session_bus_client:
> >> Sep ?4 16:48:52 tsubaki dbus: avc: ?denied ?{ send_msg } for
> >> msgtype=method_call interface=org.freedesktop.DBus member=Hello
> >> dest=org.freedesktop.DBus spid=2897
> >> scontext=unconfined_u:unconfined_r:konqueror_t:s0-s0:c0.c1023
> >> tcontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
> >> tclass=dbus
> >
> > Dbus is a bit tricky, especially when it comes to GUI user apps. You may need /want to create a:
> >
> > konqueror_dbus_chat()
> 
> Created and called from konqueror_run(), it solves the send_msg stuff too.
> 
> >
> > And you may also need dbusd_session/system_bus_client templates.
> 
> Theese didn't work for me either, I end up with acquire_svc denyal too
> 
> > Try it out a bit and when it comes to dbus remember to check both ausearch -m user_avc, as well as /var/log/messages
> 
> I searched dbus related interfaces again and it worked with
> unconfined_dbus_connect() which I guess ain't much clean sollution or
> is it?
> 
> The other thing which works fine is adding:
> 
> allow konqueror_t $2:dbus acquire_svc;

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.

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.

> 
> into konqueror_run().
> Don't know how much cleaner this is, but seems to me as better
> solution since it works with current user domain and not only and
> always with unconfined. But fix me if I'm wrong. Can I consider this
> dbus issue solved or should I try something else? In that case, what
> would you suggest?
> 
> 
> 
> Thanks for your time,
> Ondrej Vadinsky
> 
> -- 
> "Don't it always seem to go
> That you don't know what you've got
> Till it's gone."
> 
>                                          (Joni Mitchell)
> _______________________________________________
> 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: not available
Url : http://oss.tresys.com/pipermail/refpolicy/attachments/20090905/c401d24e/attachment.bin 

[refpolicy] Basic policy for KDE and Konqueror

[Nicky726]

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?

Thanx for cooperation,
Ondrej Vadinsky

-- 
Don`t it always seem to go
That you don`t know what you`ve got
Till it`s gone.

		(Joni Mitchell)

[refpolicy] Basic policy for KDE and Konqueror

[Dominick Grift]

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
> 

[refpolicy] Basic policy for KDE and Konqueror

[Nicky 726]

Hello,

> Date: Thu, 3 Sep 2009 22:36:17 +0200
> From: Dominick Grift <domg472@gmail.com>
> Subject: Re: [refpolicy] Basic policy for KDE and Konqueror
> To: refpolicy at oss.tresys.com
> Message-ID: <20090903203617.GA2709@notebook3.grift.internal>
> Content-Type: text/plain; charset="us-ascii"
>
> On Thu, Sep 03, 2009 at 10:15:23PM +0200, Nicky726 wrote:
>> Hello,
>>
>> I've been reviewing and testing my policy for Konqueror according to Dominick
>> Grift's comments. Now I've got confused with the dbus affair:
>>
>> Dne St 12. srpna 2009 20:58:03 Dominick Grift napsal(a):
>> > use proper dbus interfaces (not dbus unconfined)
>>
>> The thing is that Konqueror starts only with dbus_unconfined(). If I use
>> dbus_system_bus_client() I got message, that Konqueror can't be registered
>> with dbus, as there is already another one registered. If I use
>> dbus_session_bus_client() I got absolutely no output. In both cases Konqueror
>> won't start and no AVC denials are displayed.
>>
>> As I looked into Evolution and Mozilla policies sources, there are only this
>> two interfaces used. Are there some other steps needed for it to work? Or is
>> there some better suited interfaces? Do you have other suggestions?
> dbus policy is a bit "underdeveloped". are you looking in the right places for avc denials?
>
> ausearch -m user_avc -ts today
> grep -i dbus /var/log/messages
>
> dbus throws its denials all around the place. some stuff goes to audit.log other stuff goes to messages.
>
> can you show us your dbus related avc denials?
>>
>> Thanks for your time,
>> Ondrej Vadinsky

This is what I get from /var/log/messages:

In the mean time:
Sep  4 16:23:44 tsubaki dbus: avc:  received policyload notice (seqno=5)
Sep  4 16:23:44 tsubaki dbus: Can't send to audit system: USER_AVC
avc:  received policyload notice (seqno=5)#012: exe="?" (sauid=81,
hostname=?, addr=?, terminal=?)
Sep  4 16:23:44 tsubaki dbus: Reloaded configuration
Sep  4 16:23:44 tsubaki dbus: avc:  received policyload notice (seqno=5)

With no dbus interface called:
Sep  4 16:23:59 tsubaki dbus: avc:  denied  { send_msg } for
msgtype=method_call interface=org.freedesktop.DBus member=Hello
dest=org.freedesktop.DBus spid=2807
scontext=unconfined_u:unconfined_r:konqueror_t:s0-s0:c0.c1023
tcontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
tclass=dbus

With dbus_system_bus_client:
Sep  4 16:45:35 tsubaki dbus: avc:  denied  { acquire_svc } for
service=org.kde.konqueror-2869 spid=2869
scontext=unconfined_u:unconfined_r:konqueror_t:s0-s0:c0.c1023
tcontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
tclass=dbus

With dbus_session_bus_client:
Sep  4 16:48:52 tsubaki dbus: avc:  denied  { send_msg } for
msgtype=method_call interface=org.freedesktop.DBus member=Hello
dest=org.freedesktop.DBus spid=2897
scontext=unconfined_u:unconfined_r:konqueror_t:s0-s0:c0.c1023
tcontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
tclass=dbus

Thanks for your time,
Ondrej Vadinsky

--
"Don't it always seem to go
That you don't know what you've got
Till it's gone."

? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? (Joni Mitchell)

[refpolicy] Basic policy for KDE and Konqueror

[Dominick Grift]

On Fri, Sep 04, 2009 at 04:52:37PM +0200, Nicky 726 wrote:
> Hello,
> 
> > Date: Thu, 3 Sep 2009 22:36:17 +0200
> > From: Dominick Grift <domg472@gmail.com>
> > Subject: Re: [refpolicy] Basic policy for KDE and Konqueror
> > To: refpolicy at oss.tresys.com
> > Message-ID: <20090903203617.GA2709@notebook3.grift.internal>
> > Content-Type: text/plain; charset="us-ascii"
> >
> > On Thu, Sep 03, 2009 at 10:15:23PM +0200, Nicky726 wrote:
> >> Hello,
> >>
> >> I've been reviewing and testing my policy for Konqueror according to Dominick
> >> Grift's comments. Now I've got confused with the dbus affair:
> >>
> >> Dne St 12. srpna 2009 20:58:03 Dominick Grift napsal(a):
> >> > use proper dbus interfaces (not dbus unconfined)
> >>
> >> The thing is that Konqueror starts only with dbus_unconfined(). If I use
> >> dbus_system_bus_client() I got message, that Konqueror can't be registered
> >> with dbus, as there is already another one registered. If I use
> >> dbus_session_bus_client() I got absolutely no output. In both cases Konqueror
> >> won't start and no AVC denials are displayed.
> >>
> >> As I looked into Evolution and Mozilla policies sources, there are only this
> >> two interfaces used. Are there some other steps needed for it to work? Or is
> >> there some better suited interfaces? Do you have other suggestions?
> > dbus policy is a bit "underdeveloped". are you looking in the right places for avc denials?
> >
> > ausearch -m user_avc -ts today
> > grep -i dbus /var/log/messages
> >
> > dbus throws its denials all around the place. some stuff goes to audit.log other stuff goes to messages.
> >
> > can you show us your dbus related avc denials?
> >>
> >> Thanks for your time,
> >> Ondrej Vadinsky
> 
> This is what I get from /var/log/messages:
> 
> In the mean time:
> Sep  4 16:23:44 tsubaki dbus: avc:  received policyload notice (seqno=5)
> Sep  4 16:23:44 tsubaki dbus: Can't send to audit system: USER_AVC
> avc:  received policyload notice (seqno=5)#012: exe="?" (sauid=81,
> hostname=?, addr=?, terminal=?)
> Sep  4 16:23:44 tsubaki dbus: Reloaded configuration
> Sep  4 16:23:44 tsubaki dbus: avc:  received policyload notice (seqno=5)
> 
> With no dbus interface called:
> Sep  4 16:23:59 tsubaki dbus: avc:  denied  { send_msg } for
> msgtype=method_call interface=org.freedesktop.DBus member=Hello
> dest=org.freedesktop.DBus spid=2807
> scontext=unconfined_u:unconfined_r:konqueror_t:s0-s0:c0.c1023
> tcontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
> tclass=dbus

This may work for the issue above:

userdom_dbus_send_all_users(konqueror)

> 
> With dbus_system_bus_client:
> Sep  4 16:45:35 tsubaki dbus: avc:  denied  { acquire_svc } for
> service=org.kde.konqueror-2869 spid=2869
> scontext=unconfined_u:unconfined_r:konqueror_t:s0-s0:c0.c1023
> tcontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
> tclass=dbus
I ' am not sure which distro (version) you are using but on recent version you can probably use for this:

dbus_connect_session_bus(konqueror_t)

> 
> With dbus_session_bus_client:
> Sep  4 16:48:52 tsubaki dbus: avc:  denied  { send_msg } for
> msgtype=method_call interface=org.freedesktop.DBus member=Hello
> dest=org.freedesktop.DBus spid=2897
> scontext=unconfined_u:unconfined_r:konqueror_t:s0-s0:c0.c1023
> tcontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
> tclass=dbus

Dbus is a bit tricky, especially when it comes to GUI user apps. You may need /want to create a:

konqueror_dbus_chat()

And you may also need dbusd_session/system_bus_client templates.

Try it out a bit and when it comes to dbus remember to check both ausearch -m user_avc, as well as /var/log/messages

> 
> Thanks for your time,
> Ondrej Vadinsky
> 
> --
> "Don't it always seem to go
> That you don't know what you've got
> Till it's gone."
> 
> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? (Joni Mitchell)
> _______________________________________________
> 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: not available
Url : http://oss.tresys.com/pipermail/refpolicy/attachments/20090904/33157f8b/attachment-0001.bin 

[refpolicy] Basic policy for KDE and Konqueror

[Nicky726]

Hello,

as a part of my bachellor thesis I've made basic policy for KDE namely 
Konqueror web browser. The resulting source files are enclosed to this e-mail. 

As KDE is complicated and interconnected environment, I chosed to create a 
general module for KDE. The should be any rules concerning shared parts of KDE 
policy. As an example may be context of ~/.kde, where configuration is stored, 
and access rules of this files...

Than for every aplication which is to be confined, there should be one module 
depending on the base KDE policy module. I choosed to confine Konqueror.

I tested this policy on Fedora 10 with KDE 4.2.4 and up-to-date.

I understand that policy I created is probabaly very rough and needs many 
refinements. Would you please comment it, so I can make it better and maybe 
actually useful for some people?

Thanks for your time, 

Ond?ej Vadinsk?
(Nicky726)
-------------- next part --------------
# Qt config file
HOME_DIR/\.config/Trolltech\.conf		--	gen_context(system_u:object_r:kde_shared_home_t,s0)
# KDE home
HOME_DIR/\.kde(/.*)?		gen_context(system_u:object_r:kde_shared_home_t,s0)

# Files in tmp shared among kdeapps
/tmp/kde-(.*)?			gen_context(system_u:object_r:kde_shared_tmp_t,s0)

/tmp/ksocket-(.*)?			gen_context(system_u:object_r:kde_shared_tmp_t,s0)

/var/tmp/kdecache-(.*)?			gen_context(system_u:object_r:kde_shared_tmp_t,s0)
# Links to those file in user home
HOME_DIR/\.kde/socket-(.*)?			gen_context(system_u:object_r:kde_shared_tmp_t,s0)

HOME_DIR/\.kde/cache-(.*)?			gen_context(system_u:object_r:kde_shared_tmp_t,s0)

HOME_DIR/\.kde/tmp-(.*)?			gen_context(system_u:object_r:kde_shared_tmp_t,s0)
-------------- next part --------------
## <summary>Basic kde confinement</summary>

########################################
## <summary>
##	Do not audit attempts to read, 
##	kde tmp files
## </summary>
## <param name="domain">
##	<summary>
##	Domain to not audit.
##	</summary>
## </param>
#
interface(`kde_dontaudit_read_tmp_files',`
	gen_require(`
		type kde_shared_tmp_t;
	')

	dontaudit $1 kde_shared_tmp_t:file read_file_perms;
')

########################################
## <summary>
##	Allow domain to read, kde tmp files, links and sockets
## </summary>
## <param name="domain">
##	<summary>
##	Domain to not audit.
##	</summary>
## </param>
#
interface(`kde_read_tmp',`
	gen_require(`
		type kde_shared_tmp_t;
	')

	allow $1 kde_shared_tmp_t:file read_file_perms;
	allow $1 kde_shared_tmp_t:file read_lnk_file_perms;
	allow $1 kde_shared_tmp_t:file read_sock_file_perms;
')

########################################
## <summary>
##	Allow domain to manage kde tmp files, links, sockets and dirs
## </summary>
## <param name="domain">
##	<summary>
##	Domain to not audit.
##	</summary>
## </param>
#
interface(`kde_manage_tmp',`
	gen_require(`
		type kde_shared_tmp_t;
	')

         manage_dirs_pattern($1,kde_shared_tmp_t,kde_shared_tmp_t)
         manage_files_pattern($1,kde_shared_tmp_t,kde_shared_tmp_t)
         manage_lnk_files_pattern($1,kde_shared_tmp_t,kde_shared_tmp_t)
		 manage_sock_files_pattern($1,kde_shared_tmp_t,kde_shared_tmp_t)
')


########################################
## <summary>
##	Search kde_shared_home directories.
## </summary>
## <param name="domain">
##	<summary>
##	Domain allowed access.
##	</summary>
## </param>
#
interface(`kde_search_home_dir',`
	gen_require(`
		type kde_shared_home_t;
	')

	allow $1 kde_shared_home_t:dir search_dir_perms;
	files_search_rw($1)
')

########################################
## <summary>
##	Read kde_shared_home files.
## </summary>
## <param name="domain">
##	<summary>
##	Domain allowed access.
##	</summary>
## </param>
#
interface(`kde_read_home_files',`
	gen_require(`
		type kde_shared_home_t;
	')

	allow $1 kde_shared_home_t:file r_file_perms;
	allow $1 kde_shared_home_t:dir list_dir_perms;
	files_search_rw($1)
')

########################################
## <summary>
##	Create, read, write, and delete
##	kde_shared_home files.
## </summary>
## <param name="domain">
##	<summary>
##	Domain allowed access.
##	</summary>
## </param>
#
interface(`kde_manage_home_files',`
	gen_require(`
		type kde_shared_home_t;
	')

	allow $1 kde_shared_home_t:file manage_file_perms;
	allow $1 kde_shared_home_t:dir rw_dir_perms;
')

########################################
## <summary>
##	Manage kde_shared_home files and dirs.
## </summary>
## <param name="domain">
##	<summary>
##	Domain allowed access.
##	</summary>
## </param>
#
interface(`kde_manage_home',`
	gen_require(`
		type kde_shared_home_t;
	')

         manage_dirs_pattern($1,kde_shared_home_t,kde_shared_home_t)
         manage_files_pattern($1,kde_shared_home_t,kde_shared_home_t)
         manage_lnk_files_pattern($1,kde_shared_home_t,kde_shared_home_t)
')


########################################
## <summary>
##	Create file, dir, links of specified type in 
##  kde_shared_home_t dirs with type transition
## </summary>
## <param name="domain">
##	<summary>
##	Domain allowed access
##	</summary>
## </param>
## <param name="private type">
##	<summary>
##	Private type of created object
##	</summary>
## </param>
#
interface(`files_kde_home_filetrans',`
	gen_require(`
		type kde_shared_home_t;
	')

         type_transition $1 kde_shared_home_t:{ file lnk_file sock_file dir } $2;

')
-------------- next part --------------
policy_module(kde,0.0.1) 

########################################
#
# Declarations
#
type kde_shared_tmp_t;
files_tmp_file(kde_shared_tmp_t)

type kde_shared_home_t;
files_type(kde_shared_home_t)
-------------- next part --------------

/usr/bin/konqueror	--	gen_context(system_u:object_r:konqueror_exec_t,s0)

HOME_DIR/\.kde/share/config/konq_history		--	gen_context(system_u:object_r:konqueror_home_t,s0)

HOME_DIR/\.kde/share/config/konquerorrc		--	gen_context(system_u:object_r:konqueror_home_t,s0)

HOME_DIR/\.kde/share/config/konqsidebartng.rc		--	gen_context(system_u:object_r:konqueror_home_t,s0)

HOME_DIR/\.kde/share/config/kuriikwsfilterrc		--	gen_context(system_u:object_r:konqueror_home_t,s0)

HOME_DIR/\.kde/share/apps/konqueror(/.*)?			gen_context(system_u:object_r:konqueror_home_t,s0)

HOME_DIR/\.kde/share/apps/khtml(/.*)?			gen_context(system_u:object_r:konqueror_home_t,s0)

-------------- next part --------------

## <summary>policy for konqueror</summary>

########################################
## <summary>
##	Execute a domain transition to run konqueror.
## </summary>
## <param name="domain">
## <summary>
##	Domain allowed to transition.
## </summary>
## </param>
#
interface(`konqueror_domtrans',`
	gen_require(`
		type konqueror_t;
                type konqueror_exec_t;
	')

	domtrans_pattern($1,konqueror_exec_t,konqueror_t)
')


########################################
## <summary>
##	Search konqueror rw directories.
## </summary>
## <param name="domain">
##	<summary>
##	Domain allowed access.
##	</summary>
## </param>
#
interface(`konqueror_search_home_dir',`
	gen_require(`
		type konqueror_home_t;
	')

	allow $1 konqueror_home_t:dir search_dir_perms;
	files_search_rw($1)
')

########################################
## <summary>
##	Read konqueror rw files.
## </summary>
## <param name="domain">
##	<summary>
##	Domain allowed access.
##	</summary>
## </param>
#
interface(`konqueror_read_home_files',`
	gen_require(`
		type konqueror_home_t;
	')

	allow $1 konqueror_home_t:file r_file_perms;
	allow $1 konqueror_home_t:dir list_dir_perms;
	files_search_rw($1)
')

########################################
## <summary>
##	Create, read, write, and delete
##	konqueror rw files.
## </summary>
## <param name="domain">
##	<summary>
##	Domain allowed access.
##	</summary>
## </param>
#
interface(`konqueror_manage_home_files',`
	gen_require(`
		type konqueror_home_t;
	')

	allow $1 konqueror_home_t:file manage_file_perms;
	allow $1 konqueror_home_t:dir rw_dir_perms;
')

########################################
## <summary>
##	Manage konqueror rw files.
## </summary>
## <param name="domain">
##	<summary>
##	Domain allowed access.
##	</summary>
## </param>
#
interface(`konqueror_manage_home',`
	gen_require(`
		type konqueror_home_t;
	')

         manage_dirs_pattern($1,konqueror_home_t,konqueror_home_t)
         manage_files_pattern($1,konqueror_home_t,konqueror_home_t)
         manage_lnk_files_pattern($1,konqueror_home_t,konqueror_home_t)
')


########################################
## <summary>
##	Execute konqueror in the konqueror domain, and
##	allow the specified role the konqueror domain.
## </summary>
## <param name="domain">
##	<summary>
##	Domain allowed access
##	</summary>
## </param>
## <param name="role">
##	<summary>
##	The role to be allowed the konqueror domain.
##	</summary>
## </param>
## <param name="terminal">
##	<summary>
##	The type of the role's terminal.
##	</summary>
## </param>
#
interface(`konqueror_run',`
	gen_require(`
		type konqueror_t;
	')

	konqueror_domtrans($1)
	role $2 types konqueror_t;
	dontaudit konqueror_t $3:chr_file rw_term_perms;
')


########################################
## <summary>
##	Send and receive messages from
##	konqueror over dbus.
## </summary>
## <param name="domain">
##	<summary>
##	Domain allowed access.
##	</summary>
## </param>
#
interface(`konqueror_dbus_chat',`
	gen_require(`
		type konqueror_t;
		class dbus send_msg;
	')

	allow $1 konqueror_t:dbus send_msg;
	allow konqueror_t $1:dbus send_msg;
')

########################################
## <summary>
##	All of the rules required to administrate 
##	an konqueror environment
## </summary>
## <param name="domain">
##	<summary>
##	Domain allowed access.
##	</summary>
## </param>
## <param name="role">
##	<summary>
##	The role to be allowed to manage the konqueror domain.
##	</summary>
## </param>
## <param name="terminal">
##	<summary>
##	The type of the user terminal.
##	</summary>
## </param>
## <rolecap/>
#
interface(`konqueror_admin',`
	gen_require(`
		type konqueror_t;
	')

	allow $1 konqueror_t:process { ptrace signal_perms getattr };
	read_files_pattern($1, konqueror_t, konqueror_t)
	        

	kde_manage_tmp($1)

	konqueror_manage_home($1)

')
-------------- next part --------------
policy_module(konqueror,0.1.0)

require {
        type unconfined_t;
        type unconfined_dbusd_t;
		type user_home_t;
		type kde_shared_tmp_t;
		type kde_shared_home_t;
		type bin_t;
}

########################################
#
# Declarations
#

type konqueror_t;
type konqueror_exec_t;
application_domain(konqueror_t, konqueror_exec_t)
role system_r types konqueror_t;

permissive konqueror_t;

type konqueror_home_t;
files_type(konqueror_home_t)

type konqueror_port_t;
corenet_port(konqueror_port_t)

########################################
#
# konqueror local policy
#

## internal communication is often done using fifo and unix sockets.
allow konqueror_t self:fifo_file rw_file_perms;
allow konqueror_t self:unix_stream_socket create_stream_socket_perms;

files_read_etc_files(konqueror_t)
# Use shared libs
libs_use_ld_so(konqueror_t)
libs_use_shared_libs(konqueror_t)
# Read localization
miscfiles_read_localization(konqueror_t)
# Allow reading font files
miscfiles_read_fonts(konqueror_t) 

# Temp acces from kde module
kde_manage_tmp(konqueror_t)
files_tmp_filetrans(konqueror_t,kde_shared_tmp_t, { file dir lnk_file sock_file })

# Full access to konqueror home
konqueror_manage_home(konqueror_t)

# For now manage kde_shared_home files and rw acces to dir and filetrans of created files
# In future with more other kde modules should be reduce to read only 
# or important files should be removed from kde_shared_home
kde_manage_home_files(konqueror_t)
# Needed so that konqueror_home_files in kde_shared_home_t dir wouldn't switch to dirs type 
files_kde_home_filetrans(konqueror_t, konqueror_home_t)

# Konqueror runs drkonqi (bin_t) We certainly dont wont to allow running anything in bin_t by 
# konqueror, so for now we wont audit that. Correct solution is to confine drkonqi.
dontaudit konqueror_t bin_t:file exec_file_perms;

dev_read_urand(konqueror_t) #/dev/urandom
files_read_usr_files(konqueror_t) #/usr
kernel_read_system_state(konqueror_t) #/proc
xserver_stream_connect_xdm_xserver(konqueror_t) #connect to xdm xserver
allow konqueror_t self:process getsched; # Get self process priority
fs_getattr_xattr_fs(konqueror_t) # extended atributes support

sysnet_dns_name_resolve(konqueror_t)
corenet_all_recvfrom_unlabeled(konqueror_t)

# Access to ports
allow konqueror_t self:tcp_socket create_stream_socket_perms;
corenet_tcp_sendrecv_all_if(konqueror_t)
corenet_tcp_sendrecv_all_nodes(konqueror_t)
corenet_tcp_sendrecv_all_ports(konqueror_t)
corenet_tcp_connect_ftp_data_port(konqueror_t)
corenet_tcp_connect_ftp_port(konqueror_t)
corenet_tcp_connect_http_port(konqueror_t)
corenet_tcp_connect_http_cache_port(konqueror_t)

# dbus needed to run
allow konqueror_t unconfined_dbusd_t:unix_stream_socket connectto;
allow konqueror_t unconfined_t:unix_stream_socket { read write connectto };
dbus_system_bus_unconfined(konqueror_t)
dbus_unconfined(konqueror_t)

optional_policy(`
	gen_require(`
		type staff_t;
		type staff_devpts_t;
		type staff_tty_device_t;
		role staff_r;
	')

	konqueror_run(staff_t, staff_r, { staff_tty_device_t staff_devpts_t })
')

optional_policy(`
	gen_require(`
		type unconfined_t;
		type unconfined_devpts_t;
		type unconfined_tty_device_t;
		role unconfined_r;
	')

	konqueror_run(unconfined_t, unconfined_r, { unconfined_tty_device_t unconfined_devpts_t })
')

optional_policy(`
	gen_require(`
		type user_t;
		type user_devpts_t;
		type user_tty_device_t;
		role user_r;
	')

	konqueror_run(user_t, user_r, { user_tty_device_t user_devpts_t })
')

# corecmd_bin_entry_type(konqueror_t) # ne

[refpolicy] Basic policy for KDE and Konqueror

[Dominick Grift]

On Wed, 2009-08-12 at 14:40 +0200, Nicky726 wrote:
> Hello,
> 
> as a part of my bachellor thesis I've made basic policy for KDE namely 
> Konqueror web browser. The resulting source files are enclosed to this e-mail. 
> 
> As KDE is complicated and interconnected environment, I chosed to create a 
> general module for KDE. The should be any rules concerning shared parts of KDE 
> policy. As an example may be context of ~/.kde, where configuration is stored, 
> and access rules of this files...
> 
> Than for every aplication which is to be confined, there should be one module 
> depending on the base KDE policy module. I choosed to confine Konqueror.
> 
> I tested this policy on Fedora 10 with KDE 4.2.4 and up-to-date.
> 
> I understand that policy I created is probabaly very rough and needs many 
> refinements. Would you please comment it, so I can make it better and maybe 
> actually useful for some people?
> 
> Thanks for your time, 

Hi, i will give you my personal view on some of your policies. Be aware
that i am a hobbyist so i might be wrong about some of this:

kde.fc
remove the file context specification for objects in /tmp and links to
objects in /tmp. /tmp is a filesystem for temporary objects. file
context specifications are to ensure that objects stay labeled properly.

http://domg444.blogspot.com/2007/11/why-files-with-incompatible-types-in.html

kde.te

Not much there:

use userdom_user_home_content for content in $home instead of files_type

How is kde going to be able to interact with and manage the objects it
owns in $home and $tmp?

konqueror.te
A .te file may not have require blocks. use calls to shared policy
instead.

this is a user app and should be run using the users role instead of
system_r. You should use a role template or a per role template instead
(refer to mozilla.if mozilla_role() for example)

konqueror is a permissive domain (permissive konqueror_t) this is not
good (permissive domain are for troubleshooting/development only)

use the userdom_user_home_content(konqueror_home_t) instead of
files_type() for objects in $home.

you should not need the files_tmp_filetrans for kde object in tmp
management. kde owns it and kde creates it. the process that creates it
owns it. so if konqueror_t creates files there then its owns them.

allowing konqueror to run bin_t isnt a big deal no need to dontaudit it.
keep you dontaudits to a minimum. corecmd_exec_bin()

use proper dbus interfaces (not dbus unconfined)

the konqueror_run interface calles should be replaced by
konqueror_role() calls. These calls do not belong there but they belong
in the user domain policy.

There are also some style issues.

Today i ported 3 user app policies to rawhide. these are policies for
simple text based applications. please have a look at the 3 policies and
compare them to eachother. See if you can find the similarities and try
to apply it to your policy.

http://82.197.205.60/~dgrift/stuff/modules/rawhide12/irssi.te
http://82.197.205.60/~dgrift/stuff/modules/rawhide12/irssi.if
http://82.197.205.60/~dgrift/stuff/modules/rawhide12/irssi.fc

http://82.197.205.60/~dgrift/stuff/modules/rawhide12/elinks.te
http://82.197.205.60/~dgrift/stuff/modules/rawhide12/elinks.if
http://82.197.205.60/~dgrift/stuff/modules/rawhide12/elinks.fc

http://82.197.205.60/~dgrift/stuff/modules/rawhide12/mutt.te
http://82.197.205.60/~dgrift/stuff/modules/rawhide12/mutt.if
http://82.197.205.60/~dgrift/stuff/modules/rawhide12/mutt.fc

you can also join us on irc.freenode.org at #selinux and #fedora-selinux
ill be happy to answer any questions that i can.

hth


> 
> Ond?ej Vadinsk?
> (Nicky726)
> _______________________________________________
> 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: 197 bytes
Desc: This is a digitally signed message part
Url : http://oss.tresys.com/pipermail/refpolicy/attachments/20090812/194cdc50/attachment.bin 

[refpolicy] Basic policy for KDE and Konqueror

[Nicky726]

Hello,

Dominick Grift wrote:
> kde.fc
> remove the file context specification for objects in /tmp and links to
> objects in /tmp. /tmp is a filesystem for temporary objects. file
> context specifications are to ensure that objects stay labeled properly.
> 
> http://domg444.blogspot.com/2007/11/why-files-with-incompatible-types-in.html

I understand that file context specification for /tmp are are wrong. How should 
I solve the problem of dividing KDE /tmp stuff from users for yet unconfined KDE 
applications, so that I don't have to allow confined KDE apps to read whole 
user_tmp_t? 

> kde.te
> 
> How is kde going to be able to interact with and manage the objects it
> owns in $home and $tmp?

I intended kde module to be a layer between unconfined zone and confined KDE 
applications. So if there are needs to read/write some files which belong to 
not yet confined KDE applications, I don't have to enable this for unconfined 
user_tmp_t or user_home_t. So I didn't intended kde module itself to do more 
than just hold its files context and provide interface for already confined KDE 
applications to work with theese files.

Thanks for your time.

Ondrej Vadinsky
(Nicky726)

-- 

"Don't it always seem to go
That you don't know what you've got
Till it's gone."

                                         (Joni Mitchell)

[refpolicy] Basic policy for KDE and Konqueror

[Mike Edenfield]

On 8/17/2009 10:40 AM, Nicky726 wrote:
> Hello,
>
> Dominick Grift wrote:
>> kde.fc
>> remove the file context specification for objects in /tmp and links to
>> objects in /tmp. /tmp is a filesystem for temporary objects. file
>> context specifications are to ensure that objects stay labeled properly.
>>
>> http://domg444.blogspot.com/2007/11/why-files-with-incompatible-types-in.html
>
> I understand that file context specification for /tmp are are wrong. How should
> I solve the problem of dividing KDE /tmp stuff from users for yet unconfined KDE
> applications, so that I don't have to allow confined KDE apps to read whole
> user_tmp_t?

Files in /tmp are handled at runtime by type transitions.  The 
applications create the tmp files with the correct context.  You'll need 
to set up TE rules for KDE's files /tmp, you just don't need to define 
them in the fc file.

You should have something like this in your TE rules (note that I 
haven't actually looked at your policy yet so you might already have 
this covered.. if so, that's all you need):

type kde_tmp_t;
files_tmp_file(kde_tmp_t)

manage_dirs_pattern(kde_t, kde_tmp_t, kde_tmp_t)
manage_files_pattern(kde_t, kde_tmp_t, kde_tmp_t)
files_tmp_filetrans(kde_t, kde_tmp_t, { file dir })

--Mike

[refpolicy] Basic policy for KDE and Konqueror

[Nicky726]

Helo,

I managed to implement almost all of your comments to KDE and Konqueror 
policy. Now I need to do some testing, which is where I got totaly stuck.

First to the konqueror_role(). I created this interface according to policy 
for mozilla, but i quite don't get it, where should I place the call itself. 
You mention userdomain policy:

Dne St 12. srpna 2009 20:58:03 Dominick Grift napsal(a):
> the konqueror_run interface calles should be replaced by
> konqueror_role() calls. These calls do not belong there but they belong
> in the user domain policy.

But I didn't find there much xxx_role() calls. More important I didn't find 
there any mozilla_role() which I take as a reference. When I looked through 
refpolicy sources I managed to find mozilla_role() and other xxx_role() calls 
in roles/unprivuser.te and other roles. So to where do these calls belong?

I am not sure, that I fully comprehend this situation concerning xxx_role() 
calls. I had interface konqueror_run() which was called in konqueror.te. This 
should now be replaced by konqueror_role() which I guess should do something 
similar, and be called where? What is it good for? And are there more changes 
needed so it worked? Could someone explain this more?

Now to the testing stuff. Til now I managed to test the modules against 
unmodified Fedora targeted policy. But with konqueror_role() calls there are 
some modifications needed. How to do it? I didn't have much luck with inserting 
changed modules to fedora policy, nor with compling what I hope was exact copy 
of fedora policy.

I also think, that this module should be tested against refpolicy-git 
shouldn't it? The problem with this is, that fedora didn't even booted with 
git refpolicy. How do you test the modules than? 


Thanks for the answers,
Ondrej Vadinsky

[refpolicy] Basic policy for KDE and Konqueror

[Dominick Grift]

On Thu, Aug 27, 2009 at 06:07:52PM +0200, Nicky726 wrote:
> Helo,
> 
> I managed to implement almost all of your comments to KDE and Konqueror 
> policy. Now I need to do some testing, which is where I got totaly stuck.
> 
> First to the konqueror_role(). I created this interface according to policy 
> for mozilla, but i quite don't get it, where should I place the call itself. 
> You mention userdomain policy:
> 
> Dne St 12. srpna 2009 20:58:03 Dominick Grift napsal(a):
> > the konqueror_run interface calles should be replaced by
> > konqueror_role() calls. These calls do not belong there but they belong
> > in the user domain policy.
> 
> But I didn't find there much xxx_role() calls. More important I didn't find 
> there any mozilla_role() which I take as a reference. When I looked through 
> refpolicy sources I managed to find mozilla_role() and other xxx_role() calls 
> in roles/unprivuser.te and other roles. So to where do these calls belong?

They usually go in Fedoras userdom.if in the right place. But for testing purposes you can add them to you .te file or you could make a separate myuserdom module.

policy_module(myuserdom, 0.0.1)
gen_require(`
		type unconfined_t;
	')

	kde_role(unconfined_r, unconfined_t)
')

> 
> I am not sure, that I fully comprehend this situation concerning xxx_role() 
> calls. I had interface konqueror_run() which was called in konqueror.te. This 
> should now be replaced by konqueror_role() which I guess should do something 
> similar, and be called where? What is it good for? And are there more changes 
> needed so it worked? Could someone explain this more?
> 
> Now to the testing stuff. Til now I managed to test the modules against 
> unmodified Fedora targeted policy. But with konqueror_role() calls there are 
> some modifications needed. How to do it? I didn't have much luck with inserting 
> changed modules to fedora policy, nor with compling what I hope was exact copy 
> of fedora policy.
> 
> I also think, that this module should be tested against refpolicy-git 
> shouldn't it? The problem with this is, that fedora didn't even booted with 
> git refpolicy. How do you test the modules than? 

Well start by making it work on Fedora, porting it to refpolicy should be reasonably easy.

> 
> 
> Thanks for the answers,
> Ondrej Vadinsky
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
Url : http://oss.tresys.com/pipermail/refpolicy/attachments/20090827/c0d16f0c/attachment.bin 

[refpolicy] Basic policy for KDE and Konqueror

[Dominick Grift]

On Thu, Aug 27, 2009 at 06:07:52PM +0200, Nicky726 wrote:
> Helo,
> 
> I managed to implement almost all of your comments to KDE and Konqueror 
> policy. Now I need to do some testing, which is where I got totaly stuck.
> 
> First to the konqueror_role(). I created this interface according to policy 
> for mozilla, but i quite don't get it, where should I place the call itself. 
> You mention userdomain policy:
> 
> Dne St 12. srpna 2009 20:58:03 Dominick Grift napsal(a):
> > the konqueror_run interface calles should be replaced by
> > konqueror_role() calls. These calls do not belong there but they belong
> > in the user domain policy.
> 
> But I didn't find there much xxx_role() calls. More important I didn't find 
> there any mozilla_role() which I take as a reference. When I looked through 
> refpolicy sources I managed to find mozilla_role() and other xxx_role() calls 
> in roles/unprivuser.te and other roles. So to where do these calls belong?
> 
> I am not sure, that I fully comprehend this situation concerning xxx_role() 
> calls. I had interface konqueror_run() which was called in konqueror.te. This 

The *_role template instantiate policy for the callers role. In selinux different users can have different roles and the *_role template makes it easier and more compact.

If you have different users youd have to write similar policy for easy user (unconfined,staff,user,guest,xguest) etc. with *_role you write the policy one-time and instantiate (call) that for the various users. (easier to maintain/ less policy to write)

> should now be replaced by konqueror_role() which I guess should do something 
> similar, and be called where? What is it good for? And are there more changes 
> needed so it worked? Could someone explain this more?
> 
> Now to the testing stuff. Til now I managed to test the modules against 
> unmodified Fedora targeted policy. But with konqueror_role() calls there are 
> some modifications needed. How to do it? I didn't have much luck with inserting 
> changed modules to fedora policy, nor with compling what I hope was exact copy 
> of fedora policy.
> 
> I also think, that this module should be tested against refpolicy-git 
> shouldn't it? The problem with this is, that fedora didn't even booted with 
> git refpolicy. How do you test the modules than? 
> 
> 
> Thanks for the answers,
> Ondrej Vadinsky
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
Url : http://oss.tresys.com/pipermail/refpolicy/attachments/20090827/dcbb23e0/attachment.bin 

[refpolicy] Basic policy for KDE and Konqueror

[Nicky726]

Hello,

I've been reviewing and testing my policy for Konqueror according to Dominick 
Grift's comments. Now I've got confused with the dbus affair:

Dne St 12. srpna 2009 20:58:03 Dominick Grift napsal(a): 
> use proper dbus interfaces (not dbus unconfined)

The thing is that Konqueror starts only with dbus_unconfined(). If I use 
dbus_system_bus_client() I got message, that Konqueror can't be registered 
with dbus, as there is already another one registered. If I use 
dbus_session_bus_client() I got absolutely no output. In both cases Konqueror 
won't start and no AVC denials are displayed.

As I looked into Evolution and Mozilla policies sources, there are only this 
two interfaces used. Are there some other steps needed for it to work? Or is 
there some better suited interfaces? Do you have other suggestions?

Thanks for your time,
Ondrej Vadinsky

-- 
Don`t it always seem to go
That you don`t know what you`ve got
Till it`s gone.

		(Joni Mitchell)

[refpolicy] Basic policy for KDE and Konqueror

[Dominick Grift]

On Thu, Sep 03, 2009 at 10:15:23PM +0200, Nicky726 wrote:
> Hello,
> 
> I've been reviewing and testing my policy for Konqueror according to Dominick 
> Grift's comments. Now I've got confused with the dbus affair:
> 
> Dne St 12. srpna 2009 20:58:03 Dominick Grift napsal(a): 
> > use proper dbus interfaces (not dbus unconfined)
> 
> The thing is that Konqueror starts only with dbus_unconfined(). If I use 
> dbus_system_bus_client() I got message, that Konqueror can't be registered 
> with dbus, as there is already another one registered. If I use 
> dbus_session_bus_client() I got absolutely no output. In both cases Konqueror 
> won't start and no AVC denials are displayed.
> 
> As I looked into Evolution and Mozilla policies sources, there are only this 
> two interfaces used. Are there some other steps needed for it to work? Or is 
> there some better suited interfaces? Do you have other suggestions?
dbus policy is a bit "underdeveloped". are you looking in the right places for avc denials?

ausearch -m user_avc -ts today
grep -i dbus /var/log/messages

dbus throws its denials all around the place. some stuff goes to audit.log other stuff goes to messages.

can you show us your dbus related avc denials?
> 
> Thanks for your time,
> Ondrej Vadinsky
> 
> -- 
> Don`t it always seem to go
> That you don`t know what you`ve got
> Till it`s gone.
> 
> 		(Joni Mitchell)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
Url : http://oss.tresys.com/pipermail/refpolicy/attachments/20090903/1ebc3803/attachment.bin 

[refpolicy] Basic policy for KDE and Konqueror

[Christopher J. PeBenito]

On Wed, 2009-08-12 at 14:40 +0200, Nicky726 wrote:
> as a part of my bachellor thesis I've made basic policy for KDE namely 
> Konqueror web browser. The resulting source files are enclosed to this e-mail. 
> 
> As KDE is complicated and interconnected environment, I chosed to create a 
> general module for KDE. The should be any rules concerning shared parts of KDE 
> policy. As an example may be context of ~/.kde, where configuration is stored, 
> and access rules of this files...
> 
> Than for every aplication which is to be confined, there should be one module 
> depending on the base KDE policy module. I choosed to confine Konqueror.
> 
> I tested this policy on Fedora 10 with KDE 4.2.4 and up-to-date.
> 
> I understand that policy I created is probabaly very rough and needs many 
> refinements. Would you please comment it, so I can make it better and maybe 
> actually useful for some people?

The use of types is generally good.  Depending on your security goals
you may want more separation for users/roles.  For example you could use
TE: user_kde_home_t, staff_kde_home_t, etc. or UBAC:
ubac_confined(kde_home_t).  Without these, only DAC separates the
users/roles.

If you're looking to get these into upstream refpolicy, you need to
follow the reference policy style.  Having require blocks such as these:

optional_policy(`
        gen_require(`
                type staff_t;
                type staff_devpts_t;
                type staff_tty_device_t;
                role staff_r;
        ')

        konqueror_run(staff_t, staff_r, { staff_tty_device_t staff_devpts_t })
')

is not acceptable in refpolicy.  In addition, the interface calls in in
the konqueror.te need to be reorganized.

-- 
Chris PeBenito
Tresys Technology, LLC
(410) 290-1411 x150