Groups > comp.os.linux.development.system > #653

Re: shred or scrub

From	crankypuss <crankypuss@nomail.invalid>
Newsgroups	comp.os.linux.development.system
Subject	Re: shred or scrub
Date	2014-04-26 04:02 -0600
Organization	A noiseless patient Spider
Message-ID	<ljg06q$f5s$1@dont-email.me> (permalink)
References	(7 earlier) <lj6p5h$m0g$1@dont-email.me> <lj89en$q2a$1@dont-email.me> <ljbt7r$5bc$1@dont-email.me> <ljdbhe$ol8$1@dont-email.me> <87k3adxomn.fsf@sable.mobileactivedefense.com>

Show all headers | View raw

On 04/25/2014 12:14 PM, Rainer Weikusat wrote:
> crankypuss <crankypuss@nomail.invalid> writes:
>> On 04/24/2014 02:46 PM, David Brown wrote:

<lots of snippage, apologies if results have become muddled>

from RW:
> Every filesystem is at the mercy of the storage devices it is used on.

Every filesystem is *limited* by the storage devices it uses, which is 
not identical to "at the mercy of".  Device behavior can be monitored 
and its capabilities can become restricted, *if* the filesystem is 
sufficiently sophisticated.  Without digging into code, just being aware 
of the multi-threaded nature of what is required for this sort of thing, 
I am doubtful that such is often employed at this stage of the game.

The more our technology moves toward cloud computing and 
servers-as-devices, the more we have devices-acting-as-servers, the more 
important this will become.  I think we are already running somewhat 
"behind the curve" and need to consider some catch-up.

DB:
>>> [...] - your data is only as safe as your key.  But the
>>> usual procedure for encrypted partitions is to enter your key (or
>>> passphrase) at the keyboard when mounting.

C:
>> Yes, and once you have done so, the mounted partition is no more
>> secure than a non-encrypted partition; data security has, through your
>> supplying the key, been degraded from whatever level of security is
>> provided by the encryption algorithm used,

RW:
> It is actually worse because the key must be retained in memory which
> implies that it is possible to get it out of that again, even in ways
> people usually don't want to think about, cf
>
> https://freedom-to-tinker.com/blog/felten/new-research-result-cold-boot-attacks-disk-encryption/
[...]

C:
>> to the simple "security"
>> provided by the linux protection modes.  To quote you [DB], "for the
>> paranoid, less than 100% is not good enough".

RW:
> It supports stopping "unauthorized personnel" from "accessing files
> they're not supposed to access". That's enough 'security'.

It isn't just about personnel.  The model that relies on 'root' as 
superuser has come askew imo.  There are no "superuser" people, some 
know more than others but none of us know it all; making the split 
between superuser/other is inherently flawed because it does not 
represent reality.

Give someone the root password, or add someone to the "sudoers" list, 
and you've opened the gates.  Worstcase is when someone wants a swell 
new application and needs to install it as root; that opens a hole 
between what the person believes about the application, and what is true 
about it.  The root password is required for too many things, too many 
people have access to it.

>> I am of the opinion that the linux protection modes inherited from
>> Unix are not very "adequate", and the idea of a "superuser" is
>> inherently crippled "security".  The whole user/group/world concept
>> along with the ability to open files for non-exclusive access is
>> ridiculously antiquated and stems from the pre-1970 era when bisync
>> was state-of-the-art and the concept of servers as separate asset
>> owners was little more than a foggy idea in the minds of a few.

RW:
> There are at least three different concepts in this paragraph:
>
> 	1. The kind of access policies which can or cannot be configured
>             via 'traditional UNIX(*) access permissions'
>
> 	2. The 'privilege separation model' use to determine which
> 	   applications can execute which kind of system calls.
>
> 	3. Implicit mandatory file locking (I wonder how that landed in
> 	   here)

It landed here because it is a related problem that is imo not being 
fully handled.  The shared-file model originated back in the pre-1970 
era when few people were even aware of the concept of a "server".  It is 
imo an obsolete model; there should only be one user reading or writing 
any given file, and that should be the "file server"; the file server 
model handles all cases, where shared file access does not.  Implicit 
mandatory locking is a quick-and-dirty implementation of the file-server 
model, and anything less reliable than mandatory locking is too sloppy 
to touch with a pole imo.

RW:
> ad 1) 'common Linux filesystems' support access control lists, too. I've
> so far (in about 20 years) encountered exactly one 'real-world problem'
> which couldn't be solved without them.

ACL's should not be an optional add-on imo; the only way to properly 
test file access is to have one-method-for-all.  And if you're 
consistently using ACL's then the ogw-model becomes obsolete.  In fact 
the whole "group" concept is imo hopelessly obsolete already, its only 
real value is toward file-sharing-sans-proper-locking.

> ad 2) 'Linux system call execution privileges' are actually based on a
> more fine-grained 'capabilities model' and a 'UNIX(*) superuser' is
> emulated by assigning all capabilities to 'UID 0 processes' by
> default.

It doesn't matter how good the underlying mechanisms are if the 
top-level interfaces offer support based on potentially incorrect 
assumptions.

> AFAIK, nobody uses this except "dexstop devsloppers' and even
> in this case, I strongly suspect that they're rather suffering from an
> "OMG! So 1970s!"(BTNHMDI!![*]) knee-jerk reaction than trying to solve real
> problems.
>
> 	[*] "But That's Not How Microsoft Does It"
>
> ad 3) BTNHMDI? Cooperating applications have the necessary facilities
> for coordinating accesses to shared files in case this is
> necessary. Which it isn't always.
>

Perhaps it should always be presumed necessary, that's the way it seems 
to me anyhow, the number of programs I've written since 1969 which 
assumed less than the most rigorous set of requirements and did not 
later need to be updated or (more usually) rewritten to accede to the 
fact that the initial implementation was too naive, amounts of almost nil.

Back to comp.os.linux.development.system | Previous | Next — Previous in thread | Next in thread | Find similar

Thread

shred or scrub "Bill Cunningham" <nospam@nspam.invalid> - 2014-04-16 18:17 -0400
  Re: shred or scrub crankypuss <crankypuss@nomail.invalid> - 2014-04-17 04:19 -0600
    Re: shred or scrub "Bill Cunningham" <nospam@nspam.invalid> - 2014-04-18 22:30 -0400
      Re: shred or scrub Jasen Betts <jasen@xnet.co.nz> - 2014-04-19 07:42 +0000
        Re: shred or scrub Richard Kettlewell <rjk@greenend.org.uk> - 2014-04-19 10:04 +0100
      Re: shred or scrub crankypuss <crankypuss@nomail.invalid> - 2014-04-19 02:15 -0600
      Re: shred or scrub Rainer Weikusat <rweikusat@mobileactivedefense.com> - 2014-04-19 23:05 +0100
        Re: shred or scrub crankypuss <crankypuss@nomail.invalid> - 2014-04-20 02:47 -0600
          Re: shred or scrub John Hasler <jhasler@newsguy.com> - 2014-04-20 07:56 -0500
            Re: shred or scrub crankypuss <crankypuss@nomail.invalid> - 2014-04-21 03:51 -0600
              Re: shred or scrub Jasen Betts <jasen@xnet.co.nz> - 2014-04-21 11:50 +0000
                Re: shred or scrub crankypuss <crankypuss@nomail.invalid> - 2014-04-21 06:14 -0600
            Re: shred or scrub "Bill Cunningham" <nospam@nspam.invalid> - 2014-04-21 18:44 -0400
          Re: shred or scrub Rainer Weikusat <rweikusat@mobileactivedefense.com> - 2014-04-21 13:24 +0100
            Re: shred or scrub crankypuss <crankypuss@nomail.invalid> - 2014-04-22 04:10 -0600
              Re: shred or scrub Rainer Weikusat <rweikusat@mobileactivedefense.com> - 2014-04-22 14:39 +0100
  Re: shred or scrub Kristof Provost <kristof@codepro.be> - 2014-04-17 13:15 +0000
    Re: shred or scrub John Hasler <jhasler@newsguy.com> - 2014-04-17 09:40 -0500
      Re: shred or scrub Kristof Provost <kristof@codepro.be> - 2014-04-18 14:40 +0000
    Re: shred or scrub crankypuss <crankypuss@nomail.invalid> - 2014-04-18 02:12 -0600
      Re: shred or scrub David Brown <david.brown@hesbynett.no> - 2014-04-18 11:49 +0200
        Re: shred or scrub crankypuss <crankypuss@nomail.invalid> - 2014-04-18 09:59 -0600
          Re: shred or scrub David Brown <david.brown@hesbynett.no> - 2014-04-21 16:14 +0200
            Re: shred or scrub crankypuss <crankypuss@nomail.invalid> - 2014-04-22 04:22 -0600
              Re: shred or scrub David Brown <david.brown@hesbynett.no> - 2014-04-23 00:06 +0200
                Re: shred or scrub crankypuss <crankypuss@nomail.invalid> - 2014-04-23 05:50 -0600
                Re: shred or scrub David Brown <david.brown@hesbynett.no> - 2014-04-24 22:46 +0200
                Re: shred or scrub crankypuss <crankypuss@nomail.invalid> - 2014-04-25 03:57 -0600
                Re: shred or scrub Rainer Weikusat <rweikusat@mobileactivedefense.com> - 2014-04-25 19:14 +0100
                Re: shred or scrub crankypuss <crankypuss@nomail.invalid> - 2014-04-26 04:02 -0600
                Re: shred or scrub Rainer Weikusat <rweikusat@mobileactivedefense.com> - 2014-04-27 21:26 +0100
                Re: shred or scrub crankypuss <crankypuss@nomail.invalid> - 2014-04-28 03:27 -0600
                Re: shred or scrub Rainer Weikusat <rweikusat@mobileactivedefense.com> - 2014-04-28 12:17 +0100
                Re: shred or scrub Rainer Weikusat <rweikusat@mobileactivedefense.com> - 2014-04-28 13:01 +0100
                Re: shred or scrub crankypuss <crankypuss@nomail.invalid> - 2014-04-29 02:50 -0600
                UNIX(*)/ Linux history & system design (was: shred or scrub) Rainer Weikusat <rweikusat@mobileactivedefense.com> - 2014-05-05 21:31 +0100
                Re: UNIX(*)/ Linux history & system design crankypuss <crankypuss@nomail.invalid> - 2014-05-05 16:02 -0600
                Re: UNIX(*)/ Linux history & system design David Brown <david.brown@hesbynett.no> - 2014-05-06 01:17 +0200
                Re: UNIX(*)/ Linux history & system design crankypuss <crankypuss@nomail.invalid> - 2014-05-06 01:46 -0600
                Re: UNIX(*)/ Linux history & system design Rainer Weikusat <rweikusat@mobileactivedefense.com> - 2014-05-06 15:09 +0100
                Re: UNIX(*)/ Linux history & system design crankypuss <crankypuss@nomail.invalid> - 2014-05-06 23:47 -0600
                Re: UNIX(*)/ Linux history & system design Rainer Weikusat <rweikusat@mobileactivedefense.com> - 2014-05-07 16:23 +0100
                Re: UNIX(*)/ Linux history & system design crankypuss <crankypuss@nomail.invalid> - 2014-05-07 10:51 -0600
                Re: UNIX(*)/ Linux history & system design Jerry Peters <jerry@example.invalid> - 2014-05-07 20:25 +0000
                Re: UNIX(*)/ Linux history & system design crankypuss <crankypuss@nomail.invalid> - 2014-05-08 03:50 -0600
                Re: UNIX(*)/ Linux history & system design Jerry Peters <jerry@example.invalid> - 2014-05-08 20:24 +0000
                Re: UNIX(*)/ Linux history & system design crankypuss <crankypuss@nomail.invalid> - 2014-05-09 02:23 -0600
                Re: UNIX(*)/ Linux history & system design Rainer Weikusat <rweikusat@mobileactivedefense.com> - 2014-05-09 18:36 +0100
                Re: UNIX(*)/ Linux history & system design Rainer Weikusat <rweikusat@mobileactivedefense.com> - 2014-05-09 21:24 +0100
                Re: UNIX(*)/ Linux history & system design Rainer Weikusat <rweikusat@mobileactivedefense.com> - 2014-05-07 22:01 +0100
                Re: UNIX(*)/ Linux history & system design crankypuss <crankypuss@nomail.invalid> - 2014-05-08 03:37 -0600
                Re: UNIX(*)/ Linux history & system design Rainer Weikusat <rweikusat@mobileactivedefense.com> - 2014-05-08 14:02 +0100
                Re: UNIX(*)/ Linux history & system design crankypuss <crankypuss@nomail.invalid> - 2014-05-09 02:56 -0600
                Re: UNIX(*)/ Linux history & system design David Brown <david.brown@hesbynett.no> - 2014-05-07 00:15 +0200
                Re: UNIX(*)/ Linux history & system design crankypuss <crankypuss@nomail.invalid> - 2014-05-07 00:32 -0600
                Re: UNIX(*)/ Linux history & system design Jorgen Grahn <grahn+nntp@snipabacken.se> - 2014-05-07 08:47 +0000
                Re: UNIX(*)/ Linux history & system design crankypuss <crankypuss@nomail.invalid> - 2014-05-07 10:59 -0600
                Re: UNIX(*)/ Linux history & system design Rainer Weikusat <rweikusat@mobileactivedefense.com> - 2014-05-06 14:35 +0100
                Re: shred or scrub David Brown <david.brown@hesbynett.no> - 2014-04-26 16:30 +0200
                Re: shred or scrub crankypuss <crankypuss@nomail.invalid> - 2014-04-27 05:59 -0600
                Re: shred or scrub Rainer Weikusat <rweikusat@mobileactivedefense.com> - 2014-04-27 20:15 +0100
                Re: shred or scrub crankypuss <crankypuss@nomail.invalid> - 2014-04-28 03:29 -0600
                Re: shred or scrub Rainer Weikusat <rweikusat@mobileactivedefense.com> - 2014-04-28 12:06 +0100
                Re: shred or scrub David Brown <david.brown@hesbynett.no> - 2014-04-27 21:41 +0200
                Re: shred or scrub crankypuss <crankypuss@nomail.invalid> - 2014-04-28 04:03 -0600
                Re: shred or scrub Richard Kettlewell <rjk@greenend.org.uk> - 2014-04-28 16:44 +0100
                Re: shred or scrub David Brown <david.brown@hesbynett.no> - 2014-04-28 23:39 +0200
      Re: shred or scrub John Hasler <jhasler@newsguy.com> - 2014-04-18 07:37 -0500
        Re: shred or scrub crankypuss <crankypuss@nomail.invalid> - 2014-04-18 10:16 -0600
          Re: shred or scrub John Hasler <jhasler@newsguy.com> - 2014-04-18 12:01 -0500
      Re: shred or scrub Kristof Provost <kristof@codepro.be> - 2014-04-18 14:42 +0000
  Re: shred or scrub David Brown <david.brown@hesbynett.no> - 2014-04-17 16:41 +0200

csiph-web