Security thorough obscurity
Reverser's Anonymity Academy
So far so good... now read this beautiful essay by [blue] and then download this file chown.zip... and up you go, you superuser you... :-)
Yet another example of Micro$oft dirty tricks: security thorough obscurity.
The trick: made them think they are secure. Keep repeating this.
None really. Win32 development tools if you want to implement ideas from this essay.
You should know about Windows NT administration, Windows NT security model, ACL, ACE, Win32 programming (sorry... no assembly required :-)
A good book on NT administration is Windows NT 4 Server Unleashed by Jason Garms (you can find it on the Web).
Too long to put here...
Since the first multi-user operating system arise the necessity for controlling the access to resources. This leads to another problem: the system administrator needs a lot of rights to perform his daily duties (for example to do backups), but how we can protect some files from being accessed by sysadm? A company can have a lot of sensitive information: payroll lists, customers lists, etc. How can we protect this kind of files from being accessed by sysadm without anyone noticing?
In UNIX it's just not possible. The root account is omnipotent. When NT appears it claims it solved this problem. Please read the following statements carefully.
An owner cannot change the ownership of a resource they own. The owner can only give another user or group permission to take ownership of a resource. Security of resource is thus maintained by preventing users from creating or editing files and then making them look as if they belonged to someone else.
For example, if a user assign the No access permission to a file, a member of the Administrators group can still take ownership of the file and make changes to it. The user, by checking the ownership of the file, would see that the administrator owned the file, and had disregarded the No Access permission on the file.
Microsoft Education and Certification - Administering Microsoft Windows NT 4.0, page 133
Good, very good.
If an administrator wants to access a file that he or she is not granted access to, the administrator must first take ownership of that file. Once ownership is taken, the administrator will have full access to the file. It is important to note that administrator cannot give ownership back to the original owner. If this were so, the administrator could take ownership of a file, examine it, and then assign it back to the original owner without that owner's knowledge.
NOTE: Because administrators have backup privileges, an administrator could back up a file (or entire volume) and restore it onto another system. The administrator could then take ownership of a file on this new system, examine it, and then restore from backup with original permissions, without the owner's knowledge. Please keep this in mind when thinking about file security.
Knowledge Base Article Q102099 - Administrator Access to Files
The key distinction between C-level and B-level security is in the notion of access control. In a C2 (DAC) system, owners have absolute discretion about whether or not others have access to their objects.
Knowledge Base Article Q93362 - C2 Evaluation and Certification for Windows NT
Looks ok. The owner of a file should deny sysadm any access to file and that's it. The only thing sysadm can do it's to take ownership of the file and then give himself necessary rights, but this cannot go unnoticed: user can see the change of the file owner. Many people believe in those statements, and they give a feeling of security that administrators cannot view users' files if the permissions are set properly. However, it is simply not correct.
There are two possibilities to change the owner of a file using Micro$oft tools.
Services for Macintosh:
Windows NT 4 Server Unleashed, Chapter 10, Jason Garms
- Changing ownership changes the ACL. When you use the MacFile permission option to change the owner of a file, the old owner will be removed from the folder's access control list (ACL)-and likewise from all files within the folder. For example, if JGARMS is the owner and I change the owner to JSMITH, not only will the NTFS owner change to JSMITH, but JGARMS will be completely removed from the NTFS ACL.
- The AFP permissions keep placeholder entries for the primary group and Everyone. If you use the MacFile Permissions option to remove all three AFP permissions from the primary group or the Everyone group, they still retain placeholder access control entries (ACEs) in the NTFS access control list.
For instance, if you remove all the AFP permissions from the owner, the primary group, and Everyone, the resulting NTFS permissions on the folder will list the owner with special access (PO), and will list the primary group and Everyone with special access (), which is essentially no specified access.
- You can set the owner of the folder to a group-it does not have to be an individual user's account. This is in sharp contrast to the normal operations of Windows NT, where the Administrators group is normally the only group that can own files.
I take a look in Services for Macintosh documentation (including Microsoft Official Curriculum materials): there is no mention of first side effect: changing Macintosh owner also changes NTFS owner. Of course you can figure it out but after all that noise about "no possibility to SET owner" they don't give even a fine print warning. As you can see you have to dig, to search books to find what beast did you installed on your server.
POSIX Chown utility from Resource kit.
This is a different beast: it does not run in Win32 subsystem. POSIX subsystem like Services for Macintosh has it's own rules.
How about writing normal Win32 program to change the owner of a file? It's also possible (I'll give you a hint shortly). With administrative privileges (Backup, Restore and Take Ownership) it is always possible to change the owner of a file (without destroying the Access Control List!), even if administrators have explicit No Access to the file.
Win32 Security API
The key function is SetFileSecurity:
The SetFileSecurity function sets the security of a file or directory object.BOOL SetFileSecurity(
If the function succeeds, the return value is TRUE.
If the function fails, the return value is FALSE. To get extended error information, call GetLastError.
RemarksThe SetFileSecurity function is successful only if the following conditions are met:
Things are clear now: we have to construct a valid security descriptor and apply it to file we want to modify.
The details are left to the reader :-).
Few starting points:
Giving this we should question every Micro$oft affirmation. If they say we can't probably we can.