[ale] Write permission

[DJ-Pfulio]

Disable all rsync/scp/sftp to-from the machine.  Setup a daily migration
task for them to work around - they put the files they want transfered
on X-box in Y-directory and  by 6am the following morning, those files
are on the cluster.  Don't allow direct network access to the cluster
either.  This is how the DoD does it. They need to physically visit the
systems where that network is allowed inside a secure, guarded, room. No
paper, pencils, storage devices allowed. No coats, either. ;)  I've
worked in this sort of environment, BTW.

Either you need security or you don't.

It is our job to make certain that what we do doesn't allow it to be
compromised. Need to be 100% certain and 1 complex method of protection
is not sufficient.  I want belts AND suspenders for stuff like this.

I'd also get a legally binding contract in front of anyone involved
which advise this is illegal and lists clearly all the possible outcomes
to violation - start with being expelled, fired, whatever the legal fine
would be ($1k/per datum leaked?) then move up to jail time (assuming
that is part of it).



On 05/16/16 17:10, Jim Kinney wrote:
> On Mon, 2016-05-16 at 16:43 -0400, DJ-Pfulio wrote:
>> Force the processes to run under a different userid that is locked down.
>> Users would use sudo to access that other account and launch the
>> program(s) with approved options only. Nothing else.  That user account
>> could have access to create an LV for all temporary data, if you wanted
>> to go crazy.  Just don't let their normal userids have access to the
>> temporary areas.
> 
> A sudo process to run a script that launches their binaries from hard
> coded folder and the running user can only write to a specific folder
> for scratch and output. 
>> Are the programs developed in-house?  Hard to stop the devs from making
>> debug stuff write wherever they want.
> 
> Yep. All custom garbageIO/code. Thus the need to lock down the output space.
> 
> Everyone is trained on using the data safely. Looking for ways to block
> deliberate rule breakers from putting data files in their home dirs.
> Also to block them from scp that data to their laptops.
> 
> The more I poke at this the more I'm leaning towards an selinux rule
> set. It _will_ work but it will be a bit of a performance hit. It still
> all boils down to what is in the output files. Are substantial portions
> copied? These are currently video files so single frames are ePHI. Other
> groups use all custom binary data converted to text for processing. It's
> supposed to be scrubbed but without a manual analysis, not entirely
> certain. 
>> On 05/16/16 10:48, Jim Kinney wrote:
>>> I'm trying to envision a process that will have some funky
>>> permissions in play and would appreciate ideas. Data is sensitive and
>>> stored in encrypted partition. Only users in the approved group can
>>> read in that folder. They need to run that data through custom code
>>> that may do temporary writes somewhere. That will need to be locked
>>> down and either encrypted or overwritten after use (or both). This is
>>> the easy part. I need to prevent that data from being written/copied
>>> anywhere else even if they have write permission (home dir). I run
>>> CentOS 7 systems so I have selinux. However, once this scales off the
>>> individual research system to the cluster, I've disabled selinux on
>>> the cluster for performance reasons. I can activate it if the
>>> encrypted folders are mounted and limit runs to specific nodes if
>>> always running. So I'm seeing (sort of. Not fully thought out yet) a
>>> rule that allows data read with binaries of a particular type that
>>> can only write to particular folders. Note that the final output of
>>> the data run is not sensitive but intermediate data may be. To run a
>>> process requires writing binary to specific folder. That folder
>>> forces all contents to be special type that is subject to selinux
>>> rule. Can't allow users to directly read the files in order to
>>> disallow 'cat file > newfile' to disallowed folder. Data files are
>>> (currently) video and output is ascii text so it's possible to check
>>> file types on output before allowed to copy to new folder. However,
>>> the input data files may be ascii for a different groups work.