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;
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.
On Sun, Nov 16, 2008 at 01:57:31 -0600, Bruno Wolff III bruno@wolff.to 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.
-----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@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.
On Mon, Nov 17, 2008 at 09:33:50 -0500, Daniel J Walsh dwalsh@redhat.com 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.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Bruno Wolff III wrote:
On Mon, Nov 17, 2008 at 09:33:50 -0500, Daniel J Walsh dwalsh@redhat.com 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@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.
On Mon, Nov 17, 2008 at 10:34:58 -0500, Daniel J Walsh dwalsh@redhat.com 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@redhat.com 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.
On Mon, Nov 17, 2008 at 17:07:42 -0600, Bruno Wolff III bruno@wolff.to 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.
On Mon, Nov 17, 2008 at 19:07:40 -0600, Bruno Wolff III bruno@wolff.to wrote:
On Mon, Nov 17, 2008 at 17:07:42 -0600, Bruno Wolff III bruno@wolff.to 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?
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Bruno Wolff III wrote:
On Mon, Nov 17, 2008 at 19:07:40 -0600, Bruno Wolff III bruno@wolff.to wrote:
On Mon, Nov 17, 2008 at 17:07:42 -0600, Bruno Wolff III bruno@wolff.to 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.
On Mon, Nov 24, 2008 at 10:40:56 -0500, Daniel J Walsh dwalsh@redhat.com 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.
selinux@lists.fedoraproject.org
-
Bruno Wolff III -
Daniel J Walsh -
Ignacio Vazquez-Abrams