Is like comma 22: - They hire you to use a console and you will be fired if you use a console!
I am italian, and for us, this kind of contradictions are normal ... ----------------------------------------------------- Davide Rambaldi, PhD. ----------------------------------------------------- IEO ~ MolMed [e] davide.ramba...@ieo.eu [e] davide.ramba...@gmail.com On May 20, 2013, at 5:09 PM, Ben Bolker wrote: > On 13-05-20 04:42 AM, Barry Rowlingson wrote: >> On Sun, May 19, 2013 at 7:16 PM, Ben Bolker <bbol...@gmail.com> wrote: >>> >>> The workstations have no access to external networks, >>> nor to external media (thumb drives etc.) [information transfer to the >>> outside world is via shared drives that can be accessed by >>> administrators with network access]. >>> >>> * I stipulate that (1) the security policies don't make sense, >> >> Correct. If the machines aren't on an external network and have no >> removable media then this isn't about security from the outside >> hacker, its about trust. The organisation does not trust YOU. >> >> (2) >>> allowing users access to arbitrary shell commands should _not_ represent >>> a security risk on a well-administered, modern operating system (they're >>> running WinXP), >> >> When does WinXP go out of support? Even so, the PC isn't on the >> network right? So what's the security issue? Doesn't make sense. You >> can't stomp on other people's files. Would it matter if you could >> accidentally see other people's files because they set permissions >> loosely? How compartmentalised are the projects? > > That is indeed one of the major concerns. The administrators could > certainly lock the file access down more than they have (permissions are > restricted, but I have information about the existence of lots of > directories that I don't have permission to access: the system would > probably be more secure if I couldn't even see the top level of these > directories). > >> (3) R probably offers many other avenues for system >>> access to a malicious user, even in the absence of shell access, >>> compilers, etc.. >> >> The 'malicious user' here is on the inside. The only way to get on >> the machine is to be physically there? Then a malicious user can only >> be a trusted user gone bad. A sufficiently malicious user with >> hardware access can (nearly) always break the thing open and get at >> the data (even if it comes down to reading data lines with a tap to >> get at unencrypted streams). Tell the security guys they need to lock >> the PCs up in a room and provide thin client access over a secure >> private network at once. Enjoy your new Windows Client Access License >> costs. >> >> Glad I don't work for someone like that. > > For what it's worth, (1) the people I deal with directly are very > nice, but not technically astute; the problem is more one of a large > bureaucracy covering its ass in some nonsensical ways; (2) this is only > a tiny component of my work. If I get really frustrated with this I can > just drop it. > > I agree with your analysis of the real security situation, more or > less. (The PCs are pretty secure physically; it would be pretty hard to > break into the boxes without being noticed ...), but I think this > <http://xkcd.com/651/> is a pretty good analogy for the kind of > argument I could get into here. > > ______________________________________________ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel [[alternative HTML version deleted]] ______________________________________________ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
