Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > alt.os.development > #9366

Re: The morality of operating system security

From Rod Pemberton <NoHaveNotOne@bcczxcfre.cmm>
Newsgroups alt.os.development
Subject Re: The morality of operating system security
Date 2016-04-01 20:24 -0400
Organization Aioe.org NNTP Server
Message-ID <20160401202426.293af50b@_> (permalink)
References <nde25k$bkn$1@dont-email.me> <20160329173929.65060450@_> <ndhme3$9p5$1@dont-email.me> <20160330231852.794ac607@_> <ndlavp$85d$1@dont-email.me>

Show all headers | View raw


On Fri, 1 Apr 2016 09:22:58 +0100
James Harris <james.harris.1@gmail.com> wrote:

> On 31/03/2016 04:18, Rod Pemberton wrote:
> > On Thu, 31 Mar 2016 00:13:49 +0100
> > James Harris <james.harris.1@gmail.com> wrote:
> >> On 29/03/2016 22:39, Rod Pemberton wrote:  
> >>> On Tue, 29 Mar 2016 15:09:35 +0100
> >>> James Harris <james.harris.1@gmail.com> wrote:  

...

> Wouldn't it be feasible to say that a certain administrator, using a 
> certain terminal and a particular program, could access a specific
> piece of data in a limited way? That way, access to the data could be
> limited by login id, terminal authorisation and accessing program.

Yes, but usually the administrator has full access and so is the one
setting up the policy that would restrict the terminal access.  They
could remove the policy or transfer the policy as they desired.  Also,
since the admin has full access, they can log in as that user via
another terminal, or as that user on the restricted terminal if the
log in policy prohibits log ins from other terminals.  Of course, this
is Unix model of 'root' using 'su' and 'sudo' and being able to set
user and terminal log in policy.

Basically, AISI, you're wanting an admin without full admin privileges,
i.e., you'd need two admin's.  One higher-level admin for setting up the
restricted terminal(s), user log in policies, and user accounts.  This
higher-level admin would need more privilege than the lower-level admin
to prohibit the lower-level admin from modifying the the terminal
restrictions, account log in policies, or creating accounts with
higher-level privilege.  The lower-level admin would also need to be
restricted from using other terminals, logging in as other users, or
using 'su' and 'sudo' for privilege escalation.  If the lower-level
admin can escalate privilege or log in as the higher-level admin,
you've lost control.  However, the lower-level admin would still need
to be able to have full access to everything else to do the majority of
the system administration.  The higher-level admin would need to
be blocked from any system administration unrelated to accounts as the
admin is likely not qualified for that.  I had some Unix SysV
administration experience decades ago and a tidbit from Linux nowadays,
but I'm not sure how to set this up to work.  I never had the
"pleasure" of system admin on high security DEC VAXs.  Maybe someone
else knows how or which systems allow what you want.

> > 2) how do you prevent CDs or backups from being made?
> >
> > Most computers have CDs in them.  Those same computers use the CDs,
> > or laser-discs, or tape, etc, to make backups.  It's usually the
> > admin's job to make those backups.  I'm not familiar with the
> > particulars of the example you cite, but it was probably his job
> > to do that, and then mail them to secure storage.  He could
> > have diverted the CDs, or they could have been lost, misplaced,
> > or stolen.  It's up to authorities to find out.  
> 
> That illustrates that people who "need" access generally get access
> to entire files of information - and that there is no restriction on
> what they can do with those files. OSes have file permissions and
> that is simply not adequate.

I think it's more a matter of setting up privileges to restrict
access to files is a total PIA.  Every time the admin comes back
from lunch, someone else needs access to the file or data for
some valid reason, e.g., backup, run a report, redo a report,
legal department lawsuit, management review, audit,  They have
to set basic privileges and then lock and unlock the file over
and over again, or have to keep adding users to their ACLs.  Even
on MS-DOS, with minimal 'H' for hidden and 'S' for system flags,
trying to backup up a system is problematic if any such privilege
flags are set.  Linux has even more flag combinations and bunches
of specialty settings.  DEC VAX had many such flags and per-user
ACLs too.  You have to remember that the vast, vast majority of
people are _lazy_, and not willing to work that hard.  Path of
least resistance. The same issue affects password choice.

> IMO it would be better to give people permission to specific fields
> of data. And, as above, if the program accessing the data has to be 
> authorised to do so, that program can limit itself to, say,
> displaying data on a screen, and not provide an option to do anything
> else with the data. That would prevent administrators making copies.

It's too much work and too many problems.  Someone has to decide for
each and every field whether each and every person has access.  What
if you have 10,000 employees? more?  5 million fields?  What if you've
had 30,000 employees move on to other companies over the past decade?
Who removes them or their account from the privileges?  A hacker
doesn't need to get access, they only need to hack an account which has
access, like restoring one of the 30,000 "dead" employee accounts that
no one removed from the field privileges because it was too much work
putting them on in the first place.

> When info that has been certified to be publicly readable is stored
> on disc it can be stored unencrypted. All other info should be stored
> in an encrypted form.

Someone, more specifically, some account, always has access to the
unencrypted data.

> > AISI, the real problem is either:
> > 1) company's aren't willing to pay for good security  
> 
> How would they spend more money to improve security?
> 

Security consultants, security firm, administrator experienced with
security too, hardware encryption, software encryption, yearly audit
with specialists, etc.

> Sorry, I don't mean me specifically. I was using "my" as a proxy for
> us as a population. To rephrase, I don't mind security services
> accessing our computers if it saves our lives from terrorism.
>
> I cannot actually think of a negative effect of allowing security 
> services access to our computers. They would not be interested in
> most of us, only of people who might be a threat.

So, technically, they're not likely to ever be accessing your computer.
Therefore, it's acceptable to you that they have access to everyone's
computers.

> I don't mind a limited group of people seeing my web browsing history
> or my emails or my texts etc. What I don't want is that info to
> escape and become visible to the wider public.

I'm not sure that is possible.  Once someone has the data, it
will usually propagate, typically, to someone in a foreign
country, where you have no legal recourse.  Where you do have
legal recourse, the data will be taken offline, but kept and
archived by those that have it.  So, you've stopped some of the
regional propagation, but you can't ever eliminate the data
from being accessible, or it being in someones possession,
e.g. in the "darknet", via P2P filesharing, in NSA or GCHQ
data archived by their spy activities.

> Actually, I am surprised that Apple is not subject to US laws which
> make it compulsory for them to allow the US security services to
> access their products.

...

> AIUI no one can export strong encryption from the US.

Didn't that change? ...  Not sure.

> Maybe that also gives the lie to Edward Snowden's claims about the 
> Smurfs he alleges to be contained within people's phones...?

Are you joking or serious? ...

There was an attempt to install bugging devices in all U.S. phones
years ago, e.g., Clipper chip.  Officially, it failed, because the U.S.
public found out about it.  Unofficially, they might have done
something.  E.g., we know that the NSA Echelon program "wiretapped"
world satellites.  We know the GCHQ spied on U.S. citizens, which is
illegal for the NSA to do, and handed the data over to the NSA, which
was ruled legal to do ...  CALEA law allows wiretapping of cellphones,
broadband, and possibly VoIP.  In addition to the NSA, the FBI is known
to have all sorts of data harvesting programs and technologies, e.g.,
email, telephone records, real-time Internet traffic, passwords.  The
NSA archives all emails in the U.S. post 9/11, including content, not
just header information.  For phone calls, non-NSA federal agencies can
only record the phone metadata without a warrant from a court.  They
need a warrant to record the conversation. The NSA has been known to
perform warrant-less wiretaps, including real-time Internet logging,
but they're a classified agency, so no legal recourse ... Even the
Library of Congress is in on the act.  They've archived all Twitter
posts. That's just the "tip of the iceberg" of Big Brother activities
in the U.S.  Given all such activity, the U.S. is technically a
border-line police state, and I think the U.K. and Australia are far
worse.  There are security cameras everywhere in the U.S., but they are
not tied in directly to police stations, where police are monitoring
every movement of a citizen in real-time for miles on end, like in the
U.K.  Police need warrants to access the video here.


Rod Pemberton

Back to alt.os.development | Previous | NextPrevious in thread | Next in thread | Find similar | Unroll thread


Thread

The morality of operating system security James Harris <james.harris.1@gmail.com> - 2016-03-29 15:09 +0100
  Re: The morality of operating system security JJ <jj4public@vfemail.net> - 2016-03-30 00:03 +0700
    Re: The morality of operating system security "wolfgang kern" <nowhere@never.at> - 2016-03-29 19:39 +0200
    Re: The morality of operating system security James Harris <james.harris.1@gmail.com> - 2016-03-30 23:54 +0100
      Re: The morality of operating system security JJ <jj4public@vfemail.net> - 2016-03-31 06:16 +0700
  Re: The morality of operating system security "wolfgang kern" <nowhere@never.at> - 2016-03-29 20:01 +0200
    Re: The morality of operating system security James Harris <james.harris.1@gmail.com> - 2016-03-30 23:59 +0100
      Re: The morality of operating system security Bernhard Schornak <schornak@web.de> - 2016-03-31 17:47 +0200
        Re: The morality of operating system security James Harris <james.harris.1@gmail.com> - 2016-04-01 08:11 +0100
          Re: The morality of operating system security Bernhard Schornak <schornak@web.de> - 2016-04-01 18:25 +0200
            Re: The morality of operating system security James Harris <james.harris.1@gmail.com> - 2016-04-01 23:10 +0100
              Re: The morality of operating system security Bernhard Schornak <schornak@web.de> - 2016-04-02 14:18 +0200
      Re: The morality of operating system security "wolfgang kern" <nowhere@never.at> - 2016-04-01 09:58 +0200
        Re: The morality of operating system security James Harris <james.harris.1@gmail.com> - 2016-04-01 10:06 +0100
  Re: The morality of operating system security Rod Pemberton <NoHaveNotOne@bcczxcfre.cmm> - 2016-03-29 17:39 -0400
    Re: The morality of operating system security James Harris <james.harris.1@gmail.com> - 2016-03-31 00:13 +0100
      Re: The morality of operating system security Rod Pemberton <NoHaveNotOne@bcczxcfre.cmm> - 2016-03-30 23:18 -0400
        Re: The morality of operating system security "Alexei A. Frounze" <alexfrunews@gmail.com> - 2016-03-31 00:31 -0700
          Re: The morality of operating system security Rod Pemberton <NoHaveNotOne@bcczxcfre.cmm> - 2016-03-31 16:57 -0400
        Re: The morality of operating system security James Harris <james.harris.1@gmail.com> - 2016-04-01 09:22 +0100
          Re: The morality of operating system security Rod Pemberton <NoHaveNotOne@bcczxcfre.cmm> - 2016-04-01 20:24 -0400
            Re: The morality of operating system security James Harris <james.harris.1@gmail.com> - 2016-04-09 18:25 +0100
              Re: The morality of operating system security Rod Pemberton <NoHaveNotOne@bcczxcfre.cmm> - 2016-04-09 18:57 -0400
                Re: The morality of operating system security James Harris <james.harris.1@gmail.com> - 2016-04-26 09:07 +0100
                Re: The morality of operating system security Rod Pemberton <NoHaveNotOne@bcczxcfre.cmm> - 2016-04-26 23:58 -0400
                Re: The morality of operating system security James Harris <james.harris.1@gmail.com> - 2016-04-27 07:01 +0100
                Re: The morality of operating system security Rod Pemberton <NoHaveNotOne@bcczxcfre.cmm> - 2016-04-27 05:42 -0400
                Re: The morality of operating system security James Harris <james.harris.1@gmail.com> - 2016-05-03 00:05 +0100
                Re: The morality of operating system security Rod Pemberton <NoHaveNotOne@bcczxcfre.cmm> - 2016-05-03 16:55 -0400
                Re: The morality of operating system security James Harris <james.harris.1@gmail.com> - 2016-05-04 09:00 +0100
                Re: The morality of operating system security Rod Pemberton <NoHaveNotOne@bcczxcfre.cmm> - 2016-05-04 17:22 -0400
                Re: The morality of operating system security James Harris <james.harris.1@gmail.com> - 2016-05-05 17:02 +0100
                Re: The morality of operating system security Rod Pemberton <NoHaveNotOne@bcczxcfre.cmm> - 2016-05-05 17:55 -0400
                Re: The morality of operating system security "Kerr Mudd-John" <admin@127.0.0.1> - 2016-05-09 14:58 +0100
                Re: The morality of operating system security Rod Pemberton <NoHaveNotOne@bcczxcfre.cmm> - 2016-05-12 17:46 -0400
                Re: The morality of operating system security James Harris <james.harris.1@gmail.com> - 2016-05-15 00:11 +0100
                Re: The morality of operating system security James Harris <james.harris.1@gmail.com> - 2016-04-27 07:44 +0100

csiph-web