Handling guest accounts properly is always a little tricky.
You want them to be useful, but you want to limit the negative effects they may have on authenticated accounts and data. So, you limit the resources they may use and protect data they can access.
The processor itself is pretty easy to protect. Operating systems already have mechanisms to fairly distribute the CPU power to different processes and with any luck will also carry account information that can be used to enforce fairness across accounts. And modern file systems have ways to protect data from being accessed or modified by different accounts.
But it's possible for a guest account to misuse the computer by using lots of disk space and not freeing it before signing off. You could limit the amount of space used during a session, but if you allow disk space to be retained between sessions, several guests, working in concert, could fill up the disk. On DTSS, this was solved by severely limiting the amount of disk space a user could use for permanent storage, and having a separate larger limit for temporary files used in a process. This later trick allowed compilers to create large intermediate files. Also, by policy, guest accounts were handed out in person, so there were not a lot of them in use.
In the 32 bit version of Windows (Windows NT, Windows 2000, Windows XP etc), there is also the concept of a guest account. When a guest signs in, an empty user directory is made for that guest and when the guest signs off, the directory is deleted. This leads to an interesting security bug.
The process that deleted the guest directory runs with elevated privileges. The code would recurse through the directory, deleting files and directories. Unfortunately, it did not impersonate the guest account before doing this. If the guest left a linked file that pointed to a file it didn't have rights to delete, this deletion process would happily delete it since it had plenty of permissions. In fact, most OS files could be deleted. No good can come from this. And before you ask, yes, this bug is fixed.
Of course, this is still a problem if an administrator does the equivalent thing to a file without thinking.
2 comments:
Unix-ish systems have had "symlink attacks" for years (http://www.egr.msu.edu/mailman-archives/linux-user/2000-March/000051.html). This problem is one that isn't going away--or at least, it's one that I've not seen any system-level fixes to (you can easily enough configure per user tmp directories, but this isn't the norm).
What's the Windows equivalent that you're referring to? NTFS symlinks were only implemented in Vista and above, I believe, and you must be admin by default to use mklink. And .lnk files aren't automatically traversed by the kernel32 file APIs, right? As a result, I thought Windows was normally immune to such issues.
Windows (NT, W2K etc) has had unix links since NT 3.1 for the support of POSIX. I believe it was an NT API only, but available via a command line program in POSIX. In any case, definitely there and used internally if rarely.
LNK files are a shell invention. There are probably some shell32.dll APIs that could be used to tear them apart. Definitely not a kernel mode thing.
Post a Comment