[Dshield] Flavors of Linux

stephane nasdrovisky stephane.nasdrovisky at paradigmo.com
Wed Oct 6 14:15:50 GMT 2004


Stephane Grobety wrote:

>sn> The major difference between windows and unix, in my opinion, is that
>sn> there are no super user under windows: everything is permission based, 
>sn> if you want a root-like account, you have to include it in admin groups 
>sn> or give it allow everything permissions.
>
>Ah... the SYSTEM account has permanent, complete right over everything
>local. You can't login with it, but it is more or less the equivalent
>of root.
>  
>
Is the system account really a super-user? Why are there some 'system 
account' entries in some acl (i.e. on c:\) ? Is the system account 
behaviour sp dependant (and undocumented) ? I never tryed to remove any 
system account permission (this way, a cmd.exe launched by task 
scheduler gives me full access to my nt, whatever I (mis)did, I simply 
have to wait up to 1 minute).

>But you forgot something, probably the most important part: NT-based
>OSs have ACLs on other things than files: system objects (like mutex,
>pipes, memory mapped files, etc.)
>
And registry keys.

> all have ACLs that can be controlled
>by the calling program: Something that Unix, AFAIK, doesn't have.
>  
>
Even the system administrators could configure acls for their web 
server, sql server, directory server, ... but it requires a device which 
does not seems to be implemented in most of them: brain.

In unix, everything is a file :-) IPC (mutex, ?) are implemented on the 
user-side, I think! There are no kernel binding for these features (but 
mmap). Unfortunatly, I also think permissions are almost yesorno.
kernel IPC are limited to signals, I can't remember anything else. I 
think permissions on signals are very limited, all I can remember is 
that non root can hardly send a signal to root process. Or is the 
receiving process responsible for checking permissions ?
Pipes are either named pipes (= +- files) or unnamed, where the parent 
process specifically grant access to the child(s) for both ends of the 
pipe (there are not many kernel hooks for pipes: read, write and create 
(which is called pipe, I think), fork is usually following the pipe 
creation, only the childs which inherits the file descriptor of the 
created pipe have access to it, I guess any process that can guess the 
fileid also have access to the pipe, it may be limited to the child tree ? )





More information about the list mailing list