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.rambaldi@ieo.eu
[e] davide.rambaldi@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 <bbolker@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]]

