Record-oriented I/O for safety purposes

[farcas82]

Has anythone tried to design an OS that offers some level of consistency guarantees in the kernel? Maybe use a light kernel interpreter to verify user-defined constraints in a SQL-like fashion? I'm thinking about files=tables and defining constraints on those tables. Any thoughts on this?

[iansjack]

It's not clear what constraints you are referring to here. Perhaps you could amplify somewhat on the nature of the problem?

[farcas82]

Integrity constraints. Like column constraints in SQL. For example a such constraint could force the password hash in /etc/passwd table to be of a certain length and contain only hexdigits.

EDIT:

CREATE TABLE Persons (
ID int NOT NULL,
LastName varchar(255) NOT NULL,
FirstName varchar(255),
Age int CHECK (Age>=18)
);

Like Age int CHECK above.

[iansjack]

I see.

My view that this would be to conflate the purpose of the file system (to organize storage) with - in this case - the purpose of the security system (to determine password policy). I think it better to keep distinct systems separate. This way it's easier to change one without affecting the other. A bit like the difference between HiFi separates and a music centre.

[farcas82]

The table storage layout would be in this case the "filesystem" format. Constraints would be stored as resource forks or metadata. Constraints would have to be toggled ON one at a time and it should be possible to turn them OFF. A status report for the current active checks should be available. This way the password policy would be configurable. Highly similar to SQL. Maybe I should write an OS in SQL At least the userland tools.

[iansjack]

I would argue that the job of a filesystem is to manage collections of data (files) without concern of what information is stored in those files. This is the antithesis of SQL, whose job is to manipulate data without caring about how that data is stored.

[Schol-R-LEA]

Has anythone tried to design an OS that offers some level of consistency guarantees in the kernel? Maybe use a light kernel interpreter to verify user-defined constraints in a SQL-like fashion? I'm thinking about files=tables and defining constraints on those tables. Any thoughts on this?

Record-structured file systems were actually the norm prior to Unix, especially on IBM mainframes. The problem they have is that they tend not to be as flexible as a stream-oriented file system; you need to define a record type at the OS level for every different file type, and most of the record-structured FSes used in the past didn't make that easy; few if any supported flexible record types to any real degree.

A more modern form is the Object-Oriented file system, of which there have been a few examples, but they tend to have the same problems.

Note that their are special-purpose record-structured file systems for some advanced RDBM systems, which deliberately bypass the general-purpose stream-oriented FS which are the default in most modern systems; Oracle offers one for their mainframe versions, IIUC. These tend to be more for highly-tuned performance in SELECT and UPDATE operations, and are not intended as general-purpose file systems.

[farcas82]

The problem they have is that they tend not to be as flexible as a stream-oriented file system; you need to define a record type at the OS level for every different file type, and most of the record-structured FSes used in the past didn't make that easy; few if any supported flexible record types to any real degree.

My idea is to introduce some sort of type-checking in the storage layer. In order to make it harder to mess up the system by mistake. Even if it's less flexible (obviously this is the case here) or harder to use (again obviously true). Sort of like static-typing vs dynamically typed scripting languages. AFAIK statically typed languages are more difficult to use but at the same time less bug prone than dynamic ones. OpenVMS also has a record-oriented FS layer but it;s optional as far as I know.

[farcas82]

Now that I'm thinking more about it there exists another possible architecture. A Makefile-like incremental build system that performs integrity checks when file content is changed. This would require a fast way to detect file changes also possibly the capability to quickly locate changes in a file structure. Manually scanning for changes is rather slow. A record-oriented filesystem could bring a "dirty" flag array for each file. One dirty bit per record.

[linguofreak]

I see.

My view that this would be to conflate the purpose of the file system (to organize storage) with - in this case - the purpose of the security system (to determine password policy). I think it better to keep distinct systems separate. This way it's easier to change one without affecting the other. A bit like the difference between HiFi separates and a music centre.

I think what the OP is after is having the filesystem structured such that /etc/passwd cannot be written to without the security system validating it for usability, to prevent such silliness as

Code: Select all

# head -c 3000 /dev/urandom > /etc/passwd

A better way, IMHO, would be to allow any given file to have an attribute "editwith" for each file, which, if set, allows editing only with a certain binary. Of course, this is not proof against the sufficiently clueless admin, as the editwith attribute for /etc/passwd could always be changed by root, but even with a record structured filesystem, root could always delete /etc/passwd and create a new file with the same name and a record structure that the security system would choke on.

[eekee]

I've been thinking my system may have multiple storage systemsfor various reasons, but security isn't really one of them. For security, I'm thinking of servers; if a program wants secure data, it has to talk to the server program for that data. This is possible in POSIX, LDAP is one way I know of, see also PAM for general flexibility. I think /etc/passwd can be eliminated, but I'm not sure. (I'm not doing POSIX, no PAM for me. I may use LDAP or my own scheme.) The server program can go on another machine for extra isolation. You'll want secure auth for that, of course. I'm told Kerberos has the right design of token exchange for that, a sysadmin friend says every new auth system either copies Kerberos 5 or has security problems until it's changed to do so. If you're worried about performance, what on Earth are you doing? I suppose it might matter if you want to lock down the format of every file on a busy system, but as others have said, that leads to severe flexibility problems.

Now that I'm thinking more about it there exists another possible architecture. A Makefile-like incremental build system that performs integrity checks when file content is changed. This would require a fast way to detect file changes also possibly the capability to quickly locate changes in a file structure. Manually scanning for changes is rather slow. A record-oriented filesystem could bring a "dirty" flag array for each file. One dirty bit per record.

Perhaps the newly-written data doesn't become visible until it's been scanned. If the data goes via a server program, then it can be verified before it's even written, and only the changed records need be verified. The server may also encrypt the data so no other process can get at it, and I like "editwith" too.

[farcas82]

I see.

My view that this would be to conflate the purpose of the file system (to organize storage) with - in this case - the purpose of the security system (to determine password policy). I think it better to keep distinct systems separate. This way it's easier to change one without affecting the other. A bit like the difference between HiFi separates and a music centre.

I think what the OP is after is having the filesystem structured such that /etc/passwd cannot be written to without the security system validating it for usability, to prevent such silliness as

Code: Select all

# head -c 3000 /dev/urandom > /etc/passwd

A better way, IMHO, would be to allow any given file to have an attribute "editwith" for each file, which, if set, allows editing only with a certain binary. Of course, this is not proof against the sufficiently clueless admin, as the editwith attribute for /etc/passwd could always be changed by root, but even with a record structured filesystem, root could always delete /etc/passwd and create a new file with the same name and a record structure that the security system would choke on.

Indeed I want to prevent accidental breaking of things. But I don't care much about intentional breaking of things. The user (eventually root) should be able to change any file to any value she wishes. Just add a little bit of checking in order to prevent stupid mistakes like rm . / -rf

[Solar]

Enforcing such settings to be changed through specific interfaces only? Akin to e.g. visudo for editing sudo config files. Having those interfaces (API / command line) do the sanity checking, and disallowing "raw" access to the configuration for non-root users?

Just an idea.

[farcas82]

Enforcing such settings to be changed through specific interfaces only? Akin to e.g. visudo for editing sudo config files. Having those interfaces (API / command line) do the sanity checking, and disallowing "raw" access to the configuration for non-root users?

Just an idea.

It would be really difficult to handle so many interfaces. Because as new versions of the toolbox are deployed, new runtime checks would be added in place. This would make interface documentation hellish.