Which permission to execute a script?

[Bruno Wolff III]

I was making a modified version of the guest policy that needed to be able
to edit and run some perl scripts that also are visible to the web server.
I used the manage_files macro and allowed execute, but I can't run the
script directly. But I can run it via perl.

For example:

[tomarndt@wolff area]$ ./newcheck.pl
-bash: ./newcheck.pl: /usr/bin/perl: bad interpreter: Permission denied
[tomarndt@wolff area]$ perl ./newcheck.pl

Ownership counts:

Ownership of games with owners owning less than 10 new games.

newcheck.pl starts with:
#!/usr/bin/perl

This is the modified policy for tom_t:

policy_module(tom,1.0.0)

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

userdom_restricted_user_template(tom)

require {
	type httpd_sys_content_t;
	type httpd_sys_script_exec_t;
	type postgresql_tmp_t;
	type postgresql_t;
}

########################################
#
# tom local policy
#


optional_policy(`
	qmail_per_role_template(tom,tom_t,tom_r)
')

manage_dirs_pattern(tom_t, httpd_sys_content_t, httpd_sys_content_t)
manage_files_pattern(tom_t, httpd_sys_content_t, httpd_sys_content_t)
manage_files_pattern(tom_t, httpd_sys_script_exec_t, httpd_sys_script_exec_t)

allow tom_t postgresql_tmp_t:sock_file write;
allow tom_t postgresql_t:unix_stream_socket connectto;
allow tom_t httpd_sys_script_exec_t:file execute;

[Ignacio Vazquez-Abrams]

On Sun, 2008-11-16 at 01:57 -0600, Bruno Wolff III wrote:
>  I was making a modified version of the guest policy that needed to be
> able
>  to edit and run some perl scripts that also are visible to the web server.
>  I used the manage_files macro and allowed execute, but I can't run the
>  script directly. But I can run it via perl.
>  
>  For example:
>  
>  [tomarndt@wolff area]$ ./newcheck.pl
>  -bash: ./newcheck.pl: /usr/bin/perl: bad interpreter: Permission denied
>  [tomarndt@wolff area]$ perl ./newcheck.pl 
Sounds like a EOL issue. Try running dos2unix on it.

-- 
Ignacio Vazquez-Abrams <ivazqueznet(a)gmail.com&gt;

PLEASE don't CC me; I'm already subscribed

[Bruno Wolff III]

On Sun, Nov 16, 2008 at 01:57:31 -0600,
  Bruno Wolff III <bruno(a)wolff.to&gt; wrote:
>  I was making a modified version of the guest policy that needed to be
> able
>  to edit and run some perl scripts that also are visible to the web server.
>  I used the manage_files macro and allowed execute, but I can't run the
>  script directly. But I can run it via perl. 
Being told how to turn auditing back on for guest roles would also be
helpful as then I could find the missing permission from the logs.

[Daniel J Walsh]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Bruno Wolff III wrote:
>  I was making a modified version of the guest policy that needed to be
> able
>  to edit and run some perl scripts that also are visible to the web server.
>  I used the manage_files macro and allowed execute, but I can't run the
>  script directly. But I can run it via perl.
>  
>  For example:
>  
>  [tomarndt@wolff area]$ ./newcheck.pl
>  -bash: ./newcheck.pl: /usr/bin/perl: bad interpreter: Permission denied
>  [tomarndt@wolff area]$ perl ./newcheck.pl
>  
>  Ownership counts:
>  
>  Ownership of games with owners owning less than 10 new games.
>  
>  newcheck.pl starts with:
>  #!/usr/bin/perl
>  
>  This is the modified policy for tom_t:
>  
>  policy_module(tom,1.0.0)
>  
>  ########################################
>  #
>  # Declarations
>  #
>  
>  userdom_restricted_user_template(tom)
>  
>  require {
>  	type httpd_sys_content_t;
>  	type httpd_sys_script_exec_t;
>  	type postgresql_tmp_t;
>  	type postgresql_t;
>  }
>  
>  ########################################
>  #
>  # tom local policy
>  #
>  
>  
>  optional_policy(`
>  	qmail_per_role_template(tom,tom_t,tom_r)
>  ')
>  
>  manage_dirs_pattern(tom_t, httpd_sys_content_t, httpd_sys_content_t)
>  manage_files_pattern(tom_t, httpd_sys_content_t, httpd_sys_content_t)
>  manage_files_pattern(tom_t, httpd_sys_script_exec_t, httpd_sys_script_exec_t)
>  
>  allow tom_t postgresql_tmp_t:sock_file write;
>  allow tom_t postgresql_t:unix_stream_socket connectto;
>  allow tom_t httpd_sys_script_exec_t:file execute;
>  
>  --
>  fedora-selinux-list mailing list
>  fedora-selinux-list(a)redhat.com
>  https://www.redhat.com/mailman/listinfo/fedora-selinux-list 
 getsebool -a  | grep xgues
allow_xguest_exec_content --> off

xguest is not allowed by default to execute anything in its home dir.
Turning on this boolean should allow it.
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (GNU/Linux)
> Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
>
> iEYEARECAAYFAkkhgM4ACgkQrlYvE4MpobMUlwCgos9O2+96RoMXEpMRRTvAXFeG
> pyIAn2QtlkvXDObfqzKjOBtdbOGFcmkR
> =N7MO
> -----END PGP SIGNATURE-----

[Bruno Wolff III]

On Mon, Nov 17, 2008 at 09:33:50 -0500,
  Daniel J Walsh <dwalsh(a)redhat.com&gt; wrote:
>  
>  Bruno Wolff III wrote:
>  > I was making a modified version of the guest policy that needed to be able
>  > to edit and run some perl scripts that also are visible to the web server.
>  > I used the manage_files macro and allowed execute, but I can't run the
>  > script directly. But I can run it via perl.
>  > 
>  > For example:
>  > 
>  > [tomarndt@wolff area]$ ./newcheck.pl
>  > -bash: ./newcheck.pl: /usr/bin/perl: bad interpreter: Permission denied
>  
>   getsebool -a  | grep xgues
>  allow_xguest_exec_content --> off
>  
>  xguest is not allowed by default to execute anything in its home dir.
>  Turning on this boolean should allow it. 
I tried this and it didn't work. I think there is something else going on
though, as I got a different error before I added:
allow tom_t httpd_sys_script_exec_t:file execute;
I think that running a shell script needs something else, but I don't know
what.

[Daniel J Walsh]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Bruno Wolff III wrote:
>  On Mon, Nov 17, 2008 at 09:33:50 -0500,
>    Daniel J Walsh <dwalsh(a)redhat.com&gt; wrote:
> > Bruno Wolff III wrote:
> >> I was making a modified version of the guest policy that needed to be able
> >> to edit and run some perl scripts that also are visible to the web server.
> >> I used the manage_files macro and allowed execute, but I can't run the
> >> script directly. But I can run it via perl.
> >>
> >> For example:
> >>
> >> [tomarndt@wolff area]$ ./newcheck.pl
> >> -bash: ./newcheck.pl: /usr/bin/perl: bad interpreter: Permission denied
> >  getsebool -a  | grep xgues
> > allow_xguest_exec_content --> off
> >
> > xguest is not allowed by default to execute anything in its home dir.
> > Turning on this boolean should allow it.
>  
>  I tried this and it didn't work. I think there is something else going on
>  though, as I got a different error before I added:
>  allow tom_t httpd_sys_script_exec_t:file execute;
>  I think that running a shell script needs something else, but I don't know
>  what.
>  
>  --
>  fedora-selinux-list mailing list
>  fedora-selinux-list(a)redhat.com
>  https://www.redhat.com/mailman/listinfo/fedora-selinux-list 
Yes you are right.  I
did not read your message fully.

You are trying to execute an apache script,  http_sys_script_exec_t,
which is not allowed without the rule you added.

If you change the label to http_user_script_exec_t it should be able to
execute.



> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (GNU/Linux)
> Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
>
> iEYEARECAAYFAkkhjyEACgkQrlYvE4MpobNIlwCfZAVy2T//eSdXTmCpfqrIFTAx
> O9oAoIBT0+htYNSfQO1H33ruU/rQ0qqc
> =qOHN
> -----END PGP SIGNATURE-----

[Bruno Wolff III]

On Mon, Nov 17, 2008 at 10:34:58 -0500,
  Daniel J Walsh <dwalsh(a)redhat.com&gt; wrote:
>  -----BEGIN PGP SIGNED MESSAGE-----
>  Hash: SHA1
>  
>  Bruno Wolff III wrote:
>  > On Mon, Nov 17, 2008 at 09:33:50 -0500,
>  >   Daniel J Walsh <dwalsh(a)redhat.com&gt; wrote:
>  >> Bruno Wolff III wrote:
>  >>> I was making a modified version of the guest policy that needed to be able
>  >>> to edit and run some perl scripts that also are visible to the web server.
>  >>> I used the manage_files macro and allowed execute, but I can't run the
>  >>> script directly. But I can run it via perl.
>  >>>
>  >>> For example:
>  >>>
>  >>> [tomarndt@wolff area]$ ./newcheck.pl
>  >>> -bash: ./newcheck.pl: /usr/bin/perl: bad interpreter: Permission denied
>  >>  getsebool -a  | grep xgues
>  
>  You are trying to execute an apache script,  http_sys_script_exec_t,
>  which is not allowed without the rule you added.
>  
>  If you change the label to http_user_script_exec_t it should be able to
>  execute. 
There doesn't seem to be a http_user_script_exec_t type. Probably it's a
typo, but I didn't see a way to get a full list and didn't manage to
guess the correct name.

I still think there is something odd about this though. I can run the perl
script using perl, just not as a script invoked from bash. I am not seeing
avc's in the audit log for these failed attempts, so I am having trouble
figuring out what is happening. Does running a bash script transition to
another context when starting from a guest context?

I tried setting each of allow_guest_exec_content and allow_xguest_exec_content
to on. (I am trying to make a modified guest policy for someone ssh'ing
in to my server.) Neither of those seemed to help.

In the short run, running 'perl newcheck.pl' instead of ./newcheck.pl isn't
really a big deal, but I'd like to try and make it work normally.

[Bruno Wolff III]

On Mon, Nov 17, 2008 at 17:07:42 -0600,
  Bruno Wolff III <bruno(a)wolff.to&gt; wrote:
>  
>  There doesn't seem to be a http_user_script_exec_t type. Probably it's a
>  typo, but I didn't see a way to get a full list and didn't manage to
>  guess the correct name. 
Yep, typo. For the archive, 'seinfo -t' provides a list of types.

The guest policy (at least my modified version) does not allow access to
files labelled httpd_user_script_exec_t.

I'll keep putzing with this.

[Bruno Wolff III]

On Mon, Nov 17, 2008 at 19:07:40 -0600,
  Bruno Wolff III <bruno(a)wolff.to&gt; wrote:
>  On Mon, Nov 17, 2008 at 17:07:42 -0600,
>    Bruno Wolff III <bruno(a)wolff.to&gt; wrote:
>  > 
>  > There doesn't seem to be a http_user_script_exec_t type. Probably it's a
>  > typo, but I didn't see a way to get a full list and didn't manage to
>  > guess the correct name.
>  
>  Yep, typo. For the archive, 'seinfo -t' provides a list of types.
>  
>  The guest policy (at least my modified version) does not allow access to
>  files labelled httpd_user_script_exec_t.
>  
>  I'll keep putzing with this. 
I have it working now. In the end I needed to give both execute and
execute_no_trans permission for tom_t running httpd_sys_script_exec_t.

The allow_xguest_exec_content and allow_guest_exec_content booleans
didn't seem to make a difference.

Going forward I might want to spend the time to dial this policy back
as I am executing the scripts with those types as an unconfined user
(or perhaps I should use the user_u role) and I'd like to prevent tom_t
from changing them (or replacing the files) with selinux.

I was having trouble finding what the manage_files_pattern and
manage_dirs_pattern macros expand to and exactly what functions some
of the permissions allow. Is there any good documentation of these things
online?

[Daniel J Walsh]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Bruno Wolff III wrote:
>  On Mon, Nov 17, 2008 at 19:07:40 -0600,
>    Bruno Wolff III <bruno(a)wolff.to&gt; wrote:
> > On Mon, Nov 17, 2008 at 17:07:42 -0600,
> >   Bruno Wolff III <bruno(a)wolff.to&gt; wrote:
> >> There doesn't seem to be a http_user_script_exec_t type. Probably it's a
> >> typo, but I didn't see a way to get a full list and didn't manage to
> >> guess the correct name.
> > Yep, typo. For the archive, 'seinfo -t' provides a list of types.
> >
> > The guest policy (at least my modified version) does not allow access to
> > files labelled httpd_user_script_exec_t.
> >
> > I'll keep putzing with this.
>  
>  I have it working now. In the end I needed to give both execute and
>  execute_no_trans permission for tom_t running httpd_sys_script_exec_t.
>  
>  The allow_xguest_exec_content and allow_guest_exec_content booleans
>  didn't seem to make a difference.
>  
>  Going forward I might want to spend the time to dial this policy back
>  as I am executing the scripts with those types as an unconfined user
>  (or perhaps I should use the user_u role) and I'd like to prevent tom_t
>  from changing them (or replacing the files) with selinux.
>  
>  I was having trouble finding what the manage_files_pattern and
>  manage_dirs_pattern macros expand to and exactly what functions some
>  of the permissions allow. Is there any good documentation of these things
>  online? 
A couple of things, people have asked for the ability to stop the
execution of programs in the homedir.  So the least priv app does not
have the ability to execute content.  Since xguest has the ability to
execute perl, sh, python and other interpreters, the value of shutting
down execution in the homedir is questionable.  This means
~/bin/myscript.sh will fail, but sh ~/bin/myscript.sh will work.  The
blocking of execution does work for all compiled code.

The policy is for the boolean allows the execution of user_home_t, but
not other labeled file in the homedir, which is a bug.



> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (GNU/Linux)
> Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
>
> iEYEARECAAYFAkkqywcACgkQrlYvE4MpobNYZQCfYVlEjsxEouyMpe2yJgxnZEOV
> 7QcAn0Ys5OU0YLQU75I4fFaRFmzK11Ec
> =GyTO
> -----END PGP SIGNATURE-----

[Bruno Wolff III]

On Mon, Nov 24, 2008 at 10:40:56 -0500,
  Daniel J Walsh <dwalsh(a)redhat.com&gt; wrote:
>  
>  A couple of things, people have asked for the ability to stop the
>  execution of programs in the homedir.  So the least priv app does not
>  have the ability to execute content.  Since xguest has the ability to
>  execute perl, sh, python and other interpreters, the value of shutting
>  down execution in the homedir is questionable.  This means
>  ~/bin/myscript.sh will fail, but sh ~/bin/myscript.sh will work.  The
>  blocking of execution does work for all compiled code. 
OK, that explains what I was seeing.

>  The policy is for the boolean allows the execution of user_home_t,
> but
>  not other labeled file in the homedir, which is a bug. 
And I think that explains why changing the booleans didn't fix my specific
situation.

Thanks for the explanation.