I've been working with Pis for a few years now, but I've recently encountered something that I can't quite wrap my head around. I am working to set a few Pis as catalog machines for a local library, meaning that the patron user I created should only be able to access chromium from the desktop. Currently, I have denied the patron user all sudo permissions and locked down their access to their own file directories (execute only) and those of other users (no access). I have also disabled most of the desktop icons and further hidden x-terminal, so users won't accidentally stumble upon it. Luckily, these security measures will be acceptable for most of our users, but it isn't most users that concern me.
In some testing I've done so far, I've found that it is possible to use chmod u+rwx /home/USER on one's own user directory, even without sudo privileges. This obviously is not ideal, as it gives users that have sufficient pi experience the ability to modify anything within their directory. I then tried to limit chmod permissions in /bin to be executable by root users only, which worked perfectly to prevent patron from changing its own modifiers, but it also creates a boot loop on the initial login screen (Entering correct password generates blackscreen and reloads login screen).
Now that we've gotten that out of the way, I have a few questions, some for the furthering of this project, and some just to satiate my curiosity:
~Is there some reason that logging in to a user would call chmod?
~Is there any way to limit access to commands such as chmod that could potentially cause security threats?
~Are there any other breach possibilities that I have not considered? / Is there any way to protect against them?
And yes, I am aware that as long as a user has physical access to the Pi's, almost anything is possible through the USB ports, but the Pi's are unreachable, so I'm only looking for software workarounds.
Related
I'm in the process of building a small linux distro based on Debian for automated network testing. I am running into a pretty annoying problem though. A number of applications like paris-traceroute, ping, dublin-traceroute and so forth are not working correctly. They return an error of being unable to open a raw ICMP socket. I have tried using 'setcap cap_net_raw+ep ./application' and it's not working even though getcap indicates that the bits have been set.
I'm also running into the same problem if I try to use them as setuid root. They only work under sudo. So I'm wondering if I screwed up permissions on some intervening library or if there is some other issue.
Anyone run into something like this or have a solution?
Thanks!
In case anyone comes across this I'll explain why this is failing.
What I didn't mention is that the applications (like ping, etc) are actually installed in /opt. In this distro /opt actually and encfs file system that is only mounted after the livecd has been authorized against a licensing type of server (there are valid reasons for this - it automatically tests network connections and send the results to network engineer. We only want it to run within a specific time frame that would be associated with the user trouble ticket). So /opt isn't a real filesystem - it's an encrypted file mounted via fuse to looks like a file system. As such setcap and setuid don't actually work and likely cannot work.
Background: I look after the Raspberry Pi version of Scratch for the Foundation. Mostly this is a matter of Smalltalk programming, VM developing and some very frustrating moments with shell scripts.
Right now I'm baffled and annoyed by what seems likely to be a unix permissions or related issue when using xrdp to connect to a Pi from any other machine. I know that it's not a problem directly with theSqueak VM since google has revealed quite a few other applications having similar looking issues. Part of my problem is that I don't know enough about this area to really know what to search for to narrow things down.
So, problem description -
The current Scratch system runs on the Squeak Cog VM (see https://github.com/OpenSmalltalk/opensmalltalk-vm), which amongst other things uses pthreads and needs to set the thread priority. That used to be something that required modifying some config but more recent (Raspbian) kernels have no problem with it.
Except when using xrdp, which is a pain because I mostly work with my Pi via xrdp to my iMac. To handle this I have to prepend a 'sudo -E' which is tolerable for a developer but not really good for general users.
I have a similar problem with a trivial file copying command used in the VM make process as well, and that doesn't use any thread stuff nor priority work, but does require me to sudo make in a terminal window.
As an experiment I tried using tightvnc, to see if anything might work better. After reading the full install instructions (https://www.raspberrypi.org/documentation/remote-access/vnc/) and adding the auto-startup init.d script etc, it seemed like maybe we were in luck because the sudo isn't needed! Hooray! Of course, I was a bit disappointed by the seemingly slower display handling, but never mind.
Sadly this isn't even close to the end of the story. I've recently been working on completing the support for the X composition input window system that allows Japanese and other non-Latin1 type language users to enter characters more easily. It's pretty clever, once you've installed iBus, Anthy, many fonts and done some setup. But, while it works perfectly well on a Pi with a direct display, and fine on an xrdp display (with the sudo to allow Scratch to run in the first place, of course) it simply won't work via vnc with or without a sudo.
Googling shows a large number of other applications having problems in odd ways with the relevant XCreateIC() call (see https://github.com/OpenSmalltalk/opensmalltalk-vm/blob/Cog/platforms/unix/vm-display-X11/sqUnixX11.c line:1659 for our usage) but nothing I can make much connection to vnc for. To add to the annoyance the combo window appears ok for Terminals!
To summarise-
direct display - no problems for either the pthread priority or the compo window
xrdp - needs sudo for pthreads priority but the compo window works ok
vnc - doesn't need sudo for pthread priority but compo window doesn't work.
What I need: help with finding out what causes these problems and maybe even solutions. A way to configure xrdp to not require 'sudo' would be nice.
To my delight a colleague found what appears to be a very effective answer to this; it seems that the /etc/pam.d/common-session file needs a single line adding.
Edit the file and add
session required pam_limits.so
This allows all the applications I have that previously had permission related problems to run under xrdp. Another Scratch user who had a similar issue using PuTTY reports that it solved that issue as well.
I am working on a kiosk gui, written in ruby/gtk and using ubuntu. I'd like to be able to reboot from within the ruby/gtk gui -- specifically, I want to let people who swipe administrative cards choose to reboot the machine as one of their administrative options. I do not want to give these users root access more generally. Is there a way to do one of the following:
1) reboot from command line without root permission, or
2) change/reduce the level of permission required to reboot from command line so I can let people click on a button to reboot without worrying about their broader access to the system, or
3) (I doubt this is possible) perhaps somehow from within gtk or however programmatically log in to root to use the reboot command without exposing the password to anyone who can view the source code.
You could configure your user to be allowed to use the shutdown command via sudo. That would probably do what you want.
On most operating systems today, the default is that when we install a program, it is given access to many resources that it may not need, and it's user may not intend to give it access to. For example, when one installs a closed source program, in principle there is nothing to stop it from reading the private keys in ~/.ssh and send them to a malicious third party over the internet, and unless the user is a security expert proficient in using tracing programs, he will likely not be able to detect such a breach.
With the proliferation of many closed sourced programs being installed on computers, what actions are different operating systems taking to solve the problem of sandboxing third party programs?
Are there any operating system designed from the grounds up with security in mind, where every program or executable has to declare in a clearly readable format by the user what resources it requires to run, so that the OS runs it in a sandbox where it has access only to those resources? For example, an executable will have to declare that it will require access to a certain directory or a file on the filesystem, that it will have to reach certain domains or IP address over the network, that it will require certain amount of memory, etc ... If the executable lies in its declaration for system resource requirements, it should be prevented from accessing them by the operating system.
This is a the beauty of Virtualization. Anyone performing testing or operating a questionable application would be wise to use a virtual machine.
Virtual Machines:
Provide advantages of a full Operating System without direct hardware access
Can crash or fail and be restarted without affecting the host machine
Are cheap to deploy and configure to a variety of environments
Great for using applications designed for other platforms
Sandboxes applications that may attempt to access other private data on your computer
With the seamless modes virtualization programs such as VirtualBox provide you can take advantage of Virtual Machine's sandboxing in a nearly seamless fashion.
You have just described MAC (Mandatory Access Control) in your last paragraph.
I was always curious about that too.
Nowadays mobile OSes like Android do have sandboxing built-in. When installing an app, it asks for permissions to access a set of resources/features. Windows too as far as I know, at least to some extend. It is more permissive though.
Ironically, linux and others seem to be far far away concerning "software based permissions" and are stuck in the past, which is a pity. ...at least, as far as I know. I would be pleased for someone to show me wrong and show me a "usable" open source system where application sandboxing/privileges is built-in. Currently, as far as I know, permissions are solely user based.
I think this awareness that not only users need rights to access documents but also executables need rights to access resources has been missing for several decades. It might have avoided a plague of viruses and security issues of our century.
I recently installed a SSH server on my Windows 7 PC and created a separate user account for this. When i logged in using SSH, i could access all the windows directories.
/cygdrive/c
/cygdrive/d
/cygdrive/e
How do i prevent this user from accessing all the win directories other than its home directory under cygwin /home/chuck/ ?
Preferably i do not want the user to even view /cygdrive when the user types "mount".
Is there a easy way to do this?
I want to later allow remote users to log on to this machine and avoid messing up other things.I know i can setup a separate machine but this is a plan for later.
I don't know specifically about Cygwin but in Unix in general you could use the chroot.
try changing the group of the ssh_user_name to Guest, then specifically allow rwx perms for the Guest group through the security tab in Windows. I have not tried this before, which I am going to try soon. This should be easier than denying access to each drive by adding the ssh_user_name, which is highly inefficient if you have many drives like I do.
The reason why i chose guest is because by default it is denied all access, which makes it easier to specifically choose which drive you want the ssh_user_name to have access to.