[Gluster-users] untrusted users

Tue Oct 22 12:17:44 UTC 2019

Ah. More data. You are doing this with containers.

Take a long hard look at OpenShift. On rhel8/centos8/fedora28+ it allows devs to run containers without having root access. It's core is kubernetes.

It's a really good idea to create users inside the containers. Devs hate this (get over it!) But it separates privileges for better security.

Data sharing between users is done with group membership. Fred has his own default group. So does Wilma. They are both also in a group Flintstone. With sgid settings, all files written in a Flinstone group folder are group Flintstone but each user owns their files. Betty and Barney are also users. Neither is in Flinstone group so they have no access. They get their group, Rubble, and Flinstone can't see those files. 

If a Flintstone needs to share a file with a Rubble, a common way is to copy that file to /tmp and the current owner can then chgrp to Rubble and chown to Betty. Betty now moves that file where it's needed.

If much more sharing is needed than just a file, create a third group, neighbors, and put all 4 users in it, or experiment with groups of groups and put Flintstone and Rubble groups as members (check kernel level and version of security tools. FreeIPA can also do this) and anything in the neighbors folder gets set group id neighbors and all 4 users can see it.

SELinux is a different way to do this. It blocks users from changing group permissions and forces really solid security bits to be set that protect access. Most devs start by disabling selinux as its far more sysadmin than they want to be constrained by. It also makes a system that is historically nearly unbreakable from a data/user security perspective.

On October 22, 2019 12:12:26 AM EDT, Pankaj Kumar <pankajk81 at gmail.com> wrote:
>Hi Jim
>
>Thanks a lot for your detailed response. Some clarifications:
>
>>> If they have no sudo, they can't mount. Use a centralized
>authentication
>system like freeipa or IdM. Every user should have their own userid
>that's
>unique. No exceptions.
><< Every user has a user id. And they also have sudo access to their
>units.
>Take for eg, AWS. You have a user id you login with but you get root on
>the
>Virtual Machine. We know the username but users have full access to the
>local machine.
>
>>> Make mounts for them in fstab. Set ownership and groups on mount
>points
>so each user is restricted to their folder only.
><< If every user has his own mount point, then how does he share
>anything
>with other users?
>
>>> I work in HIPAA rules now, DoD clearance rules earlier. Users are
>not to
>be trusted. Other sysadmins are barely trustable. If users have any
>access
>to adjust the system configuration in any way, take it away. That's
>your
>job not theirs. It's easier to say no 100 times a day than spend 2
>weeks in
>front of lawyers explaining why untrusted users could create a mess
>that
>involves lawyers and courts, fines and jail time.
><< Very thankful of the warning. We will do our best, get outside
>verifications, launch prizes for hacks do everything it takes. We will
>only
>do it when we are certain. We will make sure to limit access at the
>higher
>levels. All online file sharing systems(google drive, Dropbox) do this
>thing. That's why we are thinking of writing a layer over Gluster
>possibly
>to achieve this.
>
>>> If your OS won't support basic system security, choose something
>that
>will. Some Linux distros are not usable in a multiple user environment
>(kali is a prime example). I work in an Enterprise environment so I use
>RedHat/CEntOS.
><< We are using containers and we intend to give users a choice of base
>images. They will be the only user on their linux.
>
>>> Sorry to sound really harsh but this sounds like a nightmare that
>could
>be avoided with a better sysadmin plan. Users are terrible sysadmin.
>Programmers are too. Sysadmins are not very good programmers :-(
><< That's what we are trying to do here. We like GlusterFS and I think
>we
>can build something on top of it with only a few tweaks. It supports
>ACLs
>already. If we could write a layer such that we force a container to be
>able to mount as the specified user only or not mount at all, we have
>what
>we want already.
>
>
>Thanks
>
>On Mon, Oct 21, 2019 at 8:00 PM Jim Kinney <jim.kinney at gmail.com>
>wrote:
>
>> Shell access to untrusted users. I would fight that tooth and nail as
>a
>> sysadmin. User that are untrusted get accounts deactivated.
>>
>> If they have no sudo, they can't mount. Make mounts for them in
>fstab. Set
>> ownership and groups on mount points so each user is restricted to
>their
>> folder only. Use a centralized authentication system like freeipa or
>IdM.
>> Every user should have their own userid that's unique. No exceptions.
>>
>> I work in HIPAA rules now, DoD clearance rules earlier. Users are not
>to
>> be trusted. Other sysadmins are barely trustable. If users have any
>access
>> to adjust the system configuration in any way, take it away. That's
>your
>> job not theirs. It's easier to say no 100 times a day than spend 2
>weeks in
>> front of lawyers explaining why untrusted users could create a mess
>that
>> involves lawyers and courts, fines and jail time.
>>
>> If your OS won't support basic system security, choose something that
>> will. Some Linux distros are not usable in a multiple user
>environment
>> (kali is a prime example). I work in an Enterprise environment so I
>use
>> RedHat/CEntOS.
>>
>> If users can't get things done with out being root, someone has
>really
>> messed up the work flow design.
>>
>> Sorry to sound really harsh but this sounds like a nightmare that
>could be
>> avoided with a better sysadmin plan. Users are terrible sysadmin.
>> Programmers are too. Sysadmins are not very good programmers :-(
>>
>>
>> On October 21, 2019 10:03:46 PM EDT, pankaj kumar
>> <pankaj at datacabinet.systems> wrote:
>>>
>>> We are attaching a gluster storage to our cluster. We give shell
>access
>>> to our cluster to untrusted users. Each user has a folder in
>gluster. The
>>> problem is that the users could get to mount as any user id and then
>access
>>> the other users files as their own. Is there a way to authenticate a
>user
>>> before a mount?
>>>
>>> If there is none, can you help us implement a thin authentication
>layer
>>> over mount? Where should we get started.
>>>
>>> Thanks,
>>>
>>
>> --
>> Sent from my Android device with K-9 Mail. All tyopes are thumb
>related
>> and reflect authenticity.
>> ________
>>
>> Community Meeting Calendar:
>>
>> APAC Schedule -
>> Every 2nd and 4th Tuesday at 11:30 AM IST
>> Bridge: https://bluejeans.com/118564314
>>
>> NA/EMEA Schedule -
>> Every 1st and 3rd Tuesday at 01:00 PM EDT
>> Bridge: https://bluejeans.com/118564314
>>
>> Gluster-users mailing list
>> Gluster-users at gluster.org
>> https://lists.gluster.org/mailman/listinfo/gluster-users
>>

-- 
Sent from my Android device with K-9 Mail. All tyopes are thumb related and reflect authenticity.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gluster.org/pipermail/gluster-users/attachments/20191022/a829f663/attachment.html>