InformAction Forums

Posted: **Wed Aug 05, 2015 4:50 am**

Just an idea I wanted to bounce off people: Do you think it makes sense to run multiple (per-application?) 'slave' accounts on your operating system? Ie accounts that you can control like puppets, but which have minimal privileges of their own.

I whipped up a simple shell script to make them on standard Linux systems:

Code: Select all

#!/bin/sh

MASTER=$1
SLAVE=$2
groupadd $SLAVE
useradd -g $SLAVE -mk /etc/slaves/profile $SLAVE
echo "$MASTER ALL=($SLAVE) NOPASSWD:ALL" > /etc/sudoers.d/$SLAVE
SLAVE_HOME=`grep '^$SLAVE:' /etc/passwd |awk --field-separator=: '{print $6}'`
chmod -Rv o-rwx $SLAVE_HOME
usermod -aG $SLAVE $MASTER

Where /etc/slaves/profiles contains only a .profile file to set the umask:

Code: Select all

umask 0007

So, the script creates the slave in a new group, gives the master that group and privileges to run any command as the slave and write any of the slave's files, then locks down the slave's home to be untouchable by anyone else. The master can then use slave accounts to run anything that doesn't need direct access to the master's personal files (eg Firefox), or simply manage each set of files (business documents, music, code, etc) in a different slave.

In theory, you could set up sudoers permissions so that each user of the system could use the script to make slaves for him/herself, but not for anyone else. Somewhat like virtualization, but with less isolation and less overhead, more suitable for everyday use.

Does this sound safe/useful?

Posted: **Wed Aug 05, 2015 9:06 pm**

I'm not sure I completely follow.... but speaking as a power user of Linux:

I think it has only limited security benefits (if any), because it's still your system you're doing this stuff on, no sandbox or isolated chroot or anything like that.
However, I do think it has some use cases, but largely for software developers & power users though. Mostly if you need to test something as another user but you need quick access to your own files and/or you don't want A) to deal with a default-configured setup (including, say, desktop environment), and/or B) to change your own environment if, say, you need to test a custom .profile etc.
Or it could be useful if all you need is for something to run without access to your home folder (or, I suppose, a VirtualBox shared folder), and you don't care what happens to the system - but again, I think that's a distinction that everyday users won't really understand and thus they won't know how to gain anything from doing this. Am I missing something?

I'm not sure if it has any privacy uses, if that were the case it would have to be possible to limit each slave to ONLY be able to write to files/directories it owns or the group is its own group (meaning, it has to be blocked from writing to some world-writable files), then you can search for files by owner. But I don't know whether that's possible on a Linux system and keep the account functional, I haven't played with this stuff much.

Posted: **Wed Aug 05, 2015 11:37 pm**

(offtopic: as far as you know, on what Linux distributions will that script work as-is?)

Posted: **Thu Aug 06, 2015 12:35 am**

barbaz wrote: I think it has only limited security benefits (if any), because it's still your system you're doing this stuff on, no sandbox or isolated chroot or anything like that.

True. It's not for dealing with privilege escalation; it's just to mitigate the fact that merely breaking into your own account is normally all the attacker needs.

Mostly if you need to test something as another user but you need quick access to your own files and/or you don't want A) to deal with a default-configured setup (including, say, desktop environment), and/or B) to change your own environment if, say, you need to test a custom .profile etc.

Possibly. But why not run Firefox in an isolated account always?

Or it could be useful if all you need is for something to run without access to your home folder (or, I suppose, a VirtualBox shared folder), and you don't care what happens to the system - but again, I think that's a distinction that everyday users won't really understand and thus they won't know how to gain anything from doing this. Am I missing something?

Everyday users? On Linux? Those are either rare or they have someone manage it for them.

I'm not sure if it has any privacy uses, if that were the case it would have to be possible to limit each slave to ONLY be able to write to files/directories it owns or the group is its own group (meaning, it has to be blocked from writing to some world-writable files), then you can search for files by owner.

The slave(s) would be able to read globally-readable files, but not each other's or the master's. Note that the slave's home directory is closed to those outside its group, and each slave gets a different group.

barbaz wrote:(offtopic: as far as you know, on what Linux distributions will that script work as-is?)

I wrote it on Ubuntu. It uses POSIX shell syntax, so that shouldn't be an issue. Any system that uses /etc/passwd for its user management and has the right tools (groupadd, useradd, tee, awk, grep, chmod) should work, but let me know if not.

Actually, I think the 'tee' is redundant and I'll get rid of it. This script is meant to be run as root.

Posted: **Thu Aug 06, 2015 3:54 am**

Thrawn wrote:it's just to mitigate the fact that merely breaking into your own account is normally all the attacker needs.

Well that depends what they're after. If it's personal info then yes. If it's hacking the computer, then a Linux account - even one with sudo privileges - is useless to them if they don't have its password & can't crack it. The account would have to be root.

Thrawn wrote:But why not run Firefox in an isolated account always?

Because an isolated VM that doesn't run the same OS as your host is better for that kind of thing

Seriously though, it would be useful sometimes (e.g. to make a clean profile test safer), but if you have a highly customized profile, it would be a lot of copying back and forth and extra hassle, which when you have tools like NoScript may not be worth it.

Thrawn wrote: Everyday users? On Linux? Those are either rare or they have someone manage it for them.

I think you would be surprised. I know a LOT of "normal" computer users who run Linux and manage it themselves. (However I think they all use Ubuntu.)

Thrawn wrote:The slave(s) would be able to read globally-readable files, but not each other's or the master's. Note that the slave's home directory is closed to those outside its group, and each slave gets a different group.

I was thinking private in the sense of Private Browsing type private - as in you know exactly what files the slave account can write to, and they are all GUARANTEED to be the slave account's files in some form, so that you know exactly what files to delete. If the slave can write to world-writable files it doesn't own and don't belong to its own group, you can't necessarily be sure what data it's written.

Thrawn wrote:I wrote it on Ubuntu. It uses POSIX shell syntax, so that shouldn't be an issue.

Shell syntax isn't an issue, the behavior of sh across systems is uniform enough that that wouldn't be an issue for your script. I was thinking in terms of whether the system's sudo would be set up to recognize things in the sudoers.d directory. I've found that different distros are different on things like that (like, hypothetically, some may not have a directory like that, some may not call it sudoers.d) with a bunch of programs, but I don't know if it's just as different with sudo as those others. That's why I asked.

EDIT #And, the behavior of the user* commands is also VERY different across different distros.

Posted: **Fri Aug 07, 2015 12:28 am**

barbaz wrote:If it's personal info then yes. If it's hacking the computer, then a Linux account - even one with sudo privileges - is useless to them if they don't have its password & can't crack it. The account would have to be root.

That's kind of the point. We have all sorts of defences to stop an attacker getting root privileges, but not enough to protect the personal information stored in unprivileged accounts. http://xkcd.com/1200

Thrawn wrote:But why not run Firefox in an isolated account always?
Because an isolated VM that doesn't run the same OS as your host is better for that kind of thing

Yes, but it is also much more overhead, and much more awkward to access. You have to set up shared folders, etc. Whereas the master/slave setup allows the master to freely read and write the slaves' files.

Seriously though, it would be useful sometimes (e.g. to make a clean profile test safer), but if you have a highly customized profile, it would be a lot of copying back and forth and extra hassle, which when you have tools like NoScript may not be worth it.

I'm not following you; in what circumstance would there be a lot of copying around?

I would envision that the master does all of its web browsing via a dedicated slave. Or possibly several slaves, if you really want to isolate different sites from each other.

Thrawn wrote: Everyday users? On Linux? Those are either rare or they have someone manage it for them.
I think you would be surprised. I know a LOT of "normal" computer users who run Linux and manage it themselves. (However I think they all use Ubuntu.)

Well, if someone is confident in administering their own Ubuntu, then running a script to create a new slave and then running commands as that slave using sudo shouldn't be too hard. It's just a matter of making the setup script good enough.

Thrawn wrote:The slave(s) would be able to read globally-readable files, but not each other's or the master's. Note that the slave's home directory is closed to those outside its group, and each slave gets a different group.
I was thinking private in the sense of Private Browsing type private - as in you know exactly what files the slave account can write to, and they are all GUARANTEED to be the slave account's files in some form, so that you know exactly what files to delete. If the slave can write to world-writable files it doesn't own and don't belong to its own group, you can't necessarily be sure what data it's written.

There's not all that much that is globally writeable on a normal Linux system, except /tmp.

I was thinking in terms of whether the system's sudo would be set up to recognize things in the sudoers.d directory.

Good point. That depends on the core sudoers file. Theoretically the script could edit that instead, but doing that robustly would get a *lot* more complicated.

EDIT #And, the behavior of the user* commands is also VERY different across different distros.

True, but I did use the low-level commands (useradd, usermod) instead of the higher-level adduser etc. Admittedly, that was mostly so it would be more suitable for non-interactive use. I'm not sure how portable they are.

Posted: **Fri Aug 07, 2015 2:59 am**

Come to think of it, I do see one practical issue with this. While sudo works for running programs as root, it doesn't seem to work for running graphical programs as a non-root ("standard") user. Take what happens for gedit:

Code: Select all

$ sudo -u foo gedit
[sudo] password for *******:
No protocol specified
No protocol specified
Cannot open display: 
Run 'gedit --help' to see a full listof available command line options.

A non-graphical program, like ksh, runs fine... but even trying to run qtconfig from there:

Code: Select all

$ qtconfig
No protocol specified
No protocol specified
qtconfig: cannot connect to X server :0

Do you know of any workarounds, or does this limitation not apply to the slaves for some reason?

Thrawn wrote:That's kind of the point.

Well then IMO this is a great idea at least in theory.

I tried to use this script in my Lubuntu VM, but couldn't:

Code: Select all

chmod: missing operand after ‘o-rwx’
Try 'chmod --help' for more information.

Looks like you have an undefined variable.

Thrawn wrote:Yes, but it is also much more overhead,[...]

Oh, I was mostly kidding about that, thinking what with Firefox Hello & Pocket & Heartbeat & Health Report & unremovable socialware &...

sorry I didn't make that clearer.

Thrawn wrote:I'm not following you; in what circumstance would there be a lot of copying around?

I would envision that the master does all of its web browsing via a dedicated slave. Or possibly several slaves, if you really want to isolate different sites from each other.

If you want the profile in the slave to be totally disposable, as in when done with Firefox you delete the slave's profile and re-populate it with the master's copy of the profile.

I guess what I'm getting at is that there's an extra level of protection (mainly from potentially dangerous user actions, but also from websites tracking you) if the profile is maintained in the master account, regardless of how much web browsing is done through the slaves.

Thrawn wrote:There's not all that much that is globally writeable on a normal Linux system, except /tmp.

Nothing in /var?
And as far as you know, anything written in /tmp by the slave for the type of uses you're thinking, would be owned by or belong to the primary group of the slave?

Thrawn wrote:
I was thinking in terms of whether the system's sudo would be set up to recognize things in the sudoers.d directory.
Good point. That depends on the core sudoers file. Theoretically the script could edit that instead, but doing that robustly would get a *lot* more complicated.

Well if this kind of difference is all done in the configuration files, then all that your script has to do to be portable enough is contain a note that it requires the sudoers.d directory set up. It's probably best to just `test -d /etc/sudoers.d`, and if it's not there, echo a message and exit 1. It's not up to scripts like your example to actualky reconfigure such core system programs, but I wouldn't consider it an issue if it *requires* certain configurations (that is, that can be set in config files) of its dependencies.

Thrawn wrote:I did use the low-level commands (useradd, usermod) instead of the higher-level adduser etc. Admittedly, that was mostly so it would be more suitable for non-interactive use. I'm not sure how portable they are.

(emphasis mine)
Meh, I was getting mixed up with command-line utilities like adduser, assuming that it took the place of useradd/usermod.. oops

Then it's not all that varied, just one or two command line options behave slightly differently (even if you add *BSD in the mix).

Posted: **Fri Aug 07, 2015 4:15 am**

barbaz wrote:
Code: Select all
$ sudo -u foo gedit
[sudo] password for *******:
No protocol specified
No protocol specified
Cannot open display: 
Run 'gedit --help' to see a full listof available command line options.
A non-graphical program, like ksh, runs fine... but even trying to run qtconfig from there:
Code: Select all
$ qtconfig
No protocol specified
No protocol specified
qtconfig: cannot connect to X server :0
Do you know of any workarounds, or does this limitation not apply to the slaves for some reason?

Good point, the X session isn't shared. I expect that there are ways to do that, although it would likely mean giving the slaves some privileges. This looks relevant.

Or, if you were keen, you could start an X server on another slot, belonging to the slave, and switch to it (with Ctrl+Alt+F8-F12) when you wanted.

I tried to use this script in my Lubuntu VM, but couldn't:
Code: Select all
chmod: missing operand after ‘o-rwx’
Try 'chmod --help' for more information.
Looks like you have an undefined variable.

Is that the latest version? I did apply a fix to my original post yesterday.

Thrawn wrote:I'm not following you; in what circumstance would there be a lot of copying around?

I would envision that the master does all of its web browsing via a dedicated slave. Or possibly several slaves, if you really want to isolate different sites from each other.
If you want the profile in the slave to be totally disposable, as in when done with Firefox you delete the slave's profile and re-populate it with the master's copy of the profile.

I guess what I'm getting at is that there's an extra level of protection (mainly from potentially dangerous user actions, but also from websites tracking you) if the profile is maintained in the master account, regardless of how much web browsing is done through the slaves.

Well, it's always possible for you to write a wrapper script that would, eg, wipe a slave's Firefox profile, copy it from the master, and launch Firefox.

Thrawn wrote:There's not all that much that is globally writeable on a normal Linux system, except /tmp.
Nothing in /var?

Yes, there are some directories in /var but they have the same restriction as /tmp: you can only write/delete your own files.

And as far as you know, anything written in /tmp by the slave for the type of uses you're thinking, would be owned by or belong to the primary group of the slave?

That's controlled by setting the slave's initial login group and umask. So yes.

It's probably best to just `test -d /etc/sudoers.d`, and if it's not there, echo a message and exit 1.

I could do that.

Meh, I was getting mixed up with command-line utilities like adduser, assuming that it took the place of useradd/usermod.. oops
Then it's not all that varied, just one or two command line options behave slightly differently (even if you add *BSD in the mix).

Do you know offhand if there are any variations that affect this script?

Posted: **Fri Aug 07, 2015 5:13 am**

Thrawn wrote:Good point, the X session isn't shared. I expect that there are ways to do that, although it would likely mean giving the slaves some privileges. This looks relevant.

I don't think I personally would want to go that route... don't want my X server listening for connections not on the loopback interface.

Thrawn wrote:Or, if you were keen, you could start an X server on another slot, belonging to the slave, and switch to it (with Ctrl+Alt+F8-F12) when you wanted.

This sounds much better, is there a way to do this while still keeping the current login session and not doing a switch user type thing, and with only one (virtual) monitor? (Something equivalent to switching workspaces is totally fine by me, it's probably not essential to me that the master's windows be mingled with the slave's windows.)

Thrawn wrote:Is that the latest version?

Yes, I copied it as I was writing my post.

Thrawn wrote:

Thrawn wrote:There's not all that much that is globally writeable on a normal Linux system, except /tmp.
Nothing in /var?
Yes, there are some directories in /var but they have the same restriction as /tmp: you can only write/delete your own files.
And as far as you know, anything written in /tmp by the slave for the type of uses you're thinking, would be owned by or belong to the primary group of the slave?
That's controlled by setting the slave's initial login group and umask. So yes.

Nice, so this can be useful if you want to do something without leaving traces on your HDD either for privacy or for simply being careful with your system, or if just for seeing where all something would write to.

Thrawn wrote:Do you know offhand if there are any variations that affect this script?

My uses of those commands hasn't been for user creation so much as editing existing users, but just offhand I think some distros don't use the -a argument to usermod, not completely sure on that though.

Posted: **Sun Aug 09, 2015 10:04 pm**

barbaz wrote:
Thrawn wrote:Or, if you were keen, you could start an X server on another slot, belonging to the slave, and switch to it (with Ctrl+Alt+F8-F12) when you wanted.
This sounds much better, is there a way to do this while still keeping the current login session and not doing a switch user type thing, and with only one (virtual) monitor? (Something equivalent to switching workspaces is totally fine by me, it's probably not essential to me that the master's windows be mingled with the slave's windows.)

Depends on what you mean by 'switch user'. Have you tried it? 'Switch user' in Ubuntu, at least, results in multiple X servers, which can be accessed with Ctrl+Alt+F[number]. The default is slot 7, so Ctrl+Alt+F7; the next is on slot 8, etc. You can toggle between them freely, although in some cases that will lock the screen.

Is that satisfactory?

Thrawn wrote:Is that the latest version?
Yes, I copied it as I was writing my post.

Did you provide a command-line argument, giving the name of the new slave account?

Nice, so this can be useful if you want to do something without leaving traces on your HDD either for privacy or for simply being careful with your system, or if just for seeing where all something would write to.

Well, as mentioned, a slave could write to /tmp or /var. It shouldn't be able to affect any other process, but for privacy purposes it might be unsatisfactory. Unless you clean those locations afterward.

Thrawn wrote:Do you know offhand if there are any variations that affect this script?
My uses of those commands hasn't been for user creation so much as editing existing users, but just offhand I think some distros don't use the -a argument to usermod, not completely sure on that though.

Hmm. That's used to append the new slave group to the master's list of groups, instead of overwriting the list. Doing it manually would be cumbersome.

Posted: **Sun Aug 09, 2015 11:45 pm**

Thrawn wrote:Depends on what you mean by 'switch user'. Have you tried it? 'Switch user' in Ubuntu, at least, results in multiple X servers, which can be accessed with Ctrl+Alt+F[number]. The default is slot 7, so Ctrl+Alt+F7; the next is on slot 8, etc. You can toggle between them freely, although in some cases that will lock the screen.

Is that satisfactory?

The Ubuntu's switch user locks your running session behind your password. I don't want to keep re-typing my password when switching back and forth, and I don't want to allow automatic logins without password either... that's what I mean by not switch user. And using switch user brings back a disadvantage I was talking about earlier - the slave would get a default desktop.

But come to think of it, I guess there are some possible workarounds to give the slave a more navigable desktop environment either way, say:
- Try to copy in the desktop configuration from your own home folder before using the slave
- If you custom start the slave's X instance, isn't it possible to set up a far more customized environment for the slave? Say, instead of a desktop environment, just launch something minimalistic (& thus reasonably navigable), like openbox-session & dbus, then only the dependencies of whatever you're going to use in the slave. That would also be less overhead than a whole session... although for someone who uses Lubuntu, I'm not that sure how much less that would be in practice...

Thrawn wrote:Did you provide a command-line argument, giving the name of the new slave account?

First command-line argument was my own username and second was what I wanted the slave's username to be.

Actually I think I see a possible culprit... might it be that this line

Code: Select all

SLAVE_HOME=`grep '^$SLAVE:' /etc/passwd |awk --field-separator=: '{print $6}'`

needs changed to

Code: Select all

SLAVE_HOME=`grep "^$SLAVE:" /etc/passwd |awk --field-separator=: '{print $6}'`

so that $SLAVE is actually substituted instead of taken literally?

Oh phooey, the script doesn't create /etc/slaves/profile if it's absent. ~~Let me try again pre-creating it and see if it works then.~~ EDIT Apparently that's not it.
I'll post a shell script for that here (assuming people don't mind ksh) to reduce confusion.
EDIT2 How do you set the umask? Is it just `chmod 0007 .profile`?

Thrawn wrote:Well, as mentioned, a slave could write to /tmp or /var. It shouldn't be able to affect any other process, but for privacy purposes it might be unsatisfactory. Unless you clean those locations afterward.

Well yeah, you'd have to delete the files manually or by a script that searches for matching user & group.

Thrawn wrote:Hmm. That's used to append the new slave group to the master's list of groups, instead of overwriting the list. Doing it manually would be cumbersome.

What do you mean? IIRC I've seen some distros that use -g for overwrting the list and -G for appending... and others user -a -G to append and -G for ovewriting the group list. It's not that the option isn't provided, it's just that they do it different ways.

It's pretty easy to manually change one command in a shell script, depending on the distro...

Posted: **Mon Aug 10, 2015 1:23 am**

barbaz wrote: - If you custom start the slave's X instance, isn't it possible to set up a far more customized environment for the slave?

It should be, yes, with xinit.

Actually I think I see a possible culprit... might it be that this line
Code: Select all
SLAVE_HOME=`grep '^$SLAVE:' /etc/passwd |awk --field-separator=: '{print $6}'`
needs changed to
Code: Select all
SLAVE_HOME=`grep "^$SLAVE:" /etc/passwd |awk --field-separator=: '{print $6}'`
so that $SLAVE is actually substituted instead of taken literally?

I would have expected the shell to substitute it before running the segment inside backquotes, but perhaps not.

EDIT2 How do you set the umask? Is it just `chmod 0007 .profile`?

Permissions on the .profile aren't essential, but yes, that should work.

Thrawn wrote:Hmm. That's used to append the new slave group to the master's list of groups, instead of overwriting the list. Doing it manually would be cumbersome.
What do you mean? IIRC I've seen some distros that use -g for overwrting the list and -G for appending... and others user -a -G to append and -G for ovewriting the group list. It's not that the option isn't provided, it's just that they do it different ways.

I'm not sure that's quite right. On Debian-based systems, at least, -g changes the initial login group of the user - the group in which files are created by default. -G changes the list of supplementary groups. By default, -G will overwrite the supplementary list (but not touch the initial login group); with the -a flag, it appends.

Posted: **Mon Aug 10, 2015 5:15 am**

Thrawn wrote:Permissions on the .profile aren't essential, but yes, that should work.

Oh so you're saying that the .profile contains that line, not that its permissions are set to 0007.

Thrawn wrote:I'm not sure that's quite right. On Debian-based systems, at least, -g changes the initial login group of the user - the group in which files are created by default. -G changes the list of supplementary groups. By default, -G will overwrite the supplementary list (but not touch the initial login group); with the -a flag, it appends.

Oh, you know that very well might be why I use -a some distros but not others. Some systems I would have only needed the user to be in one secondary group and others I would have wanted multiple secondary groups. So in some cases -G was the append but in others I would have had to use -a -G.
Maybe it's not inconsistent after all... I guess I've got some man page reading to do.

Posted: **Sat Aug 22, 2015 2:44 pm**

Depending on the environment variables that are (not) filtered by sudo, you may find that you can open graphical applications launched through sudo, but as X doesn't provide application separation they could use X/dbus to cause havoc (eg. sending evil keypresses to a terminal window).

A solution which allows you to run slave programs in your current xserver screen would be to run with ssh -X slave@localhost program (have the setup script add your pubkey to its authorized_keys). IMHO that provides a nicer experience than changing X desktops (albeit it's safer). Note however that X will only differenciate between privileged and unprivileged, so several GUI programs running on your X server under different slaves could communicate (or interfere) with each other through xorg.

The best solution would probably involve running the new program as a root window in a xephyr which lives inside your current session.

Posted: **Sat Aug 22, 2015 10:16 pm**

Ángel wrote:The best solution would probably involve running the new program as a root window in a xephyr which lives inside your current session.

Can you please elaborate on this?

InformAction Forums

Linux slave accounts

Linux slave accounts

Re: Linux slave accounts

Re: Linux slave accounts

Re: Linux slave accounts

Re: Linux slave accounts

Re: Linux slave accounts

Re: Linux slave accounts

Re: Linux slave accounts

Re: Linux slave accounts

Re: Linux slave accounts

Re: Linux slave accounts

Re: Linux slave accounts

Re: Linux slave accounts

Re: Linux slave accounts

Re: Linux slave accounts