8:02 p.m.
Hello:
Would it be possible for the SELinux team at Red Hat to create an
SELinux policy module for Google Earth and to show the step by step
process for confining the application? I think these kind of examples
would be useful to developers attempting to create SELinux policies
for other rpm packages out there. I'm not interested so much in the
actual policy module, but in creating it myself from step-by-step
instructions. IMHO, that would be the best way to educate developers
on how to use SELinux.
Thanks,
Benjy
8:45 a.m.
Benjy Grogan wrote:
Hello:
Would it be possible for the SELinux team at Red Hat to create an
SELinux policy module for Google Earth and to show the step by step
process for confining the application? I think these kind of examples
would be useful to developers attempting to create SELinux policies
for other rpm packages out there. I'm not interested so much in the
actual policy module, but in creating it myself from step-by-step
instructions. IMHO, that would be the best way to educate developers
on how to use SELinux.
Google-earth is not the best example of this but
The way I would go about it would be to first use policygentool to
create my initial fc/if/te files
#cd /tmp
#mkdir googlearth
#cd googleearth
STEP 1
#policygentool googlearth /usr/local/google-earth/googleearth-bin
answer some questions to the best of my ability
STEP2
add the following lines to the te file to cause the transition form
uncofined_t to googleearth
cat >> googleearth.te << __EOF
gen_require(`
type unconfined_t;
')
domain_auto_trans(uncofined_t, googleearth_exec_t, googleearth_t)
__EOF
STEP 3
# make -f /usr/share/selinux/devel/Makefile
# semodule -i googleearth.pp
# setenforce 0
In a different window as a normal user
googleearth
Test out lots of stuff
Go back to the original root window
grep googleearth /var/log/messages (or /var/log/audit/audit.log) |
audit2allow -R
Analyze these rules and macros to the best of my ability and add them to
the te file
GOTO STEP 3
Thanks,
Benjy
--
fedora-selinux-list mailing list
fedora-selinux-list(a)redhat.com
https://www.redhat.com/mailman/listinfo/fedora-selinux-list
12:03 a.m.
Hello:
On 6/15/06, Daniel J Walsh <dwalsh(a)redhat.com> wrote:
Benjy Grogan wrote:
> Hello:
>
> Would it be possible for the SELinux team at Red Hat to create an
> SELinux policy module for Google Earth and to show the step by step
> process for confining the application? I think these kind of examples
> would be useful to developers attempting to create SELinux policies
> for other rpm packages out there. I'm not interested so much in the
> actual policy module, but in creating it myself from step-by-step
> instructions. IMHO, that would be the best way to educate developers
> on how to use SELinux.
>
Google-earth is not the best example of this but
The way I would go about it would be to first use policygentool to
create my initial fc/if/te files
#cd /tmp
#mkdir googlearth
#cd googleearth
STEP 1
#policygentool googlearth /usr/local/google-earth/googleearth-bin
answer some questions to the best of my ability
I answered the questions, but I had little idea as to what pidfiles
were. As for logs, Google Earth doesn't use /var/log but I know it
must log something in ~/.googleearth. That would be a directory that
depends on which user is at the moment using Google Earth. There's
probably a better way of specifying this after running policygentool.
I didn't know if there were any /var/lib files, so I left that alone.
The module didn't have an init script, which is used by
daemons/services, right? The module will be a heavy user of the
network, so that was answered yes, but further restricting Google
Earth's network access would be useful, such as no access 192.168.x.x.
STEP2
add the following lines to the te file to cause the transition form
uncofined_t to googleearth
cat >> googleearth.te << __EOF
gen_require(`
type unconfined_t;
')
First time I've seen ` and ' used.
domain_auto_trans(uncofined_t, googleearth_exec_t, googleearth_t)
__EOF
STEP 3
# make -f /usr/share/selinux/devel/Makefile
# semodule -i googleearth.pp
# setenforce 0
In a different window as a normal user
> googleearth
Test out lots of stuff
There was a strange problem with Google Earth images not being able to
be pasted into GIMP but able to to be pasted into KolourPaint. I
removed the module using:
# /usr/sbin/semodule --remove=googleearth
libsepol.sepol_genbools_array: boolean googleearth_disable_trans no
longer in policy
... and discovered the problem had nothing to do with SELinux.
Go back to the original root window
grep googleearth /var/log/messages (or /var/log/audit/audit.log) |
audit2allow -R
Analyze these rules and macros to the best of my ability and add them to
the te file
The result from this was:
# grep googleearth /var/log/messages | audit2allow -R
/usr/bin/audit2allow: No AVC messages found.
GOTO STEP 3
So going back to step 3 wouldn't improve the policy. How could I
further restrict the policy module so that I could perhaps generate
some AVC messages? Two things I would like to do with the policy are
:
1) Restrict Google Earth's file access, so that it can only read/write
to .googleearth and read/write to ~/images (a directory available on
my acccount, but maybe not others. if no /images directory available
then do nothing). In fact all other user accounts do not have
.googleearth or ~/images, so they would have to be created.
2) Restrict Google Earth's network access, so that it can't access my
local network at 192.168.x.x, or other local services.
Is this possible? It might be a bit extreme but I'm interested in
restricting this proprietary application's access to the bare minimum.
For fun mostly.
Benjy
PS: As I add or remove the googleearth policy module using semodule,
is this affected by booting up and is it dependent on which kernel
2.6.16.x I'm using?
> Thanks,
> Benjy
>
> --
> fedora-selinux-list mailing list
> fedora-selinux-list(a)redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-selinux-list
5:14 a.m.
Benjy Grogan wrote:
Hello:
On 6/15/06, Daniel J Walsh <dwalsh(a)redhat.com> wrote:
> Benjy Grogan wrote:
> > Hello:
> >
> > Would it be possible for the SELinux team at Red Hat to create an
> > SELinux policy module for Google Earth and to show the step by step
> > process for confining the application? I think these kind of examples
> > would be useful to developers attempting to create SELinux policies
> > for other rpm packages out there. I'm not interested so much in the
> > actual policy module, but in creating it myself from step-by-step
> > instructions. IMHO, that would be the best way to educate developers
> > on how to use SELinux.
> >
> Google-earth is not the best example of this but
>
> The way I would go about it would be to first use policygentool to
> create my initial fc/if/te files
>
> #cd /tmp
> #mkdir googlearth
> #cd googleearth
> STEP 1
> #policygentool googlearth /usr/local/google-earth/googleearth-bin
> answer some questions to the best of my ability
I answered the questions, but I had little idea as to what pidfiles
were. As for logs, Google Earth doesn't use /var/log but I know it
must log something in ~/.googleearth. That would be a directory that
depends on which user is at the moment using Google Earth. There's
probably a better way of specifying this after running policygentool.
I didn't know if there were any /var/lib files, so I left that alone.
The module didn't have an init script, which is used by
daemons/services, right? The module will be a heavy user of the
network, so that was answered yes, but further restricting Google
Earth's network access would be useful, such as no access 192.168.x.x.
> STEP2
> add the following lines to the te file to cause the transition form
> uncofined_t to googleearth
> cat >> googleearth.te << __EOF
> gen_require(`
> type unconfined_t;
> ')
First time I've seen ` and ' used.
> domain_auto_trans(uncofined_t, googleearth_exec_t, googleearth_t)
This should
be unconfined_t.
>
> __EOF
> STEP 3
> # make -f /usr/share/selinux/devel/Makefile
> # semodule -i googleearth.pp
>
> # setenforce 0
> In a different window as a normal user
> > googleearth
> Test out lots of stuff
There was a strange problem with Google Earth images not being able to
be pasted into GIMP but able to to be pasted into KolourPaint. I
removed the module using:
# /usr/sbin/semodule --remove=googleearth
libsepol.sepol_genbools_array: boolean googleearth_disable_trans no
longer in policy
... and discovered the problem had nothing to do with SELinux.
> Go back to the original root window
>
> grep googleearth /var/log/messages (or /var/log/audit/audit.log) |
> audit2allow -R
> Analyze these rules and macros to the best of my ability and add them to
> the te file
The result from this was:
# grep googleearth /var/log/messages | audit2allow -R
/usr/bin/audit2allow: No AVC messages found.
I don't think you transitioned. You should check which context you ran
googleearth in with the ps command
ps -eZ | grep google
> GOTO STEP 3
p
So going back to step 3 wouldn't improve the policy. How could I
further restrict the policy module so that I could perhaps generate
some AVC messages? Two things I would like to do with the policy are
:
1) Restrict Google Earth's file access, so that it can only read/write
to .googleearth and read/write to ~/images (a directory available on
my acccount, but maybe not others. if no /images directory available
then do nothing). In fact all other user accounts do not have
.googleearth or ~/images, so they would have to be created.
You can define file context for these directories. You could create a
googleearth_rw_t and define it to ~/images and .googlearth.
If you grab the policy src rpm and take a look at the mozilla context it
will give you an idea.
2) Restrict Google Earth's network access, so that it can't
access my
local network at 192.168.x.x, or other local services.
I believe you can do this but it is fairly complicated, There is work
going on to tie SELinux and iptables closer together to make this easier.
me but I'm interested in
restricting this proprietary application's access to the bare minimum.
For fun mostly.
Benjy
PS: As I add or remove the googleearth policy module using semodule,
is this affected by booting up and is it dependent on which kernel
2.6.16.x I'm using?
Independent. semodule recomposes the policy file on disk, and init just
reads the new policy file. So the change is permanent and
all SELinux kernels would use the policy
>
> > Thanks,
> > Benjy
> >
> > --
> > fedora-selinux-list mailing list
> > fedora-selinux-list(a)redhat.com
> > https://www.redhat.com/mailman/listinfo/fedora-selinux-list
>
>
10:14 p.m.
On 6/17/06, Daniel J Walsh <dwalsh(a)redhat.com> wrote:
Benjy Grogan wrote:
> Hello:
>
> On 6/15/06, Daniel J Walsh <dwalsh(a)redhat.com> wrote:
>> Benjy Grogan wrote:
>> > Hello:
>> >
>> > Would it be possible for the SELinux team at Red Hat to create an
>> > SELinux policy module for Google Earth and to show the step by step
>> > process for confining the application? I think these kind of examples
>> > would be useful to developers attempting to create SELinux policies
>> > for other rpm packages out there. I'm not interested so much in the
>> > actual policy module, but in creating it myself from step-by-step
>> > instructions. IMHO, that would be the best way to educate developers
>> > on how to use SELinux.
>> >
>> Google-earth is not the best example of this but
>>
>> The way I would go about it would be to first use policygentool to
>> create my initial fc/if/te files
>>
>> #cd /tmp
>> #mkdir googlearth
>> #cd googleearth
>> STEP 1
>> #policygentool googlearth /usr/local/google-earth/googleearth-bin
>> answer some questions to the best of my ability
>
> I answered the questions, but I had little idea as to what pidfiles
> were. As for logs, Google Earth doesn't use /var/log but I know it
> must log something in ~/.googleearth. That would be a directory that
> depends on which user is at the moment using Google Earth. There's
> probably a better way of specifying this after running policygentool.
>
> I didn't know if there were any /var/lib files, so I left that alone.
> The module didn't have an init script, which is used by
> daemons/services, right? The module will be a heavy user of the
> network, so that was answered yes, but further restricting Google
> Earth's network access would be useful, such as no access 192.168.x.x.
>
>> STEP2
>> add the following lines to the te file to cause the transition form
>> uncofined_t to googleearth
>> cat >> googleearth.te << __EOF
>> gen_require(`
>> type unconfined_t;
>> ')
>
> First time I've seen ` and ' used.
>
>> domain_auto_trans(uncofined_t, googleearth_exec_t, googleearth_t)
This should be unconfined_t.
I had made this change. I was avoiding the policy completely by using
/usr/local/google-earth/googleearth instead of
/usr/local/google-earth/googleearth-bin.
When I do run googleearth-bin I get:
$ /usr/local/google-earth/googleearth-bin
/usr/local/google-earth/googleearth-bin: error while loading shared
libraries: ./libcomponent.so: cannot open shared object file: No such
file or directory
There are currently these shared libraries to take care of:
# ls /usr/local/google-earth/lib
libauth.so libgooglesearch.so libmeasure.so
libbase.so libgps.so libmng.so.1
libbasicIngest.so libIGAttrs.so libnavigate.so
libcollada.so libIGCollision.so libnet.so
libcommon.so libIGCore.so libpng12.so.0
libcomponent.so libIGDisplay.so libqt-mt.so.3
libcrypto.so.0.9.8 libIGExportCommon.so libqui.so.1
libcurl.so.3 libIGGfx.so librender.so
libevll.so libIGGui.so libssl.so.0.9.8
libframework.so libIGMath.so libstdc++.so.6
libfreeimage.so.3 libIGOpt.so libtiff.so.3
libfusion.so libIGSg.so libtweak.so
libgcc_s.so.1 libIGUtils.so libwebbrowser.so
libgeobase.so libjpeg.so.62 libwmsbase.so
libGLU.so.1 liblayer.so libz.so.1
libgoogleearth.so libmath.so
I included libcomponent.so when policygentool asks for any /var/lib
libraries, so it's listed in googleearth.fc as
/usr/local/google-earth/libcomponent.so gen_context(system_u:object_r:googleearth_var_lib_t,s0)
Not sure if this is the right way to go about it, because afterwards I
get the exact same message about libcomponent.so, and I'm sure every
other shared library is inaccessible too. How could I go about
allowing access to these shared libraries?
Benjy
>>
>> __EOF
>> STEP 3
>> # make -f /usr/share/selinux/devel/Makefile
>> # semodule -i googleearth.pp
>>
>> # setenforce 0
>> In a different window as a normal user
>> > googleearth
>> Test out lots of stuff
>
> There was a strange problem with Google Earth images not being able to
> be pasted into GIMP but able to to be pasted into KolourPaint. I
> removed the module using:
>
> # /usr/sbin/semodule --remove=googleearth
> libsepol.sepol_genbools_array: boolean googleearth_disable_trans no
> longer in policy
>
> ... and discovered the problem had nothing to do with SELinux.
>
>> Go back to the original root window
>>
>> grep googleearth /var/log/messages (or /var/log/audit/audit.log) |
>> audit2allow -R
>> Analyze these rules and macros to the best of my ability and add them to
>> the te file
>
> The result from this was:
>
> # grep googleearth /var/log/messages | audit2allow -R
> /usr/bin/audit2allow: No AVC messages found.
>
I don't think you transitioned. You should check which context you ran
googleearth in with the ps command
ps -eZ | grep google
>> GOTO STEP 3
> p
> So going back to step 3 wouldn't improve the policy. How could I
> further restrict the policy module so that I could perhaps generate
> some AVC messages? Two things I would like to do with the policy are
> :
>
> 1) Restrict Google Earth's file access, so that it can only read/write
> to .googleearth and read/write to ~/images (a directory available on
> my acccount, but maybe not others. if no /images directory available
> then do nothing). In fact all other user accounts do not have
> .googleearth or ~/images, so they would have to be created.
>
You can define file context for these directories. You could create a
googleearth_rw_t and define it to ~/images and .googlearth.
If you grab the policy src rpm and take a look at the mozilla context it
will give you an idea.
> 2) Restrict Google Earth's network access, so that it can't access my
> local network at 192.168.x.x, or other local services.
>
I believe you can do this but it is fairly complicated, There is work
going on to tie SELinux and iptables closer together to make this easier.
> me but I'm interested in
> restricting this proprietary application's access to the bare minimum.
> For fun mostly.
>
> Benjy
>
> PS: As I add or remove the googleearth policy module using semodule,
> is this affected by booting up and is it dependent on which kernel
> 2.6.16.x I'm using?
>
Independent. semodule recomposes the policy file on disk, and init just
reads the new policy file. So the change is permanent and
all SELinux kernels would use the policy
>
>
>>
>> > Thanks,
>> > Benjy
>> >
>> > --
>> > fedora-selinux-list mailing list
>> > fedora-selinux-list(a)redhat.com
>> > https://www.redhat.com/mailman/listinfo/fedora-selinux-list
>>
>>
9:06 a.m.
Benjy Grogan wrote:
On 6/17/06, Daniel J Walsh <dwalsh(a)redhat.com> wrote:
> Benjy Grogan wrote:
> > Hello:
> >
> > On 6/15/06, Daniel J Walsh <dwalsh(a)redhat.com> wrote:
> >> Benjy Grogan wrote:
> >> > Hello:
> >> >
> >> > Would it be possible for the SELinux team at Red Hat to create an
> >> > SELinux policy module for Google Earth and to show the step by step
> >> > process for confining the application? I think these kind of
> examples
> >> > would be useful to developers attempting to create SELinux policies
> >> > for other rpm packages out there. I'm not interested so much in
> the
> >> > actual policy module, but in creating it myself from step-by-step
> >> > instructions. IMHO, that would be the best way to educate
> developers
> >> > on how to use SELinux.
> >> >
> >> Google-earth is not the best example of this but
> >>
> >> The way I would go about it would be to first use policygentool to
> >> create my initial fc/if/te files
> >>
> >> #cd /tmp
> >> #mkdir googlearth
> >> #cd googleearth
> >> STEP 1
> >> #policygentool googlearth /usr/local/google-earth/googleearth-bin
> >> answer some questions to the best of my ability
> >
> > I answered the questions, but I had little idea as to what pidfiles
> > were. As for logs, Google Earth doesn't use /var/log but I know it
> > must log something in ~/.googleearth. That would be a directory that
> > depends on which user is at the moment using Google Earth. There's
> > probably a better way of specifying this after running policygentool.
> >
> > I didn't know if there were any /var/lib files, so I left that alone.
> > The module didn't have an init script, which is used by
> > daemons/services, right? The module will be a heavy user of the
> > network, so that was answered yes, but further restricting Google
> > Earth's network access would be useful, such as no access 192.168.x.x.
> >
> >> STEP2
> >> add the following lines to the te file to cause the transition form
> >> uncofined_t to googleearth
> >> cat >> googleearth.te << __EOF
> >> gen_require(`
> >> type unconfined_t;
> >> ')
> >
> > First time I've seen ` and ' used.
> >
> >> domain_auto_trans(uncofined_t, googleearth_exec_t, googleearth_t)
> This should be unconfined_t.
I had made this change. I was avoiding the policy completely by using
/usr/local/google-earth/googleearth instead of
/usr/local/google-earth/googleearth-bin.
When I do run googleearth-bin I get:
$ /usr/local/google-earth/googleearth-bin
/usr/local/google-earth/googleearth-bin: error while loading shared
libraries: ./libcomponent.so: cannot open shared object file: No such
file or directory
You should be running in permissive mode and translating avc messages to
allow rules via
audit2allow -R -i /var/log/messages
There are currently these shared libraries to take care of:
# ls /usr/local/google-earth/lib
libauth.so libgooglesearch.so libmeasure.so
libbase.so libgps.so libmng.so.1
libbasicIngest.so libIGAttrs.so libnavigate.so
libcollada.so libIGCollision.so libnet.so
libcommon.so libIGCore.so libpng12.so.0
libcomponent.so libIGDisplay.so libqt-mt.so.3
libcrypto.so.0.9.8 libIGExportCommon.so libqui.so.1
libcurl.so.3 libIGGfx.so librender.so
libevll.so libIGGui.so libssl.so.0.9.8
libframework.so libIGMath.so libstdc++.so.6
libfreeimage.so.3 libIGOpt.so libtiff.so.3
libfusion.so libIGSg.so libtweak.so
libgcc_s.so.1 libIGUtils.so libwebbrowser.so
libgeobase.so libjpeg.so.62 libwmsbase.so
libGLU.so.1 liblayer.so libz.so.1
libgoogleearth.so libmath.so
I included libcomponent.so when policygentool asks for any /var/lib
libraries, so it's listed in googleearth.fc as
/usr/local/google-earth/libcomponent.so
gen_context(system_u:object_r:googleearth_var_lib_t,s0)
No you do not want to do this.
Not sure if this is the right way to go about it, because afterwards
I
get the exact same message about libcomponent.so, and I'm sure every
other shared library is inaccessible too. How could I go about
allowing access to these shared libraries?
Benjy
> >>
> >> __EOF
> >> STEP 3
> >> # make -f /usr/share/selinux/devel/Makefile
> >> # semodule -i googleearth.pp
> >>
> >> # setenforce 0
> >> In a different window as a normal user
> >> > googleearth
> >> Test out lots of stuff
> >
> > There was a strange problem with Google Earth images not being able to
> > be pasted into GIMP but able to to be pasted into KolourPaint. I
> > removed the module using:
> >
> > # /usr/sbin/semodule --remove=googleearth
> > libsepol.sepol_genbools_array: boolean googleearth_disable_trans no
> > longer in policy
> >
> > ... and discovered the problem had nothing to do with SELinux.
> >
> >> Go back to the original root window
> >>
> >> grep googleearth /var/log/messages (or /var/log/audit/audit.log) |
> >> audit2allow -R
> >> Analyze these rules and macros to the best of my ability and add
> them to
> >> the te file
> >
> > The result from this was:
> >
> > # grep googleearth /var/log/messages | audit2allow -R
> > /usr/bin/audit2allow: No AVC messages found.
> >
> I don't think you transitioned. You should check which context you ran
> googleearth in with the ps command
>
> ps -eZ | grep google
> >> GOTO STEP 3
> > p
> > So going back to step 3 wouldn't improve the policy. How could I
> > further restrict the policy module so that I could perhaps generate
> > some AVC messages? Two things I would like to do with the policy are
> > :
> >
> > 1) Restrict Google Earth's file access, so that it can only read/write
> > to .googleearth and read/write to ~/images (a directory available on
> > my acccount, but maybe not others. if no /images directory available
> > then do nothing). In fact all other user accounts do not have
> > .googleearth or ~/images, so they would have to be created.
> >
> You can define file context for these directories. You could create a
> googleearth_rw_t and define it to ~/images and .googlearth.
> If you grab the policy src rpm and take a look at the mozilla context it
> will give you an idea.
>
> > 2) Restrict Google Earth's network access, so that it can't access my
> > local network at 192.168.x.x, or other local services.
> >
> I believe you can do this but it is fairly complicated, There is work
> going on to tie SELinux and iptables closer together to make this
> easier.
> > me but I'm interested in
> > restricting this proprietary application's access to the bare minimum.
> > For fun mostly.
> >
> > Benjy
> >
> > PS: As I add or remove the googleearth policy module using semodule,
> > is this affected by booting up and is it dependent on which kernel
> > 2.6.16.x I'm using?
> >
> Independent. semodule recomposes the policy file on disk, and init just
> reads the new policy file. So the change is permanent and
> all SELinux kernels would use the policy
> >
> >
> >>
> >> > Thanks,
> >> > Benjy
> >> >
> >> > --
> >> > fedora-selinux-list mailing list
> >> > fedora-selinux-list(a)redhat.com
> >> > https://www.redhat.com/mailman/listinfo/fedora-selinux-list
> >>
> >>
>
>
12:46 a.m.
On 6/19/06, Daniel J Walsh <dwalsh(a)redhat.com> wrote:
Benjy Grogan wrote:
> On 6/17/06, Daniel J Walsh <dwalsh(a)redhat.com> wrote:
>> Benjy Grogan wrote:
>> > Hello:
>> >
>> > On 6/15/06, Daniel J Walsh <dwalsh(a)redhat.com> wrote:
>> >> Benjy Grogan wrote:
>> >> > Hello:
>> >> >
>> >> > Would it be possible for the SELinux team at Red Hat to create an
>> >> > SELinux policy module for Google Earth and to show the step by
step
>> >> > process for confining the application? I think these kind of
>> examples
>> >> > would be useful to developers attempting to create SELinux
policies
>> >> > for other rpm packages out there. I'm not interested so much
in
>> the
>> >> > actual policy module, but in creating it myself from step-by-step
>> >> > instructions. IMHO, that would be the best way to educate
>> developers
>> >> > on how to use SELinux.
>> >> >
>> >> Google-earth is not the best example of this but
>> >>
>> >> The way I would go about it would be to first use policygentool to
>> >> create my initial fc/if/te files
>> >>
>> >> #cd /tmp
>> >> #mkdir googlearth
>> >> #cd googleearth
>> >> STEP 1
>> >> #policygentool googlearth /usr/local/google-earth/googleearth-bin
>> >> answer some questions to the best of my ability
>> >
>> > I answered the questions, but I had little idea as to what pidfiles
>> > were. As for logs, Google Earth doesn't use /var/log but I know it
>> > must log something in ~/.googleearth. That would be a directory that
>> > depends on which user is at the moment using Google Earth. There's
>> > probably a better way of specifying this after running policygentool.
>> >
>> > I didn't know if there were any /var/lib files, so I left that alone.
>> > The module didn't have an init script, which is used by
>> > daemons/services, right? The module will be a heavy user of the
>> > network, so that was answered yes, but further restricting Google
>> > Earth's network access would be useful, such as no access 192.168.x.x.
>> >
>> >> STEP2
>> >> add the following lines to the te file to cause the transition form
>> >> uncofined_t to googleearth
>> >> cat >> googleearth.te << __EOF
>> >> gen_require(`
>> >> type unconfined_t;
>> >> ')
>> >
>> > First time I've seen ` and ' used.
>> >
>> >> domain_auto_trans(uncofined_t, googleearth_exec_t, googleearth_t)
>> This should be unconfined_t.
>
> I had made this change. I was avoiding the policy completely by using
> /usr/local/google-earth/googleearth instead of
> /usr/local/google-earth/googleearth-bin.
>
> When I do run googleearth-bin I get:
>
> $ /usr/local/google-earth/googleearth-bin
> /usr/local/google-earth/googleearth-bin: error while loading shared
> libraries: ./libcomponent.so: cannot open shared object file: No such
> file or directory
>
You should be running in permissive mode and translating avc messages to
allow rules via
audit2allow -R -i /var/log/messages
Okay, I created a policy from audit2allow and used as many macros as I
could where it made sense. Below I have the TE file that I wrote.
This policy works fine with setenforce 0 and doesn't generate many
AVCs at all anymore, except when I navigate outside of the user's home
directory when saving or opening a jpeg, and I've auditdenied some of
that stuff. But when I turn enforcing on, setenforce 1, I get this
error:
$ googleearth
Xlib: connection to ":0.0" refused by server
Xlib: No protocol specified
There are no AVCs to be found in /var/log/messages. I figured these
lines should've handled any X server issues:
# XServer set-up
xserver_use_xdm_fds(googleearth_t)
xserver_stream_connect_xdm(googleearth_t)
... but they don't.
So my Google Earth policy works in permissive mode but fails in
enforcing mode without any AVCs to explain why not. Do you know how
to fix this? Here's the TE I wrote:
policy_module(googleearth,1.0.7)
########################################
#
# Declarations
#
type googleearth_t;
type googleearth_exec_t;
domain_type(googleearth_t)
init_daemon_domain(googleearth_t, googleearth_exec_t)
########################################
#
# googleearth local policy
#
# Check in /etc/selinux/refpolicy/include for macros to use instead of
allow rules.
# Some common macros (you might be able to remove some)
files_read_etc_files(googleearth_t)
libs_use_ld_so(googleearth_t)
libs_use_shared_libs(googleearth_t)
miscfiles_read_localization(googleearth_t)
## internal communication is often done using fifo and unix sockets.
allow googleearth_t self:fifo_file { getattr read write };
allow googleearth_t self:unix_stream_socket create_stream_socket_perms;
allow googleearth_t self:tcp_socket { connect create getopt read write };
allow googleearth_t self:udp_socket { connect create getattr read write };
# Init script handling
init_use_fds(googleearth_t)
init_use_script_ptys(googleearth_t)
domain_use_interactive_fds(googleearth_t)
gen_require(`
type unconfined_t;
')
domain_auto_trans(unconfined_t, googleearth_exec_t, googleearth_t)
# XServer set-up
xserver_use_xdm_fds(googleearth_t)
xserver_stream_connect_xdm(googleearth_t)
# var_t stuff
gen_require(`
type var_t;
')
allow googleearth_t var_t:file { getattr read };
# Connect to the unconfined domain using a unix domain stream socket.
unconfined_stream_connect(googleearth_t)
# Send and receive messages from an unlabeled IPSEC association.
kernel_sendrecv_unlabeled_association(googleearth_t)
allow googleearth_t devpts_t:chr_file { read write };
dev_rw_dri(googleearth_t)
# DISK ACCESS
# allow reading of libcomponent.so et al in /usr/local/
allow googleearth_t usr_t:file { read execute getattr };
allow googleearth_t usr_t:lnk_file read;
# allow access to .googleearth in home directory
gen_require(`
type user_home_dir_t;
type user_home_t;
type home_root_t;
')
allow googleearth_t user_home_dir_t:dir { getattr search read write };
allow googleearth_t user_home_dir_t:file getattr;
allow googleearth_t user_home_t:dir { add_name getattr remove_name
search read write };
allow googleearth_t user_home_t:file { append getattr lock read write };
allow googleearth_t user_home_t:lnk_file { create read unlink };
# don't create AVCs outside of the user's home directory
auditdeny googleearth_t home_root_t:dir { getattr search };
# get extended attributes on files
fs_getattr_xattr_fs(googleearth_t)
# allow memory access
allow googleearth_t self:process { execmem execstack };
# kernel
gen_require(`
type sysctl_kernel_t;
type sysctl_t;
')
allow googleearth_t sysctl_kernel_t:dir search;
allow googleearth_t sysctl_kernel_t:file { getattr read };
allow googleearth_t sysctl_t:dir search;
# device proc
gen_require(`
type proc_t;
')
allow googleearth_t proc_t:dir search;
allow googleearth_t proc_t:file { getattr read };
# temp dir
gen_require(`
type tmp_t;
')
allow googleearth_t tmp_t:file getattr;
allow googleearth_t tmp_t:dir search;
allow googleearth_t tmp_t:sock_file write;
# read fonts
miscfiles_read_fonts(googleearth_t)
# network stuff
corenet_tcp_sendrecv_all_if(googleearth_t)
corenet_tcp_sendrecv_all_nodes(googleearth_t)
corenet_udp_sendrecv_all_if(googleearth_t)
corenet_udp_sendrecv_all_nodes(googleearth_t)
corenet_tcp_connect_http_port(googleearth_t)
corenet_tcp_sendrecv_http_port(googleearth_t)
corenet_udp_sendrecv_dns_port(googleearth_t)
sysnet_read_config(googleearth_t)
# unknown stuff
gen_require(`
type ice_tmp_t;
')
allow googleearth_t ice_tmp_t:dir search;
allow googleearth_t ice_tmp_t:sock_file write;
gen_require(`
type urandom_device_t;
')
allow googleearth_t urandom_device_t:chr_file { getattr read };
Benjy
1 a.m.
On Tue, 2006-06-20 at 01:46 -0400, Benjy Grogan wrote:
On 6/19/06, Daniel J Walsh <dwalsh(a)redhat.com> wrote:
> Benjy Grogan wrote:
> > On 6/17/06, Daniel J Walsh <dwalsh(a)redhat.com> wrote:
> >> Benjy Grogan wrote:
> >> > Hello:
> >> >
> >> > On 6/15/06, Daniel J Walsh <dwalsh(a)redhat.com> wrote:
> >> >> Benjy Grogan wrote:
> >> >> > Hello:
> >> >> >
> >> >> > Would it be possible for the SELinux team at Red Hat to
create an
> >> >> > SELinux policy module for Google Earth and to show the step
by step
> >> >> > process for confining the application? I think these kind
of
> >> examples
> >> >> > would be useful to developers attempting to create SELinux
policies
> >> >> > for other rpm packages out there. I'm not interested so
much in
> >> the
> >> >> > actual policy module, but in creating it myself from
step-by-step
> >> >> > instructions. IMHO, that would be the best way to educate
> >> developers
> >> >> > on how to use SELinux.
> >> >> >
> >> >> Google-earth is not the best example of this but
> >> >>
> >> >> The way I would go about it would be to first use policygentool
to
> >> >> create my initial fc/if/te files
> >> >>
> >> >> #cd /tmp
> >> >> #mkdir googlearth
> >> >> #cd googleearth
> >> >> STEP 1
> >> >> #policygentool googlearth /usr/local/google-earth/googleearth-bin
> >> >> answer some questions to the best of my ability
> >> >
> >> > I answered the questions, but I had little idea as to what pidfiles
> >> > were. As for logs, Google Earth doesn't use /var/log but I know
it
> >> > must log something in ~/.googleearth. That would be a directory that
> >> > depends on which user is at the moment using Google Earth.
There's
> >> > probably a better way of specifying this after running policygentool.
> >> >
> >> > I didn't know if there were any /var/lib files, so I left that
alone.
> >> > The module didn't have an init script, which is used by
> >> > daemons/services, right? The module will be a heavy user of the
> >> > network, so that was answered yes, but further restricting Google
> >> > Earth's network access would be useful, such as no access
192.168.x.x.
> >> >
> >> >> STEP2
> >> >> add the following lines to the te file to cause the transition
form
> >> >> uncofined_t to googleearth
> >> >> cat >> googleearth.te << __EOF
> >> >> gen_require(`
> >> >> type unconfined_t;
> >> >> ')
> >> >
> >> > First time I've seen ` and ' used.
> >> >
> >> >> domain_auto_trans(uncofined_t, googleearth_exec_t, googleearth_t)
> >> This should be unconfined_t.
> >
> > I had made this change. I was avoiding the policy completely by using
> > /usr/local/google-earth/googleearth instead of
> > /usr/local/google-earth/googleearth-bin.
> >
> > When I do run googleearth-bin I get:
> >
> > $ /usr/local/google-earth/googleearth-bin
> > /usr/local/google-earth/googleearth-bin: error while loading shared
> > libraries: ./libcomponent.so: cannot open shared object file: No such
> > file or directory
> >
> You should be running in permissive mode and translating avc messages to
> allow rules via
>
> audit2allow -R -i /var/log/messages
Okay, I created a policy from audit2allow and used as many macros as I
could where it made sense. Below I have the TE file that I wrote.
This policy works fine with setenforce 0 and doesn't generate many
AVCs at all anymore, except when I navigate outside of the user's home
directory when saving or opening a jpeg, and I've auditdenied some of
that stuff. But when I turn enforcing on, setenforce 1, I get this
error:
$ googleearth
Xlib: connection to ":0.0" refused by server
Xlib: No protocol specified
There are no AVCs to be found in /var/log/messages.
It's possible that the AVCs are being dontaudit-ed. Try this:
# semodule -b /usr/share/selinux/targeted/enableaudit.pp
This is a version of the base policy without the dontaudit rules.
To revert this change:
# semodule -b /usr/share/selinux/targeted/base.pp
Paul.
1:18 a.m.
On 6/20/06, Paul Howarth <paul(a)city-fan.org> wrote:
On Tue, 2006-06-20 at 01:46 -0400, Benjy Grogan wrote:
> On 6/19/06, Daniel J Walsh <dwalsh(a)redhat.com> wrote:
> > Benjy Grogan wrote:
> > > On 6/17/06, Daniel J Walsh <dwalsh(a)redhat.com> wrote:
> > >> Benjy Grogan wrote:
> > >> > Hello:
> > >> >
> > >> > On 6/15/06, Daniel J Walsh <dwalsh(a)redhat.com> wrote:
> > >> >> Benjy Grogan wrote:
> > >> >> > Hello:
> > >> >> >
> > >> >> > Would it be possible for the SELinux team at Red Hat to
create an
> > >> >> > SELinux policy module for Google Earth and to show the
step by step
> > >> >> > process for confining the application? I think these
kind of
> > >> examples
> > >> >> > would be useful to developers attempting to create
SELinux policies
> > >> >> > for other rpm packages out there. I'm not
interested so much in
> > >> the
> > >> >> > actual policy module, but in creating it myself from
step-by-step
> > >> >> > instructions. IMHO, that would be the best way to
educate
> > >> developers
> > >> >> > on how to use SELinux.
> > >> >> >
> > >> >> Google-earth is not the best example of this but
> > >> >>
> > >> >> The way I would go about it would be to first use
policygentool to
> > >> >> create my initial fc/if/te files
> > >> >>
> > >> >> #cd /tmp
> > >> >> #mkdir googlearth
> > >> >> #cd googleearth
> > >> >> STEP 1
> > >> >> #policygentool googlearth
/usr/local/google-earth/googleearth-bin
> > >> >> answer some questions to the best of my ability
> > >> >
> > >> > I answered the questions, but I had little idea as to what
pidfiles
> > >> > were. As for logs, Google Earth doesn't use /var/log but I
know it
> > >> > must log something in ~/.googleearth. That would be a directory
that
> > >> > depends on which user is at the moment using Google Earth.
There's
> > >> > probably a better way of specifying this after running
policygentool.
> > >> >
> > >> > I didn't know if there were any /var/lib files, so I left
that alone.
> > >> > The module didn't have an init script, which is used by
> > >> > daemons/services, right? The module will be a heavy user of the
> > >> > network, so that was answered yes, but further restricting
Google
> > >> > Earth's network access would be useful, such as no access
192.168.x.x.
> > >> >
> > >> >> STEP2
> > >> >> add the following lines to the te file to cause the
transition form
> > >> >> uncofined_t to googleearth
> > >> >> cat >> googleearth.te << __EOF
> > >> >> gen_require(`
> > >> >> type unconfined_t;
> > >> >> ')
> > >> >
> > >> > First time I've seen ` and ' used.
> > >> >
> > >> >> domain_auto_trans(uncofined_t, googleearth_exec_t,
googleearth_t)
> > >> This should be unconfined_t.
> > >
> > > I had made this change. I was avoiding the policy completely by using
> > > /usr/local/google-earth/googleearth instead of
> > > /usr/local/google-earth/googleearth-bin.
> > >
> > > When I do run googleearth-bin I get:
> > >
> > > $ /usr/local/google-earth/googleearth-bin
> > > /usr/local/google-earth/googleearth-bin: error while loading shared
> > > libraries: ./libcomponent.so: cannot open shared object file: No such
> > > file or directory
> > >
> > You should be running in permissive mode and translating avc messages to
> > allow rules via
> >
> > audit2allow -R -i /var/log/messages
>
> Okay, I created a policy from audit2allow and used as many macros as I
> could where it made sense. Below I have the TE file that I wrote.
> This policy works fine with setenforce 0 and doesn't generate many
> AVCs at all anymore, except when I navigate outside of the user's home
> directory when saving or opening a jpeg, and I've auditdenied some of
> that stuff. But when I turn enforcing on, setenforce 1, I get this
> error:
>
> $ googleearth
> Xlib: connection to ":0.0" refused by server
> Xlib: No protocol specified
>
> There are no AVCs to be found in /var/log/messages.
It's possible that the AVCs are being dontaudit-ed. Try this:
# semodule -b /usr/share/selinux/targeted/enableaudit.pp
This is a version of the base policy without the dontaudit rules.
To revert this change:
# semodule -b /usr/share/selinux/targeted/base.pp
I think the problem could be some X server avcs that have been
auditdenied but this module didn't change anything. Perhaps
enableaudit needs to be expanded to enable auditing of all X server
avcs?
Benjy
Paul.
2:03 a.m.
On Tue, 2006-06-20 at 02:18 -0400, Benjy Grogan wrote:
On 6/20/06, Paul Howarth <paul(a)city-fan.org> wrote:
> On Tue, 2006-06-20 at 01:46 -0400, Benjy Grogan wrote:
> > On 6/19/06, Daniel J Walsh <dwalsh(a)redhat.com> wrote:
> > > Benjy Grogan wrote:
> > > > On 6/17/06, Daniel J Walsh <dwalsh(a)redhat.com> wrote:
> > > >> Benjy Grogan wrote:
> > > >> > Hello:
> > > >> >
> > > >> > On 6/15/06, Daniel J Walsh <dwalsh(a)redhat.com> wrote:
> > > >> >> Benjy Grogan wrote:
> > > >> >> > Hello:
> > > >> >> >
> > > >> >> > Would it be possible for the SELinux team at Red
Hat to create an
> > > >> >> > SELinux policy module for Google Earth and to show
the step by step
> > > >> >> > process for confining the application? I think
these kind of
> > > >> examples
> > > >> >> > would be useful to developers attempting to create
SELinux policies
> > > >> >> > for other rpm packages out there. I'm not
interested so much in
> > > >> the
> > > >> >> > actual policy module, but in creating it myself
from step-by-step
> > > >> >> > instructions. IMHO, that would be the best way to
educate
> > > >> developers
> > > >> >> > on how to use SELinux.
> > > >> >> >
> > > >> >> Google-earth is not the best example of this but
> > > >> >>
> > > >> >> The way I would go about it would be to first use
policygentool to
> > > >> >> create my initial fc/if/te files
> > > >> >>
> > > >> >> #cd /tmp
> > > >> >> #mkdir googlearth
> > > >> >> #cd googleearth
> > > >> >> STEP 1
> > > >> >> #policygentool googlearth
/usr/local/google-earth/googleearth-bin
> > > >> >> answer some questions to the best of my ability
> > > >> >
> > > >> > I answered the questions, but I had little idea as to what
pidfiles
> > > >> > were. As for logs, Google Earth doesn't use /var/log
but I know it
> > > >> > must log something in ~/.googleearth. That would be a
directory that
> > > >> > depends on which user is at the moment using Google Earth.
There's
> > > >> > probably a better way of specifying this after running
policygentool.
> > > >> >
> > > >> > I didn't know if there were any /var/lib files, so I
left that alone.
> > > >> > The module didn't have an init script, which is used by
> > > >> > daemons/services, right? The module will be a heavy user of
the
> > > >> > network, so that was answered yes, but further restricting
Google
> > > >> > Earth's network access would be useful, such as no
access 192.168.x.x.
> > > >> >
> > > >> >> STEP2
> > > >> >> add the following lines to the te file to cause the
transition form
> > > >> >> uncofined_t to googleearth
> > > >> >> cat >> googleearth.te << __EOF
> > > >> >> gen_require(`
> > > >> >> type unconfined_t;
> > > >> >> ')
> > > >> >
> > > >> > First time I've seen ` and ' used.
> > > >> >
> > > >> >> domain_auto_trans(uncofined_t, googleearth_exec_t,
googleearth_t)
> > > >> This should be unconfined_t.
> > > >
> > > > I had made this change. I was avoiding the policy completely by
using
> > > > /usr/local/google-earth/googleearth instead of
> > > > /usr/local/google-earth/googleearth-bin.
> > > >
> > > > When I do run googleearth-bin I get:
> > > >
> > > > $ /usr/local/google-earth/googleearth-bin
> > > > /usr/local/google-earth/googleearth-bin: error while loading shared
> > > > libraries: ./libcomponent.so: cannot open shared object file: No
such
> > > > file or directory
> > > >
> > > You should be running in permissive mode and translating avc messages to
> > > allow rules via
> > >
> > > audit2allow -R -i /var/log/messages
> >
> > Okay, I created a policy from audit2allow and used as many macros as I
> > could where it made sense. Below I have the TE file that I wrote.
> > This policy works fine with setenforce 0 and doesn't generate many
> > AVCs at all anymore, except when I navigate outside of the user's home
> > directory when saving or opening a jpeg, and I've auditdenied some of
> > that stuff. But when I turn enforcing on, setenforce 1, I get this
> > error:
> >
> > $ googleearth
> > Xlib: connection to ":0.0" refused by server
> > Xlib: No protocol specified
> >
> > There are no AVCs to be found in /var/log/messages.
>
> It's possible that the AVCs are being dontaudit-ed. Try this:
>
> # semodule -b /usr/share/selinux/targeted/enableaudit.pp
>
> This is a version of the base policy without the dontaudit rules.
>
> To revert this change:
>
> # semodule -b /usr/share/selinux/targeted/base.pp
I think the problem could be some X server avcs that have been
auditdenied but this module didn't change anything. Perhaps
enableaudit needs to be expanded to enable auditing of all X server
avcs?
My understanding is that enableaudit.pp is the same as base.pp but with
all of the dontaudit rules removed, so if you're still not getting the
AVCs after loading enableaudit.pp, I'm a bit stuck.
Paul.
2:46 p.m.
On 6/20/06, Paul Howarth <paul(a)city-fan.org> wrote:
On Tue, 2006-06-20 at 02:18 -0400, Benjy Grogan wrote:
> On 6/20/06, Paul Howarth <paul(a)city-fan.org> wrote:
> > On Tue, 2006-06-20 at 01:46 -0400, Benjy Grogan wrote:
> > > On 6/19/06, Daniel J Walsh <dwalsh(a)redhat.com> wrote:
> > > > Benjy Grogan wrote:
> > > > > On 6/17/06, Daniel J Walsh <dwalsh(a)redhat.com> wrote:
> > > > >> Benjy Grogan wrote:
> > > > >> > Hello:
> > > > >> >
> > > > >> > On 6/15/06, Daniel J Walsh <dwalsh(a)redhat.com>
wrote:
> > > > >> >> Benjy Grogan wrote:
> > > > >> >> > Hello:
> > > > >> >> >
> > > > >> >> > Would it be possible for the SELinux team at
Red Hat to create an
> > > > >> >> > SELinux policy module for Google Earth and to
show the step by step
> > > > >> >> > process for confining the application? I
think these kind of
> > > > >> examples
> > > > >> >> > would be useful to developers attempting to
create SELinux policies
> > > > >> >> > for other rpm packages out there. I'm not
interested so much in
> > > > >> the
> > > > >> >> > actual policy module, but in creating it
myself from step-by-step
> > > > >> >> > instructions. IMHO, that would be the best
way to educate
> > > > >> developers
> > > > >> >> > on how to use SELinux.
> > > > >> >> >
> > > > >> >> Google-earth is not the best example of this but
> > > > >> >>
> > > > >> >> The way I would go about it would be to first use
policygentool to
> > > > >> >> create my initial fc/if/te files
> > > > >> >>
> > > > >> >> #cd /tmp
> > > > >> >> #mkdir googlearth
> > > > >> >> #cd googleearth
> > > > >> >> STEP 1
> > > > >> >> #policygentool googlearth
/usr/local/google-earth/googleearth-bin
> > > > >> >> answer some questions to the best of my ability
> > > > >> >
> > > > >> > I answered the questions, but I had little idea as to
what pidfiles
> > > > >> > were. As for logs, Google Earth doesn't use
/var/log but I know it
> > > > >> > must log something in ~/.googleearth. That would be a
directory that
> > > > >> > depends on which user is at the moment using Google
Earth. There's
> > > > >> > probably a better way of specifying this after running
policygentool.
> > > > >> >
> > > > >> > I didn't know if there were any /var/lib files, so
I left that alone.
> > > > >> > The module didn't have an init script, which is
used by
> > > > >> > daemons/services, right? The module will be a heavy
user of the
> > > > >> > network, so that was answered yes, but further
restricting Google
> > > > >> > Earth's network access would be useful, such as no
access 192.168.x.x.
> > > > >> >
> > > > >> >> STEP2
> > > > >> >> add the following lines to the te file to cause the
transition form
> > > > >> >> uncofined_t to googleearth
> > > > >> >> cat >> googleearth.te << __EOF
> > > > >> >> gen_require(`
> > > > >> >> type unconfined_t;
> > > > >> >> ')
> > > > >> >
> > > > >> > First time I've seen ` and ' used.
> > > > >> >
> > > > >> >> domain_auto_trans(uncofined_t, googleearth_exec_t,
googleearth_t)
> > > > >> This should be unconfined_t.
> > > > >
> > > > > I had made this change. I was avoiding the policy completely by
using
> > > > > /usr/local/google-earth/googleearth instead of
> > > > > /usr/local/google-earth/googleearth-bin.
> > > > >
> > > > > When I do run googleearth-bin I get:
> > > > >
> > > > > $ /usr/local/google-earth/googleearth-bin
> > > > > /usr/local/google-earth/googleearth-bin: error while loading
shared
> > > > > libraries: ./libcomponent.so: cannot open shared object file: No
such
> > > > > file or directory
> > > > >
> > > > You should be running in permissive mode and translating avc messages
to
> > > > allow rules via
> > > >
> > > > audit2allow -R -i /var/log/messages
> > >
> > > Okay, I created a policy from audit2allow and used as many macros as I
> > > could where it made sense. Below I have the TE file that I wrote.
> > > This policy works fine with setenforce 0 and doesn't generate many
> > > AVCs at all anymore, except when I navigate outside of the user's
home
> > > directory when saving or opening a jpeg, and I've auditdenied some of
> > > that stuff. But when I turn enforcing on, setenforce 1, I get this
> > > error:
> > >
> > > $ googleearth
> > > Xlib: connection to ":0.0" refused by server
> > > Xlib: No protocol specified
> > >
> > > There are no AVCs to be found in /var/log/messages.
> >
> > It's possible that the AVCs are being dontaudit-ed. Try this:
> >
> > # semodule -b /usr/share/selinux/targeted/enableaudit.pp
> >
> > This is a version of the base policy without the dontaudit rules.
> >
> > To revert this change:
> >
> > # semodule -b /usr/share/selinux/targeted/base.pp
>
> I think the problem could be some X server avcs that have been
> auditdenied but this module didn't change anything. Perhaps
> enableaudit needs to be expanded to enable auditing of all X server
> avcs?
My understanding is that enableaudit.pp is the same as base.pp but with
all of the dontaudit rules removed, so if you're still not getting the
AVCs after loading enableaudit.pp, I'm a bit stuck.
How do you verify that you're using enableaudit.pp and not base.pp? I
get these avcs after building and loading enableaudit but my Google
Earth policy still gives off zero avcs after 20 minutes of use. Which
would be great if it actually ran in enforcing mode.
Jun 20 15:18:03 localhost kernel: audit(1150831083.862:3836): avc:
denied { siginh } for
pid=7029 comm="setfiles" scontext=user_u:system_r:semanage_t:s0
tcontext=user_u:system_r:setfiles_t:s0 tclass=process
Jun 20 15:18:03 localhost kernel: audit(1150831083.862:3837): avc:
denied { rlimitinh } for pid=7029 comm="setfiles"
scontext=user_u:system_r:semanage_t:s0
tcontext=user_u:system_r:setfiles_t:s0 tclass=process
Jun 20 15:18:03 localhost kernel: audit(1150831083.862:3838): avc:
denied { noatsecure } for pid=7029 comm="setfiles"
scontext=user_u:system_r:semanage_t:s0
tcontext=user_u:system_r:setfiles_t:s0 tclass=process
Thanks for tips anyways. It should help narrow down the problem.
Benjy
3:32 p.m.
On Tue, 2006-06-20 at 15:46 -0400, Benjy Grogan wrote:
How do you verify that you're using enableaudit.pp and not
base.pp? I
get these avcs after building and loading enableaudit but my Google
Earth policy still gives off zero avcs after 20 minutes of use. Which
would be great if it actually ran in enforcing mode.
Jun 20 15:18:03 localhost kernel: audit(1150831083.862:3836): avc:
denied { siginh } for
pid=7029 comm="setfiles" scontext=user_u:system_r:semanage_t:s0
tcontext=user_u:system_r:setfiles_t:s0 tclass=process
Jun 20 15:18:03 localhost kernel: audit(1150831083.862:3837): avc:
denied { rlimitinh } for pid=7029 comm="setfiles"
scontext=user_u:system_r:semanage_t:s0
tcontext=user_u:system_r:setfiles_t:s0 tclass=process
Jun 20 15:18:03 localhost kernel: audit(1150831083.862:3838): avc:
denied { noatsecure } for pid=7029 comm="setfiles"
scontext=user_u:system_r:semanage_t:s0
tcontext=user_u:system_r:setfiles_t:s0 tclass=process
Those avcs suggest that you are using enableaudit.pp, as they would
normally be silenced by dontaudit rules. Try running the program under
strace and checking the output to see precisely where it is failing.
One case where we get no auditing at all is the net_admin capability
check upon netlink recv; that will be fixed by a pending patch in the
audit tree. Hopefully googleearth doesn't need that though ;)
--
Stephen Smalley
National Security Agency
9:54 p.m.
On 6/20/06, Stephen Smalley <sds(a)tycho.nsa.gov> wrote:
On Tue, 2006-06-20 at 15:46 -0400, Benjy Grogan wrote:
> How do you verify that you're using enableaudit.pp and not base.pp? I
> get these avcs after building and loading enableaudit but my Google
> Earth policy still gives off zero avcs after 20 minutes of use. Which
> would be great if it actually ran in enforcing mode.
>
> Jun 20 15:18:03 localhost kernel: audit(1150831083.862:3836): avc:
> denied { siginh } for
> pid=7029 comm="setfiles" scontext=user_u:system_r:semanage_t:s0
> tcontext=user_u:system_r:setfiles_t:s0 tclass=process
> Jun 20 15:18:03 localhost kernel: audit(1150831083.862:3837): avc:
> denied { rlimitinh } for pid=7029 comm="setfiles"
> scontext=user_u:system_r:semanage_t:s0
> tcontext=user_u:system_r:setfiles_t:s0 tclass=process
> Jun 20 15:18:03 localhost kernel: audit(1150831083.862:3838): avc:
> denied { noatsecure } for pid=7029 comm="setfiles"
> scontext=user_u:system_r:semanage_t:s0
> tcontext=user_u:system_r:setfiles_t:s0 tclass=process
Those avcs suggest that you are using enableaudit.pp, as they would
normally be silenced by dontaudit rules. Try running the program under
strace and checking the output to see precisely where it is failing.
One case where we get no auditing at all is the net_admin capability
check upon netlink recv; that will be fixed by a pending patch in the
audit tree. Hopefully googleearth doesn't need that though ;)
Thanks. strace showed me that the problem was my own fault. I was
incorrectly using auditdeny.
I'm currently trying to get my Google Earth selinux policy to allow
CUPS. It's allowed but I find the cupsd_t domain's need to access the
SElinux config and security file contexts strange. You can see below.
Is this normal?
# Google Earth printing to CUPS
gen_require(`
type cupsd_etc_t;
type cupsd_rw_etc_t;
type cupsd_var_run_t;
type ipp_port_t;
')
# how come cupsd_t has been denied these privileges and why would it need them?
allow cupsd_t security_t:dir search;
allow cupsd_t security_t:file read;
allow cupsd_t selinux_config_t:dir search;
allow cupsd_t selinux_config_t:file { getattr read };
# use CUPS service...
cups_read_config(googleearth_t)
allow googleearth_t cupsd_var_run_t:dir search;
allow googleearth_t self:netlink_route_socket { r_netlink_socket_perms };
corenet_tcp_sendrecv_ipp_port(googleearth_t)
corenet_tcp_connect_ipp_port(googleearth_t)
Benjy
--
Stephen Smalley
National Security Agency
7:08 a.m.
Benjy Grogan wrote:
On 6/20/06, Stephen Smalley <sds(a)tycho.nsa.gov> wrote:
> On Tue, 2006-06-20 at 15:46 -0400, Benjy Grogan wrote:
> > How do you verify that you're using enableaudit.pp and not base.pp? I
> > get these avcs after building and loading enableaudit but my Google
> > Earth policy still gives off zero avcs after 20 minutes of use. Which
> > would be great if it actually ran in enforcing mode.
> >
> > Jun 20 15:18:03 localhost kernel: audit(1150831083.862:3836): avc:
> > denied { siginh } for
> > pid=7029 comm="setfiles" scontext=user_u:system_r:semanage_t:s0
> > tcontext=user_u:system_r:setfiles_t:s0 tclass=process
> > Jun 20 15:18:03 localhost kernel: audit(1150831083.862:3837): avc:
> > denied { rlimitinh } for pid=7029 comm="setfiles"
> > scontext=user_u:system_r:semanage_t:s0
> > tcontext=user_u:system_r:setfiles_t:s0 tclass=process
> > Jun 20 15:18:03 localhost kernel: audit(1150831083.862:3838): avc:
> > denied { noatsecure } for pid=7029 comm="setfiles"
> > scontext=user_u:system_r:semanage_t:s0
> > tcontext=user_u:system_r:setfiles_t:s0 tclass=process
>
> Those avcs suggest that you are using enableaudit.pp, as they would
> normally be silenced by dontaudit rules. Try running the program under
> strace and checking the output to see precisely where it is failing.
> One case where we get no auditing at all is the net_admin capability
> check upon netlink recv; that will be fixed by a pending patch in the
> audit tree. Hopefully googleearth doesn't need that though ;)
Thanks. strace showed me that the problem was my own fault. I was
incorrectly using auditdeny.
I'm currently trying to get my Google Earth selinux policy to allow
CUPS. It's allowed but I find the cupsd_t domain's need to access the
SElinux config and security file contexts strange. You can see below.
Is this normal?
# Google Earth printing to CUPS
is is
gen_require(`
type cupsd_etc_t;
type cupsd_rw_etc_t;
type cupsd_var_run_t;
type ipp_port_t;
')
# how come cupsd_t has been denied these privileges and why would it
need them?
allow cupsd_t security_t:dir search;
allow cupsd_t security_t:file read;
allow cupsd_t selinux_config_t:dir search;
allow cupsd_t selinux_config_t:file { getattr read };
It does not need it. This is only because you are running in permissive
mode. The first access would have been dontaudited and all of the other
avc's would not
been created.
# use CUPS service...
cups_read_config(googleearth_t)
allow googleearth_t cupsd_var_run_t:dir search;
allow googleearth_t self:netlink_route_socket { r_netlink_socket_perms };
corenet_tcp_sendrecv_ipp_port(googleearth_t)
corenet_tcp_connect_ipp_port(googleearth_t)
Benjy
>
> --
> Stephen Smalley
> National Security Agency
>
>
--
fedora-selinux-list mailing list
fedora-selinux-list(a)redhat.com
https://www.redhat.com/mailman/listinfo/fedora-selinux-list
6513
days inactive
6525
days old
selinux@lists.fedoraproject.org
13 comments
4 participants
participants (4)
-
Benjy Grogan -
Daniel J Walsh -
Paul Howarth -
Stephen Smalley