The wheel Group
The wheel group is, perhaps, not widely used today, or is seen as “archaic” and irrelevant. Nothing could be further from the truth.
The wheel group is a group which limits the number of people who are able to su to root. This usually consists of a group named “wheel” and a set of users that are permitted to use the utility ’su’ in order to change to root.
Many systems, especially either commercial systems or Linux systems, come without wheel groups configured and implemented. At least one Linux distribution, comes with wheel groups preconfigured but not active. However, all or nearly all BSD based systems will come with the wheel group installed and set up.
However, at its simplest, a wheel group implementation requires no special set up. The basic set up, as it was in the beginning, was to do the following:
- Create a “wheel” group in /etc/groups
- Change the permissions of the “su” command so that only those in the “wheel” group may run it.
That’s all there is to it. Many su implementations, however, added internal support for the wheel group, perhaps with logs kept and a more informative refusal message explaining why su would not run (for those not in the wheel group).
Perhaps one reason that the wheel group is not widely used may have something to do with the GNU project. The GNU implementation of su has this in its info page:
Why GNU `su' does not support the `wheel' group =============================================== (This section is by Richard Stallman.) Sometimes a few of the users try to hold total power over all the rest. For example, in 1984, a few users at the MIT AI lab decided to seize power by changing the operator password on the Twenex system and keeping it secret from everyone else. (I was able to thwart this coup and give power back to the users by patching the kernel, but I wouldn't know how to do that in Unix.) However, occasionally the rulers do tell someone. Under the usual `su' mechanism, once someone learns the root password who sympathizes with the ordinary users, he or she can tell the rest. The "wheel group" feature would make this impossible, and thus cement the power of the rulers. I'm on the side of the masses, not that of the rulers. If you are used to supporting the bosses and sysadmins in whatever they do, you might find this idea strange at first.
Is it any wonder that GNU/Linux systems don’t enable the wheel group by default? FreeBSD, however, does use the wheel group by default – as does OpenBSD and NetBSD.
I have noticed that the or a “wheel” group has been reading and writing data off my computer. I have also noticed that other things have gone on with my computer as well such as two proxies set up of which were not authorized. There has also been information from this computer used to write stories and music from information gathered. Which does not give me as the author free reign to write/ compose or sketch on my computer without someone else using the information. Now, I know this sounds impossible I have been told this is impossible but it isn’t. So much for the security programs offered for computers that people spend vast amts of money on.
So, you SEE, this by now has probably already been read and written as I type this for all I know….perhaps I need to bring up the activity monitor and check that out.
Have a lovely day.
I
As you noticed, it is not impossible for your computer to be compromised (as we call it). If someone is determined enough, any computer can be taken over by someone else.
The best you can do is to keep your system updated and run checks for viruses, etc. on a regular basis. If you are an end user who wants a system that requires no updating or patching, you won’t find one.
If you are a user that wants a system that is easy to manage, and that has a good record of updates and of security, I would recommend any one of the following: Red Hat Workstation, PC-BSD, OpenBSD, MacOS X… Most systems require additional configuration to be the most secure; OpenBSD does not – and perhaps, neither does MacOS X.
That is why people spend money on computer security experts – and “tiger teams” to break in – and on Chief Security Officers of companies… instead of just on programs.
Another one of his alarmingly failed “power to the people” lapses. I’ve grown accustomed to them.
Fascinating historical note.
The wheel group is just common sense. You don’t want non-privileged local users to be able to just start guessing at the root password. And, if all your network daemons are running as a non-root user (as they should be), then the wheel group makes another hurdle to block a hacker who may get local access through a flawed network server. … “wheel” is just one more important layer of the security onion.
Sometimes, when we talk about Wheel group, we`re talking about the famous “circle of thrust”, that makes sense to me, it’s common sense that you at first sight will see, which users does/ or doesn’t have security capabilities.
thanks! after reading this, I have decided I do not want a ‘wheel’ group.
you need to uncomment the line
# Allows people in group wheel to run all commands
%wheel ALL=(ALL) ALL
In order to allow the wheel users to execute the commands
thanks:
Can Anybody help on this problem?
Problem statement.
In this part of the assignment, delegates will create a pseudo-device and write a device driver for it. The pseudo-device provides a “backdoor” for gaining root access for a particular user. Instead of compiling the device driver into the kernel, delegate will create a module. Modules are object binaries that can be dynamically loaded into the kernel. They are similar to a DLL in MS Windows. Below is the description of the device the delegates are creating and the functionality your device driver is required to implement.
This pseudo-device gives root privileges to the task whose pid is written to the device. When the module is installed, the uid of the user who are allowed to use this device can be passed as module parameters. Any other user, including root, that tries to use this device will get an “access denied” error. When the correct user accesses the device for executing operations, the device driver finds the task associated with the pid and grants that task root privileges.
Work expected:
1. Identify proper device id, registration functions, and driver methods for the above given problem statement
2. Design the proper data structures required and the identified functions/methods to be implemented. Note: Issues of race conditions and synchronization should be taken care if required.
3. Develop the kernel module code for the designed functions with proper entry points to the driver
4. Write Makefile for compilation of the developed kernel module. Construct your Makefile so that developed kernel module will compile with “make” command
5. Accommodate the platform interface for the access to the developed module
6. Add the compiled kernel module into the running kernel
7. A program that uses the developed module to exec() a bash shell with root privileges. Modify the Makefile so that above program will compile when “make test” is run
8. Test the developed module for its functionality and discuss the obtained results
This is a homework assignment, and has nothing to do with the wheel group specifically. This comment is out of place here. You could ask your professor or teaching assistant if you need to.