-accounts vs access control:
. accounts are for individual users and define set of possible operations for that user. (eg what operations can user A do?)
. access control system is a set of potential user/operation pairs (eg can user A do operation x?)
-access control can be built into the kernel or into the file system. the former being the default.
-the defining characteristic of the root user is uid of 0.
-while it is possible to change the root user name or create additional users with uid 0 -- but that is a security risk.
-superuser is defined as the user with effective uid 0. the actual user name is root.
-superuser (ie proc with effective uid 0) allows itself to change its uid and gid.
-but once it assumes another uid,gid it cant go back.
-this happens for example in the login proc that starts as superuser but then becomes the uid,gid of the user that logs in.
-setuid, setgid based access control allow executable files to run with elevated permissions.
-Access control (kernel/fs) types:
. role based (rbac) - assign privs to roles and roles to users.
. mandatory (mac) - like selinux - prevents users from delegating access to their objects.
. pluggable (pam) - answers questions like 'is user x really x?'
. kerberos - pam defines the framework, kerberos defines the implementation, esp on remote hosts.
. filesystem (acl) - traditional acl based on user, group ownership.
-root login does not keep a log of actions. if multiple people have root access, one cant tell who logged as root and when.
-a slightly better way to log root is 'su'. It does not record the commands executed as root, but tells who became root and when.
-su is best reserved for emergencies.
-a still better way to log root is 'sudo'. sudo keeps detailed logs of actions, hosts, time stamps etc.
-using sudo means you can have only few or zero people with access to real root.
-sudo is faster than su and direct root login. also a single file can be used to control access for an entire network.
No comments:
Post a Comment