From what I've read UIDs in Unix are assigned by the administrator while the SIDs are random in Windows. Is there a security reason behind this, or is it just different ways to solve IDs?
Thanks
While you may edit /etc/passwd (and /etc/shadow) by hand on a Unix machine, the standard way to add users is through a useradd utility (or similar) which should automatically assign the next available UID. So they should be assigned automatically rather than by the administrator. SIDs are more complicated (i.e. hierarchical) so assigning them by hand would be even more cumbersome (and besides, you cannot update the SAM database by hand anyway).
As to assigning them randomly, the SID's random part is the Machine SID, which gives SID the advantage of being unambiguous (as opposed to Unix UIDs). For example, if MACHINE1 has local user ALICE and an NTFS volume with some files owned by MACHINE1\ALICE, when you plug this volume into MACHINE2, it won't make a mistake of thinking those files are owned by some local MACHINE2 user which just happens to have the same SID (whether named ALICE or otherwise).
On Unix, if alice had UID 501 on MACHINE1, then then you plug the same volume into MACHINE2 where UID 501 belongs to bob, ls will show the files as belonging to bob (rather than to alice or even to an 'unknown UID').
UUIDs and SIDs are essentially the same thing.
They're a combination of a system specific part and a timestamp, generated according to a specific algorithm (which might be different between implementations, but that's irrelevant).
Essentially they're both semi-random. Maybe some Unix admins are convinced there's some "security" reason for not handing them out or whatever, but that's nonsense.
The windows SID is a GLOBALLY Unique Identifier vs the Unix UID which is not globally unique.
Related
I realised I've missed a subtlety with user IDs (UID) and effective user IDs (EUID) and need some clarification. N.B. I'm working on macOS, although I suspect everything makes sense in a Linux world as well.
I've created a binary and set the setuid bit on it (with chmod +s). If I run this binary and log the values from getuid() and geteuid() then I see UID=501 (my regular user) and EUID=0 (root). I can futher call setuid(0) to set UID=0.
My question is, when would I need to do that? i.e. What can my process do with (UID, EUID)=(0,0) that it can't do with (UID, EUID)=(501,0)?
Normally when you run a binary, it runs as you. ie: your UID.
When you setuid, the binary no longer runs as you, but as the owner of the file.
In this case that user is root.
root (uid=0) can do just about anything, including changing their own UID.
There shouldn't be any difference between (0,0) (501,0) except.....
One is YOU running something as root and the other is root running something as root.
Essentially, it makes you root.
Can someone explain to me what the drwx... lines mean? As I understood starting with d is directory and with - (dash) is a normal file. Can someone confirm and help me understand what files I should create? I am so sorry if this wastes your time but I really got stuck.
These show you the file permissions, as can bee seen in nearly any unix system represented this way. The first character tells you if it is a directory (marked as ‚d‘), then you continue in groups of three for read (‚r‘), write (‚w’) and execute (‚x’) permissions for the owning user, group and everyone else.
In your example, the second entry is no directory (first position is ´-´), the owning user, which is ‚login‘, has read write and execute permissions. The owning group is ‚wheel‘ and can only execute, however everyone can read.
As this is basic stuff, you can find plenty of information about file permissions on unix/linux/whatever on the net.
IMHO the Arch-Wiki has a good overview for beginners:
Arch Wiki - File permissions
Looks like permission groups and types for files in Linux or Unix or OSX, more:
https://www.linux.com/learn/understanding-linux-file-permissions
I'm trying to use Windows SIM to generate a somewhat random computer name for a bunch of new computers we will be deploying Windows 10 using WDS. I know how to use SIM to auto-add the computers to the domain and plan to do so. I do not plan on using MDT since it is not a good choice for my organization.
I want something like LT-DepartmentName-## where the ##s are sequential numbers for each computer imaged. I also don't want them having the same name as another computer in AD. How can I do this? Is it easier just to rename the computer after they are joined to the domain?
Yes, you can have Windows generate a unique computer name, but it might not work the way you had hoped.
The computer name is limited to 15 characters, i.e. department name likely won't fit
The uniqueness is a random string, not sequential number
the generated name is either completely random or based (in part) on the full name and organization name specified in the Microsoft-Windows-Setup -> UserData section of the answer file
For more info see the documentation at https://learn.microsoft.com/en-us/windows-hardware/customize/desktop/unattend/microsoft-windows-shell-setup-computername
I am attempting to use LDIFDE to export users, groups, and OUs for importing into a different domain. I'm at the stage where I'm importing users, and I've noticed a problem.
I utilized this command to export users from my domain controller:
ldifde -f Exportuser.ldf -p subtree -r "(&(objectCategory=person)(objectClass=User)(givenname=*))" -l "cn,givenName,objectclass,samAccountName"
This is the bare minimum required, because if you run the command without the -l filters, you end up with data that wont import, and stops the import.
Anyways, I get users out perfectly fine with the script (that is, it runs), and they even import with the -i -f Exportuser.ldf command no problem. However, while importing the group membership associations I got some errors that gave me cause to look closer at what I'd created. To wit: The command above skipped quite a few users in the process of export. These range from system accounts to actual active users, though the "hardest" hit was an OU where we keep deactivated accounts. Not a single strange flag goes up, either.
I can't seem to find anything special about these various users that they'd have in common, but I'm still looking. In the mean time, I thought I'd check to see if anyone here had any history of LDIFDE simply just blowing past users.
Thanks,
M.
Solution:
The filter (givenname=) does not handle null values. The givenname attribute refers to the First and Last Name fields for the User account (not the display name). Therefore, if those fields have no value, (givenname=) will filter those users out.
M.
I want to write a program that allows or blocks processes while openning a file depending on a policy.
I could make a control by checking the name of the program. However, it would not be enough because user can change the name to pass the policy. i.e. let's say that policy doesn't allow a.exe to access txt files whereas b.exe is allowed. If user change a.exe with b.exe, i cannot block it.
On the other hand, verifying portable executable signature is not enough for me, because i don't care whether the executable signed or not. I just want to identify the executable that is wanted to execute even its name is changed.
For this type of case, what would you propose? Any solutions are welcome.
Thanks in advance
There are many ways to identify an executable file. Here is a simple list:
Name:
The most simple and straightforward approach is to identify a file by its name. But it is one of the easiest things to change, and you already ruled that out.
Date:
Files have an access, creation, and modification date, and they are managed by the operating system. They are not foolproof, or maybe not even accurate.
Also, they are very simple to change.
Version Information:
Since we are talking about executable files, then most executable files have version information attached to it. For example, original file name, file version, product version, company, description, etc. You can check these fields if you are sure the user cannot modify them by editing your executable. It doesn't require you to keep a database of allowed files. However, it does require you to have something to compare to, like company name, or a product name. Also, If someone made an executable with the same value
they can run instead of the allowed one and bypass your protection.
Location:
If the file is located in a specific place and is protected by file system access rights, and it cannot be changed, then you can use that. You can, for example, put the allowed files in a folder where the user (without admin rights) can only read/execute them, but not rename/move. Then identify the file with its location. If it is run from this location, then allow it, else block it. It is good as it doesn't need a database of
allowed/blocked files, it just compares the location, it it is a valid one, then allow, and you can keep adding and removing files to allowed locations
without affecting your program.
Size:
If the file has a specific file size, you can quickly check its size and compare it. But it is unreliable as files can be changed/patched and without any change in size. You can avoid that by also applying a CRC check to detect if the content of the file changed.
But, both size and CRC can be changed. Also, this requires you to have a list of file names and their sizes/CRC, and keeping it up to date.
Signature:
Deanna mentioned that you can self-sign your executable files. Then check if the signature matches yours and allow/deny based on that. This seems to be a good way if
it is okay for you to sign all the executable files you want to allow. It doesn't require you to keep an updated list of allowed files.
Hash:
arx also pointed out, that you can hash the files. It is one of the slowest methods, as it requires the file to be hashed every time it is executed, then compared to a list of files. But it very reliable as it can uniquely identify each file and hard to break. But, you will need to keep an up to date database of every file hash.
Finally, and depend on your needs and options, you can mix two or more ways together to get the results you want. Like, checking file name + location, etc.
I hope I covered most of things, but I'm sure there are more ways. Anyone can freely edit my post to include anything that I have missed.
I would recommend using the signature, if it has one, or the hash otherwise. Apps such as Office that update frequently are more likely to be signed, whereas smaller apps downloaded off the Internet are unlikely to ever be updated and so should have a consistent hash.