[ Date Index ] [ Thread Index ] [ <= Previous by date / thread ] [ Next by date / thread => ]
On 20/12/13 16:58, Tremayne, Steve wrote: > OK, I've only recently caught up with the LUG emails and this one passed me by... > > > I am aware that I don't understand "root" access completely, so if someone can > give a succinct overview (or point me to the webpage I couldn't find after > searching on t'interweb), then I would appreciate the chance to not fall in to a > security problem in the future ... > > Just to clarify - I'm just looking to learn about the different reasons behind > these approaches, rather than the specifics of Stinga's server problem > > > > Ok, so "root" is a user. Ok, understood. (Not quite sure where the "wheel" group > comes in to this, but that's possibly a different topic) > > And "sudo" and "su" are commands to run a command as a different user..., i.e. > root?? But *buntu's don't have a "root" user, so I'm getting hazy now... > > > So, if your friendly hacker has found any user/password combo to gain access, > surely they then just type "sudo <bad commands>" and they have exactly the same > access level to the box? > > > I believe that the reason for sudo was to allow a user access to specific commands > at a privileged level (i.e. sudo apt-get update) but not others (sudo install > rootkit)... > > So where does "su" come in to this? > > And (for a bonus point), why do some distros use one over the other? :o) > > > I'm just trying to learn the fundamental security concepts here, so that I can > understand the advice given to Stinga and make my home system more secure > > > Thanks (& Happy Christmas!) > > Steve Ok, I'll take a stab at this - there are a LOT of resources available on the internet at large for this topic however, and you're advised to do some further reading and research at your leisure. Ah, Simon just replied whilst I was typing this, which will save a lot of the basics as he's already covered them. Excellent. I'll just add some extra details. Firstly, although the origin of "root" is uncertain, it's thought to originate from MULTICS, the system that Ken Thompson and Dennis Ritchie were working on prior to, and largely responsible for inspiring them to, build the original UNIX at Bell Labs in 1969. Whilst MULTICS didn't have a root account, "the root" referred to the top level of the filesystem: / The original UNIX also had a root user, so called because their home directory was based in / and they were the first and most powerful user of a new system, capable of accessing, deleting or modifying every file under / so, basically all of them. These days, most systems have a /root folder now to keep the root user's clutter out of / (until relatively recently, Solaris was a noticeable hold-out). ALL Unix and Linux systems (and BSD, Mac OSX, etc) have a root account, although it may not be enabled or obvious out of the box. On Mac OSX the true root user has to be specially unlocked and enabled, and on Ubuntu, the root user is created but all system administration is designed to be performed by users with elevated privileges via sudo. I too am on an Ubuntu machine at the moment, so I'll demonstrate: ghost@failbot:~$ grep root /etc/passwd root:x:0:0:root:/root:/bin/bash ghost@failbot:~$ id root uid=0(root) gid=0(root) groups=0(root) If you do this on your PC, you will see exactly the same results. /etc/passwd holds the list of local users on your computer along with some other information like default login shell and User ID (UID) and Group ID (GUID) membership information. Note that root, who isn't actually a user at all, but a special, unique login class, always has a UID and GUID of 0, the lowest allowable value. Nobody else can have those values, and nobody by definition can have higher privileges than root (although they can have equal rights). It's probably simplest to think of root as being *GOD* on a Unix machine: they can do anything, delete anything, create anything. If someone gets your root password (this is where the term "rooted" comes from in relation to hacking: an attacker compromising your root user account and gaining "god"-level access to your resources). If you check your own user account with the above tests you'll get these results instead: ghost@failbot:~$ grep $USER /etc/passwd ghost:x:1000:1000:ghost,,,:/home/ghost:/bin/bash ghost@failbot:~$ id $USER uid=1000(ghost) gid=1000(ghost) groups=1000(ghost),4(adm),24(cdrom),27(sudo),30(dip),46(plugdev),109(lpadmin),124(sambashare),126(vboxusers),128(debian-tor),132(kvm),139(libvirtd) Most 'sane' Linux distributions will start creating new user accounts, including those created during the initial install, with a UID of 1000, incrementing by 1 for every new user. Most will also set up a new group with the same name as the user and a matching GUID: here, I setup "ghost" as my user account during the install of Ubuntu and it automatically designated me as user ghost with UID 1000 and created a new group "ghost" specifically for that user with a matching GUID of 1000. The next user created will have a UID of 1001 and a unique group created for them with a GUID of 1001, and so on. The "id" command run second shows that my account "ghost" is also the member of numerous other groups, all listed along with their unique GUIDs: I'm in a lot of groups because I'm a sysadmin, you will probably be in less. Incidentally, Ubuntu automatically creates the root account but discourages "ordinary" users from going anywhere near it - the root password is generated randomly during installation. If you want to get access to it, do this (presuming you have access to sudo): sudo su - passwd exit This will invoke your super-user privileges via the sudo mechanism and drop you into root's environment in a shell: you issue "passwd" as root, and set the new password to something secure, then exit. You now have access to your root account, should you need it. Normally, you won't ever need to access the root account directly: by default, the first user created during an Ubuntu install (probably yours, I'd imagine) is automatically granted access to sudo. Simon has already covered that luckily: you can just prefix any command with "sudo" and your privileges will be escalated appropriately. The "wheel" group is just another convention (some distros, including Ubuntu, prefer a group called "sudo" or "admin") - historically, when setting up sudo privileges for system-wide control a subset of completely trusted admins are added to the wheel group, and any user who is in the wheel group can perform ANY action as if they were root. This is obviously a serious amount of trust to give anyone, and should be used sparingly. As Simon touched on, sudo access can be tailored in a highly granular fashion so that some users can do things like software upgrades but can't read syslogs, backup admins can dump/restore filesystems but can't control services, etc. If you want to check your system, do: sudo visudo Which will invoke the sudo configuration file in your $EDITOR - for god's sake don't make any changes though. If you skip down through it you will see the lines: # Members of the admin group may gain root privileges %admin ALL=(ALL) ALL # Allow members of group sudo to execute any command #%sudo ALL=(ALL:ALL) ALL These lines are effectively identical: they mean that any user with membership in either of these groups can issue any command under sudo and have root privileges. In this example, only the %admin group is currently functional: the %sudo group is still commented out and thus inactive. It should be pointed out that that user/group membership is the very first and most primitive type of user access control available in modern Linux systems: MAC (Mandatory Access Control) systems like SELinux, etc, provide infinitely more granular and robust methods of controlling security but with a corresponding increase in difficulty and admin overhead. Hope that this might be of some use, feel free to ask if you want anything cleared up. Regards -- The Mailing List for the Devon & Cornwall LUG http://mailman.dclug.org.uk/listinfo/list FAQ: http://www.dcglug.org.uk/listfaq