Groups | Search | Server Info | Keyboard shortcuts | Login | Register
Groups > comp.os.linux.development.system > #658
| From | Rainer Weikusat <rweikusat@mobileactivedefense.com> |
|---|---|
| Newsgroups | comp.os.linux.development.system |
| Subject | Re: shred or scrub |
| Date | 2014-04-27 21:26 +0100 |
| Message-ID | <87wqear01o.fsf@sable.mobileactivedefense.com> (permalink) |
| References | (8 earlier) <lj89en$q2a$1@dont-email.me> <ljbt7r$5bc$1@dont-email.me> <ljdbhe$ol8$1@dont-email.me> <87k3adxomn.fsf@sable.mobileactivedefense.com> <ljg06q$f5s$1@dont-email.me> |
crankypuss <crankypuss@nomail.invalid> writes:
> On 04/25/2014 12:14 PM, Rainer Weikusat wrote:
>> crankypuss <crankypuss@nomail.invalid> writes:
[...]
> 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.
[...]
This is an entirely different topic. So-called 'UNIX(*) file system
permissions' enable defining access control policies for 'filesystem
objects'. The 'security' offered by the kernel is that these access
rights are enforced. 'Superuser' is a technical term and refers to a
system account whose access to the system is not limited like that
of an 'ordinary' user account. Hence, it has 'relative superpowers'
which implies exactly nothing a about the (real) people who might be
able to use these 'superpowers'.
>>> 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.
Ehh ... you do understand that programs, shared libraries and stuff like
'documentation' are ultimatively all files accessible via the filesystem
namespace? Concurrent read accesses don't conflict with each other and
concurrent write access to files may or may not: It is up to a set of
cooperating applications to implement whatever 'access coordination
policy' might be necessary for a given case. Eg, one example I'm dealing
with is a IKE-server ('Internet Key Exhange' [protocol], used for
creating dynamic IPsec-based VPNs) which writes a record (in append
mode) to a certain file whenever a user has 'logged in' and an IP was
assigned to it and a second program responsible for doing all kinds of
'user-specific, automatic reconfigurations', eg, in order to support a
notion of 'firewall/ packet filter rules' supposed to affect users or
groups of users' reads these records as they are appended in order to
update its idea of which IPs currently represent which users.
> 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.
... and if I'm "consistently" walking, all other means of land
transportation 'become obsolete' because I can walk to any place
someone could reach by car or train but the reverse is not
true. Nevertheless, I prefer using the train when I want to visit
someone living 30 miles distant because while this is an inflexible and
very limited way of reaching 'a destination', it's a lot faster where
applicable.
NB: This is example is IMHO less stupid than it may sound.
> In fact the whole "group" concept is imo hopelessly obsolete already,
> its only real value is toward file-sharing-sans-proper-locking.
As already mentioned above, locking isn't needed for concurrent read
accesses. Also, group access rights have other uses. A common one would
be 'allowing all members of a group read or read/write access to some
filesystem objects or filesystem objects but deny them the ability to
change the permissions'. This will usually mean a file owned by root in
a directory owned by root whose 'group access permissions' permit the
intended access, eg, a file storing a database access password needed by
some processes.
Back to comp.os.linux.development.system | Previous | Next — Previous in thread | Next in thread | Find similar
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