[ale] Write permission

Jim Kinney jim.kinney at gmail.com
Mon May 16 18:18:02 EDT 2016


On Mon, 2016-05-16 at 18:06 -0400, DJ-Pfulio wrote:
> 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.
Happily, this isn't DoD. Just HIPPA. Must strike a balance between
absolute security (standalone system with no networking in a room with
armed guards will to shoot on site) and usability (woo! Free-for-all
and everyone has root - NOT ON MY WATCH!).
> Either you need security or you don't.
> 

Need security that prevents accidental relocation and makes deliberate
abuse difficult but most importantly, traceable back to the now
expelled/fired idiot.
> 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).
> 

They all have a series of classes in data protection. Bear in mind,
this is the same stuff (actually less identifiable) as what is visible
on nearly any computer screen at the hospital or clinic. The only
difference is quantity.
> 
> 
> 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.
> > > > 

> > > 

> > 

> 
> _______________________________________________
> Ale mailing list
> 
Ale at ale.org> 
http://mail.ale.org/mailman/listinfo/ale
> 
> See JOBS, ANNOUNCE and SCHOOLS lists at
> 
http://mail.ale.org/mailman/listinfo> 

-- 
James P. Kinney III

Every time you stop a school, you will have to build a jail. What you
gain at one end you lose at the other. It's like feeding a dog on his
own tail. It won't fatten the dog.
- Speech 11/23/1900 Mark Twain

http://heretothereideas.blogspot.com/

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ale.org/pipermail/ale/attachments/20160516/a5aa64b6/attachment.html>


More information about the Ale mailing list