Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > alt.os.development > #9366
| 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> |
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 | Next — Previous in thread | Next in thread | Find similar | Unroll 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