Comment 1 for bug 1911431

Correct, scripts are treated as their own executable. Eg.

Profile some_script /usr/bin/script {
   ...
}

will attach to a script as if it is its own executable instead of the interpreter (say perl). This same script can be run directly from the interpreter and NOT be confined by the defined profile. ie.

  $ perl /usr/bin/script

will launch the script with what ever confinement perl will run under instead of what the profile for the script.

This does mean that that users can launch applications that by-pass a script profile for the interpreter profile OR as you have noticed use a script profile to by-pass the interpreter profile.

Currently it is expected that if user should not be able to change what confinement a script will run under they should not be given write access to the script file, and ideally denied running the interpreter directly. Interpreters if they support AppArmor's API can execute switch into the scripts profile but unfortunately no interpreters are doing this atm.

This is less than ideal and the AppArmor project is working on improving this with some extensions.
- script profiles will be able to identify what their interpreter should be, causing script execution to fail if the interpreter is different than what has been defined.
- scipts can be defined to pickup/use the interpreter profile
- scripts can be allowed/blocked based on the interpreter

And further out
- interpreters will be able to be tagged as such and parse out the script file that is to be run, and pickup the script profile even when started by the interpreter.