Diminuer les droits sur les fichier d'installation #2

Dans /opt/apps/myc-deploy et mic-manage il faut enlever les droits pour les autres utilisateur que root et groupe

Screenshot 2021-04-22 at 14.55.22.png

20 KiB

Screenshot 2021-04-22 at 14.56.32.png

11 KiB

Hi, thanks for your interest in myc-manage. We try to keep English language in issue report when possible to help with referencing and avoid mixing different languages.
We appreciate also when you can expand on the rationale of the issue (the "why?" part) to helps us understand your concern and show us you are understanding what you are asking for.

I'd like to also suggest you to favor copy-pasting over screenshots of text only data. Again, this generally helps for referencing and makes everything easier to read.

We are thinking about ways to making these guidelines more explicit so as to help any future contributor to make efficient and quality contribution. You'll notice these are nothing far from what is actually widely used everywhere else.

As for what I understand of what could be your concern, let me first address the myc-manage scripts and their permissions: they are deployed in /usr/local/sbin, and as you've probably noticed in any linux distribution, binaries in all {,/usr{,/local}}/sbin directories are also still world readable and executable even if it is clear that you'll probably need root permission to do anything useful (or harmful) on your system with them.

This is because they are obviously readable anyway, indeed, most of them are open-source and you can find them everywhere, you'll notice that this is the same for our script on this very website. And second, as a consequence, if you can read them, you can copy them and then be the owner and change the executable bit at will and execute them. Note for instance, that for bash script, a simple bash myscript will bypass the execution permission leveraging the read permission. There is, thus, no point to protect them more than they already are.

So what need to be understood here is that scripts and binaries are in '*/sbin' only for convenience and avoid having them popping out of TAB completion for instance when you don't have root permissions, because they will probably fail quickly and be useless to you. As a side note, executable permission is mostly used for convenience also. There are of course some very specific use case were the executable bit is a very important security measure (in relation with setuid bit for instance), or of course, if your binary's content is not opensource or readable in any other way, and that you have a secret inside you want to be protected, then you would be right, and the permissions should be set appropriately.

I hope you understand that we are not in these very specific cases.

This is of course a different story for the second case you brought up, which is about the read permission of compose.yml. Let me sidetrack a second to note that your screen capture shows other files around, with unusual permissions that are not coming from our standard VPS install. So I'll address only the issue of the read permissions of the compose.yml:

There are very few cases where the file could be read from a non-root account just because the host part of our standard VPS doesn't have non-root non-system account. The only service running on the host is sshd which is running as root anyway because it needs to run setuid to be able to spawn a login shell as any user.

This leaves us only one way to really be able to read compose.yml from an unpriviledged account : breaking in one of the dockerized service and breaking through the linux container namespacing while still being namespaced in an unpriviledged user for the host. If this seems hard at first sight, it's probably the only place I could find some very hypothetical threat that would be mitigated by removing the read permission of compose.yml. But even these could justify the change.

And I must admit that the change seems also rather painless, so even if I'm not sure of the full pertinence of this change, I would NOT have any reason to refuse a nice and clean PR from your side.

If you were looking for simple way to contribute to this code, this is probably one of the simplest patch to do.

It would fit nicely in the myc-update process so as to make sure all managed VPS gets this change on the next update.

If unsure, we generally appreciate that you test appropriately your contribution by running it on a fresh debian 9/10 first install and a previously deployed VPS (with running dockers) updated thanks to myc-update.

Hi, thanks for your interest in `myc-manage`. We try to keep English language in issue report when possible to help with referencing and avoid mixing different languages. We appreciate also when you can expand on the rationale of the issue (the "why?" part) to helps us understand your concern and show us you are understanding what you are asking for. I'd like to also suggest you to favor copy-pasting over screenshots of text only data. Again, this generally helps for referencing and makes everything easier to read. We are thinking about ways to making these guidelines more explicit so as to help any future contributor to make efficient and quality contribution. You'll notice these are nothing far from what is actually widely used everywhere else. As for what I understand of what could be your concern, let me first address the `myc-manage` scripts and their permissions: they are deployed in `/usr/local/sbin`, and as you've probably noticed in any linux distribution, binaries in all `{,/usr{,/local}}/sbin` directories are also still world readable and executable even if it is clear that you'll probably need `root` permission to do anything useful (or harmful) on your system with them. This is because they are obviously readable anyway, indeed, most of them are open-source and you can find them everywhere, you'll notice that this is the same for our script on this very website. And second, as a consequence, if you can read them, you can copy them and then be the owner and change the executable bit at will and execute them. Note for instance, that for bash script, a simple `bash myscript` will bypass the execution permission leveraging the read permission. There is, thus, no point to protect them more than they already are. So what need to be understood here is that scripts and binaries are in '*/sbin' only for convenience and avoid having them popping out of TAB completion for instance when you don't have root permissions, because they will probably fail quickly and be useless to you. As a side note, executable permission is mostly used for convenience also. There are of course some very specific use case were the executable bit is a very important security measure (in relation with setuid bit for instance), or of course, if your binary's content is not opensource or readable in any other way, and that you have a secret inside you want to be protected, then you would be right, and the permissions should be set appropriately. I hope you understand that we are not in these very specific cases. This is of course a different story for the second case you brought up, which is about the read permission of `compose.yml`. Let me sidetrack a second to note that your screen capture shows other files around, with unusual permissions that are not coming from our standard VPS install. So I'll address only the issue of the `read` permissions of the `compose.yml`: There are very few cases where the file could be read from a non-root account just because the host part of our standard VPS doesn't have non-root non-system account. The only service running on the host is `sshd` which is running as root anyway because it needs to run `setuid` to be able to spawn a login shell as any user. This leaves us only one way to really be able to read `compose.yml` from an unpriviledged account : breaking in one of the dockerized service and breaking through the linux container namespacing while still being namespaced in an unpriviledged user for the host. If this seems hard at first sight, it's probably the only place I could find some very hypothetical threat that would be mitigated by removing the read permission of `compose.yml`. But even these could justify the change. And I must admit that the change seems also rather painless, so even if I'm not sure of the full pertinence of this change, I would NOT have any reason to refuse a nice and clean PR from your side. If you were looking for simple way to contribute to this code, this is probably one of the simplest patch to do. It would fit nicely in the `myc-update` process so as to make sure all managed VPS gets this change on the next update. If unsure, we generally appreciate that you test appropriately your contribution by running it on a fresh debian 9/10 first install and a previously deployed VPS (with running dockers) updated thanks to `myc-update`.

As a side note, /opt/apps/myc-deploy is a git repository, and if it is used as it was intended at some point, to store versions of compose.yml. The removal of read permission for other should be done on the full directory and recursively to be sure to hit all history.

We didn't decide yet what strategy to apply for possible git push of this history as it would means that the remote git history would need to be also protected in unusual ways for a git repository and access would need to be protected to ensure only the VPS owner and the possible admins could read this remote.

For now, I'm not aware of VPS where a git commit would have been issued, and anyway we are NOT pushing compose.yml changes (VPS owners don't have write permission to the remote).