Path: csiph.com!usenet.pasdenom.info!aioe.org!news.swapon.de!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail From: Rainer Weikusat Newsgroups: comp.os.linux.development.system Subject: Re: shred or scrub Date: Sun, 27 Apr 2014 21:26:43 +0100 Lines: 107 Message-ID: <87wqear01o.fsf@sable.mobileactivedefense.com> References: <87k3adxomn.fsf@sable.mobileactivedefense.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: individual.net MtrU6VwCllD7D1T9EygtvABbJR2qJpC1RwWtPN78d+3E8+rdc= Cancel-Lock: sha1:kp25DJRlfi8Vk8K8uVX0zN+Zsoc= sha1:JjLnFbqQSH3wsd6S65Rq11MR79E= User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (gnu/linux) Xref: csiph.com comp.os.linux.development.system:658 crankypuss writes: > On 04/25/2014 12:14 PM, Rainer Weikusat wrote: >> crankypuss 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.