2009-08-12 12:40:20

by nicky726

[permalink] [raw]
Subject: [refpolicy] Basic policy for KDE and Konqueror

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


2009-08-12 18:58:03

by domg472

[permalink] [raw]
Subject: [refpolicy] Basic policy for KDE and Konqueror

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

2009-08-14 17:37:02

by cpebenito

[permalink] [raw]
Subject: [refpolicy] Basic policy for KDE and Konqueror

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

2009-08-17 14:40:49

by nicky726

[permalink] [raw]
Subject: [refpolicy] Basic policy for KDE and Konqueror

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)

2009-08-17 15:01:24

by Mike Edenfield

[permalink] [raw]
Subject: [refpolicy] Basic policy for KDE and Konqueror

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

2009-08-27 16:07:52

by nicky726

[permalink] [raw]
Subject: [refpolicy] Basic policy for KDE and Konqueror

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

2009-08-27 16:42:38

by domg472

[permalink] [raw]
Subject: [refpolicy] Basic policy for KDE and Konqueror

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

2009-08-27 16:47:04

by domg472

[permalink] [raw]
Subject: [refpolicy] Basic policy for KDE and Konqueror

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

2009-09-03 20:15:23

by nicky726

[permalink] [raw]
Subject: [refpolicy] Basic policy for KDE and Konqueror

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)

2009-09-03 20:36:17

by domg472

[permalink] [raw]
Subject: [refpolicy] Basic policy for KDE and Konqueror

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