Execute the WOL "wake" command as user?

[tpusztai]

I would like to wake up other computers from my FreeNAS box. From the terminal, but only as root, I can use the "wake" command and it does what I want. Now I would like to use this command as a regular user.

Since the owner/group and permission settings of the wake command are "-r-xr-xr-x 1 root wheel 6904 Apr 15 09:23 /usr/sbin/wake", I thought that if I add my username to the wheel group, it should work. Instead, if I execute the command, I get this message (FreeNAS-9.3-STABLE-201505100553):

[freenasuser@freenasbox ~]$ wake em0 <<MAC ADDRESS HERE>>
wake: Cannot open bpf interface: Permission denied

I'm stuck here. I would certainly avoid manually overwriting the permission of system files, and even if I did so, they would probably be restored at each FreeNAS system upgrade.

So, how to allow users executing the "wake" command in a proper way?

Thanks for your thoughts,

Tamás

 

[cyberjock]

The bpf interface is the berkeley packet filter. It's a Kernel device used for sniffing from as well as sending out packets. I don't know what your security model expects, but this is something that I don't know how to change, nor would I ever ever recommend someone change it to give others access to kernel based resources like this. The potential security implications are so serious that it's probably not possible to over exaggerate them.

 

[tpusztai]

Cyberjock, I fully agree with you, I would not change security settings at this level. What I'm looking for is a simple and "supported" solution that allow users to wake up their computers remotely via executing the "wake" command. I don't think that this command is particularly dangerous, and I see no reason why users should not be allowed to do this.

Tamás

 

[jgreco]

"sudo"

 

[cyberjock]

I don't think that this command is particularly dangerous, and I see no reason why users should not be allowed to do this.

Honestly, I don't think you have the requisit understanding of FreeBSD to make that claim.

1. The FreeNAS devs probably didn't expect people to try to use it in fashion you are desiring.
2. The FreeBSD design isn't friendly to allowing non-superuser things like this from happening.

So yeah, I totally disagree with what you "think" on this topic.

 

[tpusztai]

Cyberjock,

Again, I agree with you, tweaking the security settings of FreeNAS is dangerous, especially if done by a non-expert like me. And now, please, don't misunderstand me. With all my modesty (fed by comparing our experience reflected by the number of messages in these forums) I just ask: Do you think that my goal, i.e. to allow a non-priviliged user to initiate a WOL request (so as to wake up his favourite workstation) from the FreeNAS box is dangerous? If yes, please tell me why, but if not, then I would expect that there exists a "secure" or "official" solution to do so, and this solution is what I would like to know.

Thanks,

Tamás

 

[jgreco]

Again, look at "sudo". Secure solution.

 

[Bidule0hm]

Proper solution already found 3 posts before: do some reading on the sudo command ;)

Edit: well, ninja'd by jgreco :p

 

[jgreco]

There's also a variety of ways you could maintain a sudoers file (since the default FreeNAS one isn't going to be what you want), and there's potentially even a simpler way to implement this if needed, which involves copying the wake executable to the pool, setuid root, mode 4750, with a group that only authorized users have access to. There are also a variety of other ways you might be able to do this. It can absolutely be done safely and securely, but there are questions like "should any user be allowed to WoL any box" that need to be answered.

 

[cyberjock]

But even if you move the executable, I don't see how that gets around the resource restriction he listed above...

[freenasuser@freenasbox ~]$ wake em0 <<MAC ADDRESS HERE>>
wake: Cannot open bpf interface: Permission denied

Am I out to lunch?

 

[tpusztai]

What jgreco suggests, i.e., copying the "wake" executable to the pool, then adding a setuid flag to it actually works. Thanks for the idea.

I have tried something similar before. I wrote a wrapper script that calls "wake", set the owner/group of this script to root/wheel, and added the setuid flag to it. But this approach did not work, I got the same error message about the bpf interface as if I called "wake" directly.

... there's potentially even a simpler way to implement this if needed, which involves copying the wake executable to the pool, setuid root, mode 4750, with a group that only authorized users have access to. ...

 

[cyberjock]

I didn't expect that to work, hence I didn't give the recommendation. Glad someone else did since it actually works!

Food for thought!

 

[jgreco]

But even if you move the executable, I don't see how that gets around the resource restriction he listed above... Am I out to lunch?

Yes, but that lunch is where I took you out to lunch and you learned something fun: an old UNIX admin's trick.

The fundamental problem is that you need escalated permissions to access bpf. There are lots of things in the base system which may need escalated permissions to access network services. Consider ping and traceroute for example. You look at those and you'll find them to be setuid. So a user who is allowed to run the executable will be able to, but the system will substitute in a different effective user ID (0, or root, in this case). This means that that particular copy of the executable gets different privileges.

But there are plenty of things especially in sbin-land that aren't SUID, because you don't want arbitrary users running them, or other things like shutdown, which you want restricted on the basis of group. So you can redesign your system with suitable permissions. On a normal UNIX box, that is. But FreeNAS, that's slightly different. You don't want to change the base system. But, since the export directories are (foolishly?) not noexec/nosuid, you can take an executable over into the export directories, change the permissions there, and execute it. And it'll be persistent across minor software updates, at least.

What jgreco suggests, i.e., copying the "wake" executable to the pool, then adding a setuid flag to it actually works. Thanks for the idea.

I have tried something similar before. I wrote a wrapper script that calls "wake", set the owner/group of this script to root/wheel, and added the setuid flag to it. But this approach did not work, I got the same error message about the bpf interface as if I called "wake" directly.

Scripts can't be setuid. There's a number of problems with scripts being setuid, so most UNIX variants do not allow it. You need a wrapper executable. But for user-facing stuff usually it is better and safer to use something designed to the task, such as sudo, which provides fine grained control and logging as well.

But as with most things UNIX, there's like 8 or more ways to solve a problem.