Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #231331 > unrolled thread

website permissions and ownership

Back to article view | Back to linux.debian.user

Contents

  website permissions and ownership Richard Hector <richard@walnut.gen.nz> - 2021-02-02 08:10 +0100
    Re: website permissions and ownership Jeremy Ardley <jeremy@ardley.org> - 2021-02-02 09:20 +0100
      Re: website permissions and ownership Richard Hector <richard@walnut.gen.nz> - 2021-02-02 10:00 +0100
        Re: website permissions and ownership Jeremy Ardley <jeremy@ardley.org> - 2021-02-02 10:40 +0100
          Re: website permissions and ownership Jeremy Ardley <jeremy@ardley.org> - 2021-02-02 10:50 +0100
            Re: website permissions and ownership Richard Hector <richard@walnut.gen.nz> - 2021-02-02 11:00 +0100
        Re: website permissions and ownership john doe <johndoe65534@mail.com> - 2021-02-02 10:40 +0100
          Re: website permissions and ownership Richard Hector <richard@walnut.gen.nz> - 2021-02-02 10:50 +0100
    Re: website permissions and ownership Kenneth Parker <sea7kenp@gmail.com> - 2021-02-02 12:50 +0100

#231331 — 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

[toc] | [next] | [standalone]

#231332

[Multipart message — attachments visible in raw view] — view raw

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

[toc] | [prev] | [next] | [standalone]

#231333

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

[toc] | [prev] | [next] | [standalone]

#231334

[Multipart message — attachments visible in raw view] — view raw

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

[toc] | [prev] | [next] | [standalone]

#231337

[Multipart message — attachments visible in raw view] — view raw

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

[toc] | [prev] | [next] | [standalone]

#231338

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

[toc] | [prev] | [next] | [standalone]

#231335

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

[toc] | [prev] | [next] | [standalone]

#231336

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

[toc] | [prev] | [next] | [standalone]

#231339

[Multipart message — attachments visible in raw view] — view raw

On Tue, Feb 2, 2021, 2:10 AM Richard Hector <richard@walnut.gen.nz> 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

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.user

csiph-web