Re: website permissions and ownership
On Tue, Feb 2, 2021, 2:10 AM Richard Hector wrote: > Hi all, > > I'm reviewing how I set up websites (mostly Wordpress at the moment), > and would like other opinions on what I'm planning is sane. > > My plan is to have a user eg "mysite" that owns all/most of the standard > files and directories. > > The webserver (actually php-fpm) would run as "mysite-run". > > Group ownership of the files would then be mysite-run, but group-write > permission would not be granted except where required, eg the 'uploads' > and 'cache' directories. > > Files in those directories, created by the php-fpm process, would > obviously be owned by mysite-run. > > Alternatively the group ownership of most of the directories could > remain with mysite, and but the uploads and cache directories > group-owned (and group-writeable) by mysite-run. > > The objective of course is that site code can't write to anything it > shouldn't. I know that means that I'll have to install upgrades, plugins > etc with the wp cli tool. > > I earlier had thoughts of improving this with ACLs, but a) this got > really complicated and b) it didn't seem to solve some of the problems I > was trying to solve. > > I wanted to be able to allow other users (those who might need to update > sites) to be able to log in as themselves and make changes, but IIRC > nothing (other than sudo or setuid tools) will allow them to set the > ownership back to 'mysite', which is what I want it to be. I'm aware of > bindfs, which allows fuse mounting of filesystems with permission > translation, but as far as I can tell, it doesn't allow mapping of > userids. Tools could help, but I'd rather some of these users had SFTP > access only, which would prevent them being used. > > Any thoughts? > I like some of the ideas, mentioned by others, including SELinux issues. But, for a High Security Website, I prefer Lighttpd over Apache2 and, especially WordPress. Am I mostly on the right track? > Mostly. > > Thanks, > Richard > Kenneth Parker
Re: website permissions and ownership
On 2/02/21 10:42 pm, Jeremy Ardley wrote: On 2/2/21 5:32 pm, Jeremy Ardley wrote: On 2/2/21 4:55 pm, Richard Hector wrote: What you are doing sounds pretty O.K. Though I personally also use SELinux for web facing services. Thanks. I haven't looked in to SELinux. I looked at AppArmor, but it appears that it won't work as expected in an LXC container, which is where I run this. Would SELinux work there? SELinux, from what I can see, seems more complex to learn than AppArmor. SELinux is quite hard to get right, but when it's done properly it's very hard to exploit. Basically if it's not explicitly permitted it's forbidden. SELinux has the advantage that it by default enforces rules that you should probably already have in place. So for example it will automatically stop writes to web content by the web server. You have to explicitly allow the web server to make modifications to specific files or directories. SELinux makes you think about what is important to you and what you think should be alterable on your website. Getting back to my staging scenario, you start with default SELinux rules completely restricting web server write access to content. You'd have another set of SELinux rules that allow some other process to make changes to the content. You may even have a set of SELinux rules allowing the web server to write to an upload directory - but likely not read from it. Further to this, web servers can interact not only with disk content, but databases, content back-ends (e.g. php-fpm) and even with hardware and communication devices. SELinux blocks all this until such time as you do the analysis and decide that particular interactions should be allowed. It's a pain to get right, but compared to the pain of your server being exploited, not so much. You've reminded me that of course nginx (in my case) as well as php-fpm needs read access to a bunch of stuff (not php ... unless it's a site that publishes php scripts ...), but no write to anything. So I'll need to revise my model for that, at least :-( Though I guess that can be covered by 'other' permissions (with nginx config to prevent serving php and other files that it shouldn't). I think I'm leaving SELinux in the 'too hard' basket for the time being; it looks like it would need changes to a bunch of other stuff as well (eg postfix ...) Thanks, Richard
Re: website permissions and ownership
On 2/2/21 5:32 pm, Jeremy Ardley wrote: On 2/2/21 4:55 pm, Richard Hector wrote: What you are doing sounds pretty O.K. Though I personally also use SELinux for web facing services. Thanks. I haven't looked in to SELinux. I looked at AppArmor, but it appears that it won't work as expected in an LXC container, which is where I run this. Would SELinux work there? SELinux, from what I can see, seems more complex to learn than AppArmor. SELinux is quite hard to get right, but when it's done properly it's very hard to exploit. Basically if it's not explicitly permitted it's forbidden. SELinux has the advantage that it by default enforces rules that you should probably already have in place. So for example it will automatically stop writes to web content by the web server. You have to explicitly allow the web server to make modifications to specific files or directories. SELinux makes you think about what is important to you and what you think should be alterable on your website. Getting back to my staging scenario, you start with default SELinux rules completely restricting web server write access to content. You'd have another set of SELinux rules that allow some other process to make changes to the content. You may even have a set of SELinux rules allowing the web server to write to an upload directory - but likely not read from it. Further to this, web servers can interact not only with disk content, but databases, content back-ends (e.g. php-fpm) and even with hardware and communication devices. SELinux blocks all this until such time as you do the analysis and decide that particular interactions should be allowed. It's a pain to get right, but compared to the pain of your server being exploited, not so much. -- Jeremy OpenPGP_signature Description: OpenPGP digital signature
Re: website permissions and ownership
On 2/02/21 10:37 pm, john doe wrote: On 2/2/2021 9:55 AM, Richard Hector wrote: On 2/02/21 9:11 pm, Jeremy Ardley wrote: On 2/2/21 3:09 pm, Richard Hector wrote: Hi all, I'm reviewing how I set up websites (mostly Wordpress at the moment), and would like other opinions on what I'm planning is sane. My plan is to have a user eg "mysite" that owns all/most of the standard files and directories. The webserver (actually php-fpm) would run as "mysite-run". Group ownership of the files would then be mysite-run, but group-write permission would not be granted except where required, eg the 'uploads' and 'cache' directories. Files in those directories, created by the php-fpm process, would obviously be owned by mysite-run. Alternatively the group ownership of most of the directories could remain with mysite, and but the uploads and cache directories group-owned (and group-writeable) by mysite-run. The objective of course is that site code can't write to anything it shouldn't. I know that means that I'll have to install upgrades, plugins etc with the wp cli tool. I earlier had thoughts of improving this with ACLs, but a) this got really complicated and b) it didn't seem to solve some of the problems I was trying to solve. I wanted to be able to allow other users (those who might need to update sites) to be able to log in as themselves and make changes, but IIRC nothing (other than sudo or setuid tools) will allow them to set the ownership back to 'mysite', which is what I want it to be. I'm aware of bindfs, which allows fuse mounting of filesystems with permission translation, but as far as I can tell, it doesn't allow mapping of userids. Tools could help, but I'd rather some of these users had SFTP access only, which would prevent them being used. Any thoughts? Am I mostly on the right track? Thanks, Richard What you are doing sounds pretty O.K. Though I personally also use SELinux for web facing services. Thanks. I haven't looked in to SELinux. I looked at AppArmor, but it appears that it won't work as expected in an LXC container, which is where I run this. Would SELinux work there? SELinux, from what I can see, seems more complex to learn than AppArmor. To accomodate other users I suggest you set up staging areas where they can upload content that you periodically sync to the website using a privileged process. This means you don't have to give any rights to users other than access to the staging areas. Yes. I can foresee difficulties with my clients not being able to see their changes immediately. Inotify could be of interest there by monitoring the staging area. 1) https://man7.org/linux/man-pages/man7/inotify.7.html Agreed. Worth bearing in mind, thanks. Though IIRC it's quite a pain to keep watch on an entire directory tree; you have to maintain the list of watched directories rather than just watching the top. Cheers, Richard
Re: website permissions and ownership
On 2/2/2021 9:55 AM, Richard Hector wrote: On 2/02/21 9:11 pm, Jeremy Ardley wrote: On 2/2/21 3:09 pm, Richard Hector wrote: Hi all, I'm reviewing how I set up websites (mostly Wordpress at the moment), and would like other opinions on what I'm planning is sane. My plan is to have a user eg "mysite" that owns all/most of the standard files and directories. The webserver (actually php-fpm) would run as "mysite-run". Group ownership of the files would then be mysite-run, but group-write permission would not be granted except where required, eg the 'uploads' and 'cache' directories. Files in those directories, created by the php-fpm process, would obviously be owned by mysite-run. Alternatively the group ownership of most of the directories could remain with mysite, and but the uploads and cache directories group-owned (and group-writeable) by mysite-run. The objective of course is that site code can't write to anything it shouldn't. I know that means that I'll have to install upgrades, plugins etc with the wp cli tool. I earlier had thoughts of improving this with ACLs, but a) this got really complicated and b) it didn't seem to solve some of the problems I was trying to solve. I wanted to be able to allow other users (those who might need to update sites) to be able to log in as themselves and make changes, but IIRC nothing (other than sudo or setuid tools) will allow them to set the ownership back to 'mysite', which is what I want it to be. I'm aware of bindfs, which allows fuse mounting of filesystems with permission translation, but as far as I can tell, it doesn't allow mapping of userids. Tools could help, but I'd rather some of these users had SFTP access only, which would prevent them being used. Any thoughts? Am I mostly on the right track? Thanks, Richard What you are doing sounds pretty O.K. Though I personally also use SELinux for web facing services. Thanks. I haven't looked in to SELinux. I looked at AppArmor, but it appears that it won't work as expected in an LXC container, which is where I run this. Would SELinux work there? SELinux, from what I can see, seems more complex to learn than AppArmor. To accomodate other users I suggest you set up staging areas where they can upload content that you periodically sync to the website using a privileged process. This means you don't have to give any rights to users other than access to the staging areas. Yes. I can foresee difficulties with my clients not being able to see their changes immediately. Inotify could be of interest there by monitoring the staging area. 1) https://man7.org/linux/man-pages/man7/inotify.7.html -- John Doe
Re: website permissions and ownership
On 2/2/21 4:55 pm, Richard Hector wrote: What you are doing sounds pretty O.K. Though I personally also use SELinux for web facing services. Thanks. I haven't looked in to SELinux. I looked at AppArmor, but it appears that it won't work as expected in an LXC container, which is where I run this. Would SELinux work there? SELinux, from what I can see, seems more complex to learn than AppArmor. SELinux is quite hard to get right, but when it's done properly it's very hard to exploit. Basically if it's not explicitly permitted it's forbidden. SELinux has the advantage that it by default enforces rules that you should probably already have in place. So for example it will automatically stop writes to web content by the web server. You have to explicitly allow the web server to make modifications to specific files or directories. SELinux makes you think about what is important to you and what you think should be alterable on your website. Getting back to my staging scenario, you start with default SELinux rules completely restricting web server write access to content. You'd have another set of SELinux rules that allow some other process to make changes to the content. You may even have a set of SELinux rules allowing the web server to write to an upload directory - but likely not read from it. -- Jeremy OpenPGP_signature Description: OpenPGP digital signature
Re: website permissions and ownership
On 2/02/21 9:11 pm, Jeremy Ardley wrote: On 2/2/21 3:09 pm, Richard Hector wrote: Hi all, I'm reviewing how I set up websites (mostly Wordpress at the moment), and would like other opinions on what I'm planning is sane. My plan is to have a user eg "mysite" that owns all/most of the standard files and directories. The webserver (actually php-fpm) would run as "mysite-run". Group ownership of the files would then be mysite-run, but group-write permission would not be granted except where required, eg the 'uploads' and 'cache' directories. Files in those directories, created by the php-fpm process, would obviously be owned by mysite-run. Alternatively the group ownership of most of the directories could remain with mysite, and but the uploads and cache directories group-owned (and group-writeable) by mysite-run. The objective of course is that site code can't write to anything it shouldn't. I know that means that I'll have to install upgrades, plugins etc with the wp cli tool. I earlier had thoughts of improving this with ACLs, but a) this got really complicated and b) it didn't seem to solve some of the problems I was trying to solve. I wanted to be able to allow other users (those who might need to update sites) to be able to log in as themselves and make changes, but IIRC nothing (other than sudo or setuid tools) will allow them to set the ownership back to 'mysite', which is what I want it to be. I'm aware of bindfs, which allows fuse mounting of filesystems with permission translation, but as far as I can tell, it doesn't allow mapping of userids. Tools could help, but I'd rather some of these users had SFTP access only, which would prevent them being used. Any thoughts? Am I mostly on the right track? Thanks, Richard What you are doing sounds pretty O.K. Though I personally also use SELinux for web facing services. Thanks. I haven't looked in to SELinux. I looked at AppArmor, but it appears that it won't work as expected in an LXC container, which is where I run this. Would SELinux work there? SELinux, from what I can see, seems more complex to learn than AppArmor. To accomodate other users I suggest you set up staging areas where they can upload content that you periodically sync to the website using a privileged process. This means you don't have to give any rights to users other than access to the staging areas. Yes. I can foresee difficulties with my clients not being able to see their changes immediately. I could also probably use a git hook to deploy a suitably tagged branch, but then I also probably need to help my clients use git :-) Or if I had some kind of web portal for them, I could give them a deploy button, but I'm not ready to do that yet. This also helps in disaster recovery as you can set up and maintain the entire static site from staging areas. Ideally you should be able to fire up a virtual server and load it from the staging area whenever you want. If it goes down, fire up another one. Your only issue is database records for which you'll need to set up a different recovery process. Useful points too. Thanks, Richard
Re: website permissions and ownership
On 2/2/21 3:09 pm, Richard Hector wrote: Hi all, I'm reviewing how I set up websites (mostly Wordpress at the moment), and would like other opinions on what I'm planning is sane. My plan is to have a user eg "mysite" that owns all/most of the standard files and directories. The webserver (actually php-fpm) would run as "mysite-run". Group ownership of the files would then be mysite-run, but group-write permission would not be granted except where required, eg the 'uploads' and 'cache' directories. Files in those directories, created by the php-fpm process, would obviously be owned by mysite-run. Alternatively the group ownership of most of the directories could remain with mysite, and but the uploads and cache directories group-owned (and group-writeable) by mysite-run. The objective of course is that site code can't write to anything it shouldn't. I know that means that I'll have to install upgrades, plugins etc with the wp cli tool. I earlier had thoughts of improving this with ACLs, but a) this got really complicated and b) it didn't seem to solve some of the problems I was trying to solve. I wanted to be able to allow other users (those who might need to update sites) to be able to log in as themselves and make changes, but IIRC nothing (other than sudo or setuid tools) will allow them to set the ownership back to 'mysite', which is what I want it to be. I'm aware of bindfs, which allows fuse mounting of filesystems with permission translation, but as far as I can tell, it doesn't allow mapping of userids. Tools could help, but I'd rather some of these users had SFTP access only, which would prevent them being used. Any thoughts? Am I mostly on the right track? Thanks, Richard What you are doing sounds pretty O.K. Though I personally also use SELinux for web facing services. To accomodate other users I suggest you set up staging areas where they can upload content that you periodically sync to the website using a privileged process. This means you don't have to give any rights to users other than access to the staging areas. This also helps in disaster recovery as you can set up and maintain the entire static site from staging areas. Ideally you should be able to fire up a virtual server and load it from the staging area whenever you want. If it goes down, fire up another one. Your only issue is database records for which you'll need to set up a different recovery process. -- Jeremy OpenPGP_signature Description: OpenPGP digital signature
website permissions and ownership
Hi all, I'm reviewing how I set up websites (mostly Wordpress at the moment), and would like other opinions on what I'm planning is sane. My plan is to have a user eg "mysite" that owns all/most of the standard files and directories. The webserver (actually php-fpm) would run as "mysite-run". Group ownership of the files would then be mysite-run, but group-write permission would not be granted except where required, eg the 'uploads' and 'cache' directories. Files in those directories, created by the php-fpm process, would obviously be owned by mysite-run. Alternatively the group ownership of most of the directories could remain with mysite, and but the uploads and cache directories group-owned (and group-writeable) by mysite-run. The objective of course is that site code can't write to anything it shouldn't. I know that means that I'll have to install upgrades, plugins etc with the wp cli tool. I earlier had thoughts of improving this with ACLs, but a) this got really complicated and b) it didn't seem to solve some of the problems I was trying to solve. I wanted to be able to allow other users (those who might need to update sites) to be able to log in as themselves and make changes, but IIRC nothing (other than sudo or setuid tools) will allow them to set the ownership back to 'mysite', which is what I want it to be. I'm aware of bindfs, which allows fuse mounting of filesystems with permission translation, but as far as I can tell, it doesn't allow mapping of userids. Tools could help, but I'd rather some of these users had SFTP access only, which would prevent them being used. Any thoughts? Am I mostly on the right track? Thanks, Richard
