[Dshield] Flavors of Linux
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
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