Removing unneeded system accounts for jail

Beeblebrox

Beeblebrox

I'm setting up some jails for private use (no remote management). The jails will run services like tor and privoxy, each in its individual jail, and each jail will run one service only. For maximum security I would like to delete the unnecessary user accounts, but will add the necessary user required by each service later. The list below is what I have come up with. Please remark on whether some of the accounts are needed or if there is any other account I could remove.

USERS REMAINING
Code: 
root:*:0:0:Charlie &:/root:/bin/csh
daemon:*:1:1:Owner of many system processes:/root:/usr/sbin/nologin
bin:*:3:7:Binaries Commands and Source:/:/usr/sbin/nologin
tty:*:4:65533:Tty Sandbox:/:/usr/sbin/nologin
kmem:*:5:65533:KMem Sandbox:/:/usr/sbin/nologin
uucp:*:66:66:UUCP pseudo-user:/var/spool/uucppublic:/usr/local/libexec/uucp/uucico
sshd:*:22:22:Secure Shell Daemon:/var/empty:/usr/sbin/nologin
hast:*:845:845:HAST unprivileged user:/var/empty:/usr/sbin/nologin
nobody:*:65534:65534:Unprivileged user:/nonexistent:/usr/sbin/nologin

USERS BEING CONSIDERED FOR DELETION
Code: 
man:*:9:9:Mister Man Pages:/usr/share/man:/usr/sbin/nologin
bind:*:53:53:Bind Sandbox:/:/usr/sbin/nologin
unbound:*:59:59:Unbound DNS Resolver:/var/unbound:/usr/sbin/nologin
proxy:*:62:62:Packet Filter pseudo-user:/nonexistent:/usr/sbin/nologin
_pflogd:*:64:64:pflogd privsep user:/var/empty:/usr/sbin/nologin
_dhcp:*:65:65:dhcp programs:/var/empty:/usr/sbin/nologin
www:*:80:80:World Wide Web Owner:/nonexistent:/usr/sbin/nologin
operator:*:2:5:System &:/:/usr/sbin/nologin
auditdistd:*:78:77:Auditdistd unprivileged user:/var/empty:/usr/sbin/nologin

USERS DELETED:
Code: 
toor:*:0:0:Bourne-again Superuser:/root: (jail is on local machine with full acces from host side)
games:*:7:13:Games pseudo-user:/usr/games:/usr/sbin/nologin
news:*:8:8:News Subsystem:/:/usr/sbin/nologin
smmsp:*:25:25:Sendmail Submission User:/var/spool/clientmqueue:/usr/sbin/nologin
mailnull:*:26:26:Sendmail Default User:/var/spool/mqueue:/usr/sbin/nologin
pop:*:68:6:Post Office Owner:/nonexistent:/usr/sbin/nologin
 
Re: Removing unneded system accounts for jail

Why delete them if the accounts are disabled in the first place? I can not come up with any convincing argument why deleting those accounts would increase security in any way.
 
Re: Removing unneded system accounts for jail

Why delete them if the accounts are disabled in the first place?
Click to expand...
OK KPA @kpa, I can lock them also:
Code: 
games:*LOCKED**:7:13::0:0:Games pseudo-user:/usr/games:/usr/sbin/nologin

The question persists: which accounts can I then lock? Handbook 14.4 (I feel like I'm quoting from the Bible: "And say unto them ..."):
nobody is the generic unprivileged system user. However, it is important to keep in mind that the more services that use nobody, the more files and processes that user will become associated with, and hence the more privileged that user becomes.
Click to expand...

While auto-starting services are explicitly disabled in the jail/etc/rc.conf (example:
Code: 
sendmail_enable="NO"
), I would feel better if I disable unneeded system accounts.

P.S. I have yet to come across a complete list of service names and how to disable them in rc.conf for those services that are included in base/world.
 
Last edited by a moderator:
Re: Removing unneded system accounts for jail

P.S. I have yet to come across a complete list of service names and how to disable them in rc.conf for those services that are included in base/world.
Click to expand...

# service -e should give you a list of the rc scripts that will be run on startup. If you can see anything obvious in that list that you want to disable, it should be fairly straight forward to find the relevant rc.conf setting. On a base system, there isn't really much running that isn't needed.
 
Re: Removing unneded system accounts for jail

service -e should give you a list of the rc scripts that will be run on startup
Click to expand...
I know that, but my problem is about disabling code for each service. There's some information pollution about how to do that. For example, to disable Sendmail, I have all of these, while logically just one should suffice.
Code: 
sendmail_enable="NO"
sendmail_submit_enable="NO"
sendmail_outbound_enable="NO"
sendmail_msp_queue_enable="NO"

I'm also in the tinfoil hat mindset lately, so please humor me :p
 
Re: Removing unneded system accounts for jail

Sorry, the wording of your question suggested that you were after a way to audit enabled services. Disabling them is fairly straightforward in 99% of cases - just scan /etc/defaults/rc.conf for the relevant knob and add it to /etc/rc.conf.

Granted, Sendmail is a particularly annoying one. Last time I checked the network reachable Sendmail service was disabled by default, but it still runs a local delivery agent as it assumes you want local services (cron/periodic/etc.) to be able to submit emails and actually have them delivered successfully. The following should switch it off completely:

Code: 
sendmail_enable="NONE"

Edit: Just to make it clear, unless you are adding a different mailer, this will actually stop anything on your system being able to send you an email. This is why "NO" doesn't actually mean "NO" when it comes to Sendmail, Sendmail is the base system's way of sending emails.

It would maybe make more sense if "NO" meant disable completely, in line with all other services, and Sendmail had a special
Code: 
sendmail_enable="LOCAL"
option to provide local facilities only (which would be default)?
 
Re: Removing unneded system accounts for jail

scan /etc/defaults/rc.conf for the relevant knob
Click to expand...
Yes, that will work!

Sendmail service was disabled by default, but it still runs a local delivery agent as it assumes you want local services (cron/periodic/etc.) to be able to submit emails and actually have them delivered successfully.
Click to expand...
You have heard of the Cockroach Theory in management, right? For every bug you find, there are 10 or 20 (your guess as to the number) problems which have yet to present themselves. The same goes for operational problems in corporations and organizations. Well that's my rant for the day, and hence, my tinfoil hat paranoia.

Thank you for the input and ideas (both @kpa and @usdmatt).
 
Last edited by a moderator:
Well, the mentioning of tinfoil kind of triggered this reaction...

Why stop here? In my opinion removing is even better than disabling. For example; there are several options which I don't use in Apache, for example the user directory, DAV fs, etc. So I don't merely settle for not loading the modules in my configuration, I start by making sure that those don't end up on my system in the first place, this fully rules out the possibility that they may end up in my configuration anyway.

In my opinion this is no different (but it takes a little more effort).

Check the src.conf(5) manual page. Don't want sendmail to be present on your system? Rebuild it while defining the option WITHOUT_SENDMAIL or maybe even WITHOUT_MAIL in /etc/src.conf. The possibilities are endless; I'm taking care of updates myself using the source tree. Therefore I want to make sure that no one, including myself, can accidentally mess with freebsd_update. And what do you know: WITHOUT_FREEBSD_UPDATE.

When it comes to securing or optimizing your base system I really think you should consider to tune and build your base system yourself. Heck; this doesn't even have to involve your main OS, you could simply build a whole userland just for your jail.

That's what I'm experimenting with right now; I'm currently building a "BSD only" jail; an environment without anything GNU related (enter the WITHOUT_GNU or perhaps better WITHOUT_GNU_SUPPORT).

Edit:

I forgot to mention (I just discovered this myself today): If you're interested in this approach then be sure to look into the SRCCONF build option as well (see src.conf(5) and optionally build(7)). This allows you to specify a different src.conf styled file. The advantage is that you can specify build options which won't affect your main system. Something I consider to be ideal for building jails.
 
@ShelLuser: For your benefit, I am sharing my /etc/src.conf. It was one of the first things I set up when I started using FreeBSD.

Code: 
WITHOUT_ACCT= yes
WITHOUT_ASSERT_DEBUG= yes
WITHOUT_BLUETOOTH= yes
WITHOUT_CVS= yes
WITHOUT_FLOPPY= yes
WITHOUT_FREEBSD_UPDATE= yes
WITHOUT_GDB= yes
WITHOUT_HTML= yes
WITHOUT_INET6= yes
WITHOUT_INET6_SUPPORT= yes
WITHOUT_IPFILTER= yes
WITHOUT_IPFW= yes
WITHOUT_MAIL= yes
WITHOUT_PORTSNAP= yes
WITHOUT_SENDMAIL= yes
WITHOUT_SVNLITE= yes
WITHOUT_WIRELESS= yes
WITHOUT_WPA_SUPPLICANT_EAPOL= yes

.include "/etc/make/modex.conf"

# These have been tried. If you set these, you risk braking port builds
#WITHOUT_NLS= yes
#WITHOUT_NLS_CATALOGS= yes
#WITH_BSD_GREP= yes

What is modex.conf, you ask? Search through /usr/src/sys/dev for all the extra modules you do not need on your system and list them in a separate file like below. The "exclude modules list" will allow for faster buildworld (by not building the unnecessary modules).
Code: 
WITHOUT_MODULES= aac acpi/acpi_asus acpi/dock \

enter the WITHOUT_GNU or perhaps better WITHOUT_GNU_SUPPORT
Click to expand...
I would advise against that, as certain port compiles may break. It's too early to implement, unless you have a thing for banging your head against a variety of hard objects.

The only thing I have not gotten around to, is finding how to specify a different src.conf for the # ezjail-admin update -i command. There are a number of components in base I would like to NOT install into jails (not because of security, just unnecessary usage of disk space; and yes, I do have zfs-dedup ON).

@fonz: The Holy Hand Grenade of Antioch is no joking matter. We will not tolerate blasphemy on this forum!
 
Last edited by a moderator:
Beeblebrox said:
@ShelLuser: For your benefit, I am sharing my /etc/src.conf. It was one of the first things I set up when I started using FreeBSD.
Click to expand...
Cool, thanks for that.

It seems great minds do think alike indeed, your options and mine are quite similar. Apart from some specific entries of course, for example I want ACCT to be present on my system, I even added those options to my kernel.

Beeblebrox said:
What is modex.conf, you ask? Search through /usr/src/sys/dev for all the extra modules you do not need on your system and list them in a separate file like below. The "exclude modules list" will allow for faster buildworld (by not building the unnecessary modules).
Click to expand...
Actually, no, I wasn't asking ;) (couldn't resist :beergrin)

Interesting approach. I also keep my modules to a minimum, but in order to do so I simply tell my system to only build a small subset by adding this line to my /etc/make.conf:

Code: 
MODULES_OVERRIDE=zfs opensolaris smbfs libiconv libmchain
Having said that I'm most certainly going to dive into your approach a little more as well, it looks quite interesting too.

Beeblebrox said:
ShelLuser said:
enter the WITHOUT_GNU or perhaps better WITHOUT_GNU_SUPPORT
Click to expand...
I would advise against that, as certain port compiles may break. It's too early to implement, unless you have a thing for banging your head against a variety of hard objects.
Click to expand...
Thanks for the warning, but I'm covered. As mentioned this is for usage in a Jail and that's a place where nothing gets compiled on my systems. The only way it can apply certain updates is through binary packages which have been built and provided on my (dedicated) testing server.

I can't help you with the ezjail issue because I've been administering all my jails by hand so far. Well, by hand and a bit of scripting of course.

Beeblebrox said:
@fonz: The Holy Hand Grenade of Antioch is no joking matter. We will not tolerate blasphemy on this forum!
Click to expand...
Ni! :e

PS: It's threads like these which make this an awesome place to participate on!
 
Last edited by a moderator:
French-Monty-Python-Holy-Grail-French-taunt.jpg
 
ShelLuser said:
Cool, thanks for that.

It seems great minds do think alike indeed, your options and mine are quite similar. Apart from some specific entries of course, for example I want ACCT to be present on my system, I even added those options to my kernel.


Actually, no, I wasn't asking ;) (couldn't resist :beergrin)

Interesting approach. I also keep my modules to a minimum, but in order to do so I simply tell my system to only build a small subset by adding this line to my /etc/make.conf:

Code: 
MODULES_OVERRIDE=zfs opensolaris smbfs libiconv libmchain
Having said that I'm most certainly going to dive into your approach a little more as well, it looks quite interesting too.


Thanks for the warning, but I'm covered. As mentioned this is for usage in a Jail and that's a place where nothing gets compiled on my systems. The only way it can apply certain updates is through binary packages which have been built and provided on my (dedicated) testing server.

I can't help you with the ezjail issue because I've been administering all my jails by hand so far. Well, by hand and a bit of scripting of course.


Ni! :e

PS: It's threads like these which make this an awesome place to participate on!
Click to expand...
You know it's illegal to install spyware on someone's devices without consent right? I know you have an obsession with the word "hand" for some odd reason.

you must be friends with this fine man
1709842257913.png
 
You must log in or register to reply here.
Back
Top