Security policy for FAT partition driver?

[Jaix]

I was thinking about the security policy and NTFS partitions, I really like this function, but this is only availible on NTFS, but why not make the FAT driver head the policies and make it work as NTFS?

Of course it's really easy to boot from a DOS disk and be able to read/write any file, but being able to set access policys on a home-computer/network is a real help for an administrator. It doesn't stop a hacker, but children and wifes (some of them anyway).

Microsoft isn't interested in such a driver because they want everyone to run NTFS, but we don't have such preference, we are interested in the best function not our habitat.

[Gasmann]

I was thinking about the security policy and NTFS partitions, I really like this function, but this is only availible on NTFS, but why not make the FAT driver head the policies and make it work as NTFS?

You mean ReactOS should save the access rights for users in somekind of database? Sounds interesting, and it shouldn't be too hard to implement something like this, since (if I understand correctly) it just has to look for the access rights in an external database instead of the filesystem itself.

Of course it's really easy to boot from a DOS disk and be able to read/write any file, but being able to set access policys on a home-computer/network is a real help for an administrator. It doesn't stop a hacker, but children and wifes (some of them anyway).

You can set a bios password, this should prevent the possibility to boot from anything other than hdd (well, freeldr than has to support password protection for it's config and custom boot feature, too).

Microsoft isn't interested in such a driver because they want everyone to run NTFS, but we don't have such preference, we are interested in the best function not our habitat.

That's probably correct, but NTFS access rights can be bypassed too, e.g. with Linux NTFS driver or NTFSDOS.

[oiaohm]

Dos programs Cause this major problems at first and this never got updated for long filenames filesystem due to problems.

umsdos.txt
http://www.ibiblio.org/pub/Linux/kernel ... umsdos.txt

Using another filesystem is a better idea. Otherwise syncing will be always required due to dos programs playing with the filesystem and the larger the filesystem the longer the sync.

Basicly any filesystem that supports extended attribs under linux could be used. Since we have a Ext2 driver upgrade to support extended attribs or upgrade Ext3 and activate the Extended Attribs. Would be a far better fix. A modern Linux accessing a file may not create the reactos required Attribs but It can be made do it. The linux system deleting a file will remove the Extended Attribs that reactos linked to the file. So sync can be skiped and any errors fixed at runtime.

To top things off Fat is a slow filesystem and fragements and gets slower. Accessing a database or file to get attribs slows down file access even more. Yep linux guys gave up on this. A loop back file inside fat was far faster and better than extending Fat file system to get protection.

Everything sound good on paper it when you do it you find out where the problems are.

It always pays to go and have a look at what other OS's have done and the problems they struck. Yep can save a lot of time due to almost no idea is new.

[Jaix]

You mean ReactOS should save the access rights for users in somekind of database? Sounds interesting, and it shouldn't be too hard to implement something like this, since (if I understand correctly) it just has to look for the access rights in an external database instead of the filesystem itself.

Yes a new registryfile like FATpolicy.dat for example.

You can set a bios password, this should prevent the possibility to boot from anything other than hdd (well, freeldr than has to support password protection for it's config and custom boot feature, too).

Yes that makes it a bit more sequre, but it's easy to reset the CMOS on the motherboard.

That's probably correct, but NTFS access rights can be bypassed too, e.g. with Linux NTFS driver or NTFSDOS.

Perhaps we can get FreeDOS to also support this way of doing things and make a standard? Maybe too far away?

Dos programs Cause this major problems at first and this never got updated for long filenames filesystem due to problems.

umsdos.txt
http://www.ibiblio.org/pub/Linux/kernel ... umsdos.txt

Using another filesystem is a better idea. Otherwise syncing will be always required due to dos programs playing with the filesystem and the larger the filesystem the longer the sync...

Well, how does Win9x handle long filenames and how does Long filenams for DOS do it, perhaps its just to extend those ideas?
And another thing I don't mind we restrict the security policy to directory level, this makes a lot less informaton to handle while there doesn't cripple function to much. Or this database only handle files on explict order (not every file just those orderd to change).

[user222]

Yes that makes it a bit more sequre, but it's easy to reset the CMOS on the motherboard.

Someone would have to take the computer apart to do that.

[oiaohm]

Well, how does Win9x handle long filenames and how does Long filenams for DOS do it, perhaps its just to extend those ideas?

The problems is old version of Dos programs they directly interface with the filesystem in most cases. Win9x used a fake network drive setup to protect the filesystem some dos programs built after Win9x still access fat32 directly leading back to the same problems.

Windows 95/98 and Windows NT/2000 store long filenames on FAT in special directory entries with set attributes ReadOnly, Hidden, System and Volume, so if you access FAT volume from DOS you don't see these "files". These special entries have this mad structure:

byte sequence number for slot
string(10) first 5 characters in name
byte attribute byte
byte always 0
byte checksum for 8.3 alias
string(12) 6 more characters in name
word starting cluster number, 0 in long slots
string(4) last 2 characters in name

Problem occur when you delete or modify file with long name from system without VFAT support, because only DOS 8+3 entry will be deleted or modified. Scandisk from Windows 95/98 can repair this problem.

From http://www.linux.org/docs/ldp/howto/Fil ... WTO-3.html

Problem is that these entrys also expand the filesystem. Also changing the filesystem will fight with windows own scandisk. Yep that scandisk that windows runs from time to time over a vfat systems is to cleanup old directory entrys.

This form of change is not going to work. We will endup fighting head to head with windows own scandisk because it will call our entry a invaid entry and remove it form the directory.

Basicly thank Microsoft for not building in a expand system.

We are locked out. What ever we do on the vfat system we are going to have sync problems. If you delete a directory from another os you will still have a lost entry that will have to be fixed by a sync. Vfat is having sync problems to start with.

Basicly it one giant mess that I cannot see a smart way of fixing. Other than droping fat from a main filesystem and placing something else in.

Ntfs is not much better.

Lack of access to specs and control over specs and locked specs by tools like scandisk. Causes major problems for anyone who wants to addon.

I don't say not try just be awake that the fix is not simple just looks simple. Main thing that makes it complex is that fat had no builtin methord to deal with these problems. Most core Unix/Linux filesystems must have built in support for expandion so OS upgraded work without reformating.

[Crappish]

Yes that makes it a bit more sequre, but it's easy to reset the CMOS on the motherboard.

Someone would have to take the computer apart to do that.

Huh? Just pop open the side, switch the jumper on and off and youre go. Takes about 1 minute...

Or better yet, some motherboards reset themselves after a number of unsuccessfull boots.. just fiddle with the reset couple of times..

[counting_pine]

Huh? Just pop open the side, switch the jumper on and off and youre go. Takes about 1 minute...

Or better yet, some motherboards reset themselves after a number of unsuccessfull boots.. just fiddle with the reset couple of times..

I'd say you've managed to keep out the average computer illiterate spouse/child just by denying them permission in the GUI. And if you're worried about hackers, you probably shouldn't be using FAT in the first place.

[oiaohm]

I really do mean motherboard dependant.

Some boards don't have jumpers to switch.(most do some don't). Then its pull battery. Now it don't have jumper or battery you may have a major problem.

You have to get past the case lock to pull battery or do jumper without using software and risking stuffing everything.

Ok why does this computer have a custom bois chip and no CMOS battery and seam to work perfectly? Tech ans no problem machine pulls time from central server no problem. I set the default settings in the bois and wrote them to the flash chip ie no login option and all setting set.

At this point I almost stranged the tech because I was ment to be fixing the machine and fitting a new harddrive. When he said the this is not a problem all machines bois chips are sitting in that filling cabnet all we have to do is put a battery in and put the chip back and he will recreate a new locked bois latter.

Never under estmate a tech when he has had computers stollen 3 times. The 4 time the thiefs were not happy.

Yep reset the CMOS might not be a option.

[Gasmann]

Yes, it is motherboard dependant. But still you can figure out the bios password with some specific password crackers (there are a lot if them in the net ). I'm sure you'll find one that makes it possible to find out the password, even on windows/reactos.

But it is safe enough against normal users.

[Bond007s]

You can hold the Insert (I believe) key down before the computer is powered on and keep holding it after boot up till after it comes up. The CMOS will be reset. I have used it, it works more effectively than Jumpers. On a side note almost all (if not all -- I haven't seen one yet) motherboards have a CMOS Reset Jumper, the proble is they are not always in obvious places...

[oiaohm]

The insert key works on cmos without password set. Most Bois with password set will come up with a keyboard error if you try it.

I have 2 different boards without the CMOS Reset Jumper and the Motherboards Books the Instructions for them is pull the battery.

Editing the award bois and setting the defaults with the required setting and disable the edit bois screen entry and removing the CMOS battery is about as locked as you can get.

90% of all systems don't need to locked this far.

Lets get back to the problems of FAT. We have side tracked. I am annoyed with myself because I normal don't side track this bad.

[Jaix]

I wonder, is it possible to extend the win9x FAT handling so it will still work with win9x and get a security extendet FAT. Is there handling of FAT documented?

[MadRat]

If there was going to be a "poor man's lockdown" approach to give at least a parental controls atmosphere, then the same approach should be used to work across all formats, not just FAT. Apple's OS X.5 will probably do something with an extended ACL to offer Netware-ish extensions to security.

[oiaohm]

Apples fileformat is extendable so just add it in to the filesystem no problems.

Fat on the other hand is not. Microsoft methrod was to create special entrys then use a cleanup program that will remove invaild entrys from the filesystem. Basicly Nothing can be placed in the filesystem that is not allready there because scandisk will remove it.

Umsdos is the only methord to extend the filesystem. And it requires syncing. Ie a file or files somewhere storing the extra information so that scan disk does not delete it.

Some of my old dos programs used to have hidden files by the volume flag more update scandisk deletes theses. Because they would not appear in a dir.

Netware used its own filesystem to do acls and stuff called NWFS what is a changed version of FAT and is not Dos or Windows Compad. NSS is now the one used by Novell and still not Dos or Windows compad out box.

I don't have complete specs to either filesystem so most likely unable to beused at this point.

Apple uses hidden tracks to store the infomation on floppy. You find this out in OS 9 when you place a 1.68M floppy in the drive(a windows 95a installation disk) And the OS locks up and dies. This still has to be synced.

Verry messy anyone to come up with a fix.

Basicly Extending the Filesystem is out.

Only Options is a on top driver that causes overheads or don't use FAT use something else.