Find the answer to your Linux question:
Results 1 to 8 of 8
Enjoy an ad free experience by logging in. Not a member yet? Register.
  1. #1

    File System Idea.

    I should mention I been away from programming for many years, a decade or so. And have done mostly windows programming, and this might not be a new idea.

    However it seems there is a really simple way to set up a secure file system, that also makes sense, and would be easy to implement.

    This is the idea, if it is not as clearly written as it could be, or if has been done before, then the question would be why do most file systems only use one type of folder, or set restrictions based on users, not what 'programs' might try to do, since all the viruses come from programs.

    After spending some time seeing the file system of the new operating system I been using, I think there is a really simple way to make a better more secure system. Someone probably has already done it, or if they haven’t they probably should. So this is my idea for a file structure to solve the problem people worry about as far as viruses go.

    And because I think the entire ‘document folder idea, should be shortcuts to info, not the actual locations, like how the libraries work.

    Definition of terms,
    User is an action by a person using the computer.
    Fence API is an action by the OS to approve or facilitate reads and writes including from memory or cache to monitor or limit areas of directories reading other areas.

    All other actions are presumed to be initiated by some program.

    File Structure.

    Program Folder

    .Install Folder
    ...Path to Reporter File
    ...Path to Construction File
    ...Path to Estate File
    ...List of Permission to access from outside of this program folder
    ...List of Friends Program Folders.
    ...List of Write access other Lawns approved and said not to ask again.
    ...Special Conditions, If Admin folder,
    (no request for access prompts to non administrators)
    (System folder special restrictions.)

    ...Contains Fence API Interfaces paths and version information.

    ...Only Accessed by Fence API
    ...Contains a Log File of Attempted Violations

    ...Only accessed during Installs
    ...Contains a log file of install changes
    ...Contains a data file for roll backs from installations
    ...Read Write to Estate, Lawn, House Safe Room
    ...Through Fence API
    ....During install can request access to other Estate Folders
    in other program files. Each question must have user prompt
    ....Can create other Program folders that are accessible
    As if they are these same folders (Friends for the document
    Directory backwards capability)

    .Estate Folder
    ..Run Permission
    ...Write to Lawn
    ...Write to House
    ...Read form Lawn House Safe Room Normally.
    ..Through Fence API,
    ...Read from any Lawn folder
    ...With User prompt can write to any Lawn Folder
    ...Or with Friend Program Folder added to list

    ..Estate\Lawn Folder
    ...Run Permission
    ....Estate can read/write
    ...Through fence API
    ....Read from anyone
    ....Write with a prompt to user.

    ..Estate\House Folder
    ...Run Permission
    ....Estate can read/write

    ..Estate\Safe Room
    ...Run Permission
    ....Estate can read

    Program Folder
    The Program folder defines the start of an area. There is one Program Folder for each program. Programs that are heavily dependant or use same installers can use Friends Program Entries. Created by installer as Folder To Install In

    The Install directory is created by first initial install, after that, all updates must occur from files put into this directory, or Update commands from this area. Short cuts can start a Install process but can not change any data in this folder, only the install file in the Program/Install/Construction can write the patching during install mode. User must put the Install, or update connector into this directory if patch is added. A multi Program Folder update would prompt user for each putting of a file into an Install area.

    The Initial Install is always in two phases, build file structure, inside Folder(allowed without Fence API, since in the same folder, and folder creation is not restricted.) Although no overwriting of file or folder creation allowed without prompt during initial install. Then all other writes follow procedures of Fence API, if needing any information from outside of folder. And that includes copying in all the ‘Setup.exe’ into the folders. Prompts and being in Install mode would be requiered.

    Inside the Install Directory are two system files Settings and Reporter. Settings is created by Installs and any need to connect to any other Program Folder must have user permission during set up. There should be no reason to have access to other Program Folders other then two programs that both have write access to the same documents. In the cases of “Documents and setting folders” a folder should be created with permission access, approved by user (user selects path). Documents should be in there own Program Folders that are given Access permission then documents are stored in the Lawn of that directory.

    Two programs accessing the same documents can be the only programs that access those documents that are in the third Program folder. So even if the documents are shared they are only shared with permissions.

    Loading And Caching Outside Files
    For either program to access files outside of the Program folder, the rules of the Fence API are used. Since reads are allowed anywhere in Lawn Directories. Typically all system files will be read in at start up into memory, or copies can be written in as temp caches during each start up if more system files are needed then are put in memory. They are stored in lawn directories of the Program Folders. Such cached files are checked for version on each startup.

    This allows for updates to system files to occur while programs are still running using those files. Then on a program restart it will check its cached data or load the other file into its process memory.

    Cached files can lower need to communicate through Fence API during Initialization, at the cost of Cached copies of system files in the local Program Folder. Note that the DLLs used are loaded into process memory space, and in the same way, cached in Program Folder location, if page file swaps occur within that process. So that next load will not have to go through Fence API if page swapping, and if the ‘Lawn’ of ‘Current Version List Program Folder’ shows the cache is up to date.

    An OS system could clean up Caches of unused files, or even keep a record of who requests copies and when to order that program to reload caches on next start up of that application. Note that also keeps from having to restart an application during installs, since copies are used.

    Some Structure Comments
    A OS Program Folder that has names of locations of system files from things like GUIDs(currently in the registry) would have the file paths that are in other OS Program Files.

    If the OS files are in Lawns, anyone can get a copy of the file. However having different Program Files for things like Registered components, and various types of settings, could better restrict who changes those parts of a program, needing user permission during install. By them being in lawns, to change a system file would require:

    A user approval of putting a patch into any Program folder that was being patched.
    An install starting from within each system Program Folder would then occur. (a typical OS update would be a set of shortcuts to different update files in the different program folders, to then request the updates for those program sections, that way updates occur from within Program Folder.)

    Patch Example
    So to patch an OS, you might have to approve an exe for install going into File Location Program Folder, Network Program Folder, GUI Program Folder, Kernal Program Folder, etc... No one Program area could right to all those areas without permission. A user could set up a Program Folder, then give write writes to many other Program Folders, if a centralized Update was wanted, however that would be less secure.

    Typically a batch of shortcuts would initiate the update files.
    Update files would only run once, and each time a user gives permission, it is permission only for that version and checksum of that file to be ran. Any new update would move old patch to rollback area. To run a patch twice permission would have to be requested again. (Since the shortcut to the file is accessible from anywhere) All of that would be recorded in some Program Folder called Patching stats, only written to by the OS during patching procedures.

    And since only the OS can access the areas that have the permission through user prompts, the checksum number could not be hacked by a virus, without user permission, and even then they would have to give permission for every program it tried to infect.

    And any program that runs, on initialization checks its cached version numbers with the versions in system directories to know if they need to be cleaned. Or the OS, could even flag different programs to ‘reload’ after an update, since it could store who gets copies of its system files through the Fence API.

    Fence API
    The Fence API, all it is is some restrictions on what programs can read and write, based on what part of a file structure they are in. The fence does nothing different in either reading from memory caches or from files as the current OS file API, accept that it does a check to see if certain rules based on where a read or write is coming from or going. And since the OS does all the writes to disks and memory through APIs and Memory Managers in the APIs, it would be secure and not to difficult to implement.

    All that would have to be added would be the sections of System only OS directories that give permission information to the API on a program start up, so it knows how to handle a program. And those permissions could not be accessed by the program (accept during install, and with user prompts, and admin instal permissions)

    It is a pretty simple concept, probably someone else thought of it before. It stops the idea of viruses propagating to other DLLs, because they can’t be written to, unless specifically given permission on initial instal, and are kept in a list in the OS Only accessible part of the Program Folder, so that any time, a check could be done to see if they are trying to write or have permissions to some areas they normally do not access.

    I think that makes sense.

    Programmable clip board actions, would have to be done on both sides, and most of those are user prompted actions, so that would not be a problem.

    The idea is to create some folder types that never can be written to from a program or from the Internet without being in Install mode, or with a user prompt.

    For backwards compatibility, an API installer would handle most of the items, and a few ‘permission boxes’ during first time a program runs and goes to get some folder from some other location, would all that would be needed. And in backwards compatibility all items not set up with how they access or are access other files could be put in the Estate folder.

    And the displays of things like logs and permissions for a folder would not have to actually be folders but could be areas shown from file view window (optionally)

    Would be a pretty easy thing to do, when I get a version of Linux and a compiler I probably will give It a try.

    Note, any extra Hard Disk usage of caching system files instead of using instances of the same files running in memory, that is not that big of a problem, since instances still could be used in any case where the system file is not writing to any other files(read only access). If a system file never does a write, or does not call to do a write, it could be treated with read access as a system lawn.

    Or if it did do writes, it could be loaded into Program Folder, and from there it would be restricted by Fence API like any other part of the program running from there.

    Even if a program used 100 system files that did IO at an average of 100KB each, that is still only 10 megs of hard drive or memory storage in a process for each program.

    And the OS would be optimized to separate out manipulating functions, math or utility functions and functions that could harm other programs or the OS if not constrained.

    Files that could do no damage, would be on lawns and could be interfaced like any other program, although not written over, nor would they ever have to do any writes, so could be called by interfaces.

    And files that do writes, or could do damage, would be copied into Program Folder, and from there would be limited where they could write by the Fence API checks on reads and writes.

    Again if this is obvious, or if I missed some issue that could occur, comments would be interesting.


  2. #2
    if the post is difficult to read, it is a rough draft of the idea.

    Probably not a new idea, but I think from skimming through the read it is possible to see the idea.

    Different types of folders with different access rights, and a single folder containing all of an application, those folders, and the needed settings and instal for an application.

    then an API to enforce restrictions.

    And an OS that expects that structure for program files, and can even set up that structure to keep folders secure.

    Basically each program area has a space for files that never change, that are changed by the program, and for exe's that will reach out to system or other documents or folders.

    Bob Eastwood

    And the segments of an OS or large program separated into folder segments that are more then a list of files, but also the information needed for a set of files, to access other files.

    A large program could have many Program Folders and all the other files, or many different read only locally(data) folders or many read everywhere, write with permission files(Library files).

  3. #3
    Is the no responses due to lack of clarity, bad idea, obvious idea, or something else, to long to read, not a catchy intro?

    The basic idea is to move away from every file having an attribute set, and instead having 'multiple types of folders' that have attributes set, then the file system and users can easily see structure of file access in the way files are in a directory.

    Anyways, I figured it was a good idea, maybe it is to obvious. Or maybe having Windows experience maybe the Linux file system already does such things.

    having folders having sections that define how the file can be worked on, seems to be a good idea to me.

    The idea of one type of folder, and then setting some attribute, seems to not be as intuitive as actually having different types of folder sections in the same patterns throughout a file system.

    It does make sense doesn't it?

  4. $spacer_open
  5. #4

    your file system

    Quote Originally Posted by RobertEastwood View Post
    Is the no responses due to lack of clarity, bad idea, obvious idea, or something else, to long to read, not a catchy intro?
    Your idea is beyond my comprehension so I can not reply to the content of your idea.
    However, if you want a real technical discussion at an academic level, go to Usenet, find one or more appropriate usenet newsgroups from the comprehensive list with all available newsgroups, and post your idea there.
    Chances are they will both ignite a response and a thorough discussion.
    These 'web forums' may seem nice, but they are both scattered in the sense that many forums cover the same topics, as well as that there is no comprehensive list of them, so almost nobody knows they are there, other than through coincidence (or a lucky hit in google/bing/whatever).

    Good luck and if you decide to post your ideas in a newsgroup on usenet, let us (me) know which one.

  6. #5
    Linux Guru
    Join Date
    Oct 2007
    Tucson AZ
    since all the viruses come from programs.
    How do you define 'programs'? There are simple one line commands that will destroy the entire OS. No complicated program necessary although I'm
    not sure what you mean by it. Many viruses are run on computers accidentally by users who are either careless or download 'programs' from sites they know nothing about.

    After spending some time seeing the file system of the new operating system I been using
    What filesystem/operating system is that?
    Not sure why you refer to 'Documents' folder. The directories on a Linux filesystem, for example require root/administrator permissions for pretty much everything outside the users /home directory. Most programs are not stored in that directory.

    And that includes copying in all the ‘Setup.exe’ into the folders.
    A Setup.exe file will be dead weight on a Linux system as they won't run. Are you just using that as an example of an executable file?

    Part of the difficulty in reading your post comes from your use of construction/landscaping terms, at least for me. Different programs in Linux use the same libraries and it would be duplicative and cumbersome to have the same library in each directory you have a program. That's the way I'm reading it but maybe that's not what you mean??

    I don't know any programming so that may be why I'm not reading your post correctly, if I'm not?
    Last edited by yancek; 07-16-2013 at 08:59 PM.

  7. #6
    Linux User IsaacKuo's Avatar
    Join Date
    Feb 2005
    Baton Rouge, LA, USA
    Once upon a time, I had some similar ideas, but this really isn't a "file system" idea. It's really an idea for how to organize an operating system.

    I was thinking of breaking up things by disk, rather than folder, so you could write protect your OS and application floppies while leaving your data floppies write protected optionally. The OS would only run executables from authorized discs, and only when write protected.

    I sort of revived these ideas back when CD's were competitive in speed and bigger in space than hard would be nice to run operating systems directly off of CD. For various reasons, the Amiga operating system was already organized in a way which lent itself to this.

    But with modern hardware and modern operating systems, there just aren't compelling reasons to organize things this way. Not when you'd basically have to design a new OS from scratch around it, and hardware simply isn't set up for read-only media anymore.
    Isaac Kuo, ICQ 29055726 or Yahoo mechdan

  8. #7
    Linux Newbie
    Join Date
    Jun 2004
    Halesowen, West Midlands, UK
    Some years ago there was a Linux distro that made each program an entity, libraries were compiled in, etc.
    It never caught on because of bloat and performance issues rather than security issues.

    There are so many ways of hardening Linux and security in general is not a bolt-on feature for kernels and their filesystems in Unix and Linux but is designed in.

    Overview of Linux Kernel Security Features |

    Paranoid Penguin - Linux Filesystem Security, Part II | Linux Journal

    The mention of viruses takes me back to the first announcement of a Linux virus which when I looked at it, it required 3 things to be effective and only one (su) was running on my systems and I dare say hardly anyone was running the 3 and if there were 3 running there was a particular configuration needed for it to have been valuable to an attacker.

    There have been many articles putting forward the notion that it was only a numbers thing and that if Linux numbers approached a certain threshold, it would gain the attention of virus writers.

    My retort to that was that if the virus writers really wanted to cause havoc there is no bigger target than the internet backbone that is predominantly Linux.

    Some years ago when IIS was under DOS attack, Microsoft sought refuge by temporarily switching IIS behind a Linux ISP until they were able to patch the vulnerability.

  9. #8
    Thanks for the replies, I think some of the advantages and ideas may need some more work and to be drawn out a bit. Maybe after awhile I will post again with some more details, and explain it a bit better, was basically first draft.

    And thanks to the links to the Linux information. And the comments that others have thought about this, and places to look further on the subject.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts