# System Hardening



## Deather (Jul 30, 2020)

Is there a FULL cheat sheet for rc.conf sysctl.conf etc..? I would like to review all the things I might need. Thanks <3

Edit: Thank you guys so much for the useful replies and if anyone would like to add more ideas let me know! <3


----------



## vmb (Jul 30, 2020)

I am not aware of such a cheat sheet.
However, install lynis

```
#pkg install -y lynis
```
Then run

```
#lynis audit system -Q
```
That should give you a starting point for sysctl.conf and others


----------



## Deather (Jul 30, 2020)

Yes, Lynis is a great tool but it doesn't tell you a whole lot. Like yes it tells you one like security.bsd.hardlink_check_gid=1 but is there other security.bsd ones?


----------



## Alain De Vos (Jul 30, 2020)

Good question. For security I find some info here, some info there, use a package like lynis. Centralized info i did not found.
sysctl.conf depends largely on your personal usage. So there is nothing general.


----------



## T-Daemon (Jul 30, 2020)

Here are some hardening tuneables for /boot/loader.conf, /etc/rc.conf, /etc/sysctl.conf, /etc/ttys listed.

man security(7) has instructions how to secure (harden) the system.

Or go direct to HardenedBSD, "a security-enhanced fork of FreeBSD. The HardenedBSD Project is implementing many exploit mitigation and security technologies on top of FreeBSD."

Here the wiki:








						Sign in
					

HardenedBSD GitLab




					git-01.md.hardenedbsd.org


----------



## rootbert (Jul 30, 2020)

also: FreeBSD - a lesson in poor defaults: https://vez.mrsk.me/freebsd-defaults.html


----------



## Mjölnir (Jul 30, 2020)

We can make this thread the start for a wiki page.  My contribution:

traditionally the _staff_ group is used for developers & such, and these have reason to see a full process list. Thus I have mac_seeotheruids(4) in sysctl.conf(5)

```
kern.randompid=1
#security.bsd.see_other_uids=0
security.bsd.see_jail_proc=0
# see also rc.conf kld_load="${kld_load} mac_seeotheruids". id staff=20
security.mac.seeotheruids.specificgid=20
security.mac.seeotheruids.specificgid_enabled=1
kern.random.fortuna.minpoolsize=512
```

You may want to reflect if your security needs justify to use a file system firewall (ugidfw(8), mac_bsdextended(4)) or any of the other MAC policies (local doc).
Fixing CPU bugs is mandatory: install sysutils/cpupdate & sysutils/devcpu-data
Enable the predefined ipfw firewall: `sysrc firewall_enable=YES` `sysrc firewall_type=workstation`
Does s/o have a good comparision of the available IDS in ports?


----------



## George (Jul 30, 2020)

Who is the attacker?^^
There is security(7), and https://www.freebsd.org/doc/handbook/security.html, but..


----------



## Deather (Jul 30, 2020)

G


Elazar said:


> Who is the attacker?^^
> There is security(7), and https://www.freebsd.org/doc/handbook/security.html, but..


Governemnt agencies. As I will use it for "Pentesting".


----------



## Mjölnir (Jul 30, 2020)

Additionally, you can enable various security related checks in periodic.conf(5). RTFM & RTSL UTSL /etc/defaults/periodic.conf


----------



## Deather (Jul 30, 2020)

Alain De Vos said:


> Good question. For security I find some info here, some info there, use a package like lynis. Centralized info i did not found.
> sysctl.conf depends largely on your personal usage. So there is nothing general.


I only need the base install, my custom program, and internet  So do you have any ideas for that configuration?


----------



## Mjölnir (Jul 30, 2020)

What's the attack surface? To mitigate access to the ME & any OOB management, you need an external packet filter.  Check the base like said above (+`freebsd-update IDS`) & enable the _workstation_ firewall, if needed configure it to allow access to your program.  With the additions found throughout this thread you have a pretty good basic host security.  Choose a strong password & change it regularly.


----------



## Deather (Jul 30, 2020)

mjollnir said:


> What's the attack surface? To mitigate access to the ME & any OOB management, you need an external packet filter.  Check the base like said above (+`freebsd-update IDS`) & enable the _workstation_ firewall, if needed configure it to allow access to your program.  With the additions found throughout this thread you have a pretty good basic host security.  Choose a strong password & change it regularly.


I will be making a firewall in hardware aswell etc.. I will take to the extreme and I will even strip FreeBSD down to the point where it is almost impossible to use for any other use than it was intended. Which is pentesting using my program. Though I will have multiple firewalls and I couldn't get Tor to work with pf. If you know a firewall for Tor please let me know, and not just pf, ipfw and all the built in firewalls would be appreciated <3 Sorry for asking alot.


----------



## Mjölnir (Jul 30, 2020)

Then you already know about nanobsd(8) & picobsd(8).  What do you mean with _"a firewall for tor(1)"_?  Traditionally, you have an external packet filter (single, extra phys. system _solely_ for that purpose) & application gateway in a DMZ which you can set up as a collection of jailed proxies (SOCKS, HTTP, DNS, NTP, ...).  There's a security/torsocks & net/tsocks to _socksify_ any application.  Nowadays you need to inspect the data streams, which is a topic of it's own.  So you want to pentest another host or network, and your program is doing that?  Then why do you want to harden _that_ system?


----------



## Deather (Jul 30, 2020)

mjollnir said:


> Then you already know about nanobsd(8) & picobsd(8).  What do you mean with _"a firewall for tor(1)"_?  Traditionally, you have an external packet filter (single, extra phys. system _solely_ for that purpose) & application gateway in a DMZ which you can set up as a collection of jailed proxies (SOCKS, HTTP, DNS, NTP, ...).  There's a security/torsocks & net/tsocks to _socksify_ any application.  Nowadays you need to inspect the data streams, which is a topic of it's own.  So you want to pentest another host or network, and your program is doing that?  Then why do you want to harden _that_ system?


During a pentest it is also good for the blue team to attack back at the red team in certain cases. Trying to deanonymize the users such as the fbi did with javascript once. I can't use the pkg system for reasons so is there a way to do something like proxychains or torsocks without actually having the program, perhaps a .sh? Also I'm a grey hat "exploiter" so when I say pentest I don't always do good. Sorry if you are dissapointed.


----------



## Mjölnir (Jul 31, 2020)

Deather said:


> During a pentest it is also good for the blue team to attack back at the red team in certain cases. Trying to deanonymize the users such as the fbi did with javascript once. I can't use the pkg system for reasons so is there a way to do something like proxychains or torsocks without actually having the program, perhaps a .sh? Also I'm a grey hat "exploiter" so when I say pentest I don't always do good. Sorry if you are dissapointed.


No, not at all.  tsocks(1) is a shell script.  It might serve as a start for your purpose.  But since you can't use packages, I'll assume you don't have _root_ privileges & you need to download some library into your $HOME to be available for your script.  Where we have a topic that was forgotten not explicitely mentioned until now: mount(8) options.  If the place where you can install your library or script has _noexec_ mount options, you're out if you can't find any suitable substitute on the machine.  Still not shure if this is valuable input for you.
Browse _/usr/ports/security_.  Have to leave, bye & good luck.


----------



## mark_j (Jul 31, 2020)

Deather said:


> Is there a FULL cheat sheet for rc.conf sysctl.conf etc..? I would like to review all the things I might need. Thanks <3
> 
> Edit: Thank you guys so much for the useful replies and if anyone would like to add more ideas let me know! <3


Simple really. Remove everything in rc.conf and don't allow users. System hardening completed.


----------



## George (Jul 31, 2020)

> Government agencies.


Encrypt your hard disk. And do it well.^^


----------



## Mjölnir (Jul 31, 2020)

mark_j said:


> Simple really. Remove everything in rc.conf and don't allow users. System hardening completed.


And cut/unplug every network connection.  On a ZFS machine, blank out loader.conf(5), too.  Information added: zero.


----------



## olli@ (Jul 31, 2020)

To make a computer really secure, switch it off, remove all cables and physically destroy all storage devices, and bury it 5 feet deep in concrete. And even then I wouldn’t be 100 % sure …


----------



## Deather (Jul 31, 2020)

Elazar said:


> Encrypt your hard disk. And do it well.^^


My encryption passwords are hundreds of chars long. Root passwords are 20.


----------



## SirDice (Jul 31, 2020)

Deather said:


> My encryption passwords are hundreds of chars long. Root passwords are 20.


That won't prevent anyone from circumventing them if they have local access to the machine.


----------



## Mjölnir (Jul 31, 2020)

Deather So did you find s/th?  What is your route?  Just curious, as I guess you're doing this pentesting in a professional environment (you wrote about two teams), and then you ought to have some good background on security & network, but maybe just lacking experience in FreeBSD.


----------



## Mjölnir (Jul 31, 2020)

SirDice said:


> That won't prevent anyone from circumventing them if they have local access to the machine.


Obviously you can e.g. reset the (most) machine & boot from external media, but how would you circumvent the password/key to access encrypted data?  Especially if it's two tokens, i.e. a key on a thumb drive or smartcard plus a password or fingerprint via sensor?  Then there are these One-Time-Passwords.


----------



## George (Jul 31, 2020)

There are 400-500 people with source commit bit (the list is in the Developers handbook). How do you know that none of them was ever approached by a government agency, offering money for a backdoor?


----------



## SirDice (Jul 31, 2020)

mjollnir said:


> but how would you circumvent the password/key to access encrypted data?


You're right. That was my dyslexia interfering, and trying to do different things at the same time. That caused me to miss the encrypted part.


----------



## olli@ (Jul 31, 2020)

Elazar said:


> There are 400-500 people with source commit bit (the list is in the Developers handbook). How do you know that none of them was ever approached by a government agency, offering money for a backdoor?


Let me say two things: “open source” and “peer review”.


----------



## Mjölnir (Jul 31, 2020)

As long you keep on posting unencryted, that's perfectly ok... Man, dyslexia, freudian associations to BDSM, what comes next?


Elazar said:


> There are 400-500 people with source commit bit (the list is in the Developers handbook). How do you know that none of them was ever approached by a government agency, offering money for a backdoor?


Much of this stuff related to security is a matter of _trust_.  E.g. `freebsd-update IDS`: who checks the keys visually to prevent a _man-in-the-middle attack_?  Who uses a verified checking tool from authorized media (else the keys can look ok but the tool is compromized)?  I can only trust that the relevant parts of the source code  are beeing conscientiously peer-reviewed and do what they're documented to do.  And then, still there will be bugs.  Remember the OpenSSL fiasko of Debian & derived distros.


----------



## SirDice (Jul 31, 2020)

mjollnir said:


> Man, dyslexia, freudian associations to BDSM, what comes next?


AD/HD doesn't make things better either.


----------



## Deather (Jul 31, 2020)

SirDice said:


> That won't prevent anyone from circumventing them if they have local access to the machine.


I've got ideas for that one.


----------



## Alain De Vos (Jul 31, 2020)

For the one who is inteterested my sysctl.conf, security part

```
#General
kern.randompid=1
security.bsd.see_other_uids=0            #Unprivileged processes may not see subjects/objects with different real uid
security.bsd.see_other_gids=0            #Unprivileged processes may not see subjects/objects with different real gid
security.bsd.see_jail_proc=0             #Unprivileged processes may not see subjects/objects with different jail ids
security.bsd.unprivileged_read_msgbuf=0  #Unprivileged processes may not read the kernel message buffer
security.bsd.unprivileged_proc_debug=0   #Unprivileged processes may use process debugging facilities
security.bsd.hardlink_check_gid=1        #Unprivileged processes cannot create hard links to files owned by other groups
security.bsd.hardlink_check_uid=1        #Unprivileged processes cannot create hard links to files owned by other users 
security.jail.sysvipc_allowed=0
security.bsd.stack_guard_page=1 #1

#Ip
net.inet6.ip6.use_tempaddr=1
net.inet6.ip6.prefer_tempaddr=1
net.inet.sctp.blackhole=2          
net.inet.udp.blackhole=1           
net.inet.tcp.blackhole=2           
net.inet.icmp.drop_redirect=1              
net.inet.tcp.icmp_may_rst=0
net.inet.ip.maxfragpackets=0     
net.inet.ip.maxfragsperpacket=0 
net.inet.ip.check_interface=1                  
net.inet.ip.process_options=0                   
net.inet.ip.random_id=1                         
net.inet.ip.redirect=0
net.inet.tcp.cc.algorithm=cubic
net.inet.tcp.icmp_may_rst=0

#Adres map randomization
kern.elf32.aslr.pie_enable=1
kern.elf32.aslr.enable=1
kern.elf64.aslr.pie_enable=1
kern.elf64.aslr.enable=1

#Firefox bug
kern.elf64.aslr.stack_gap=0
kern.elf32.aslr.stack_gap=0
```


----------



## Deather (Jul 31, 2020)

mjollnir said:


> As long you keep on posting unencryted, that's perfectly ok... Man, dyslexia, freudian associations to BDSM, what comes next?
> 
> Much of this stuff related to security is a matter of _trust_.  E.g. `freebsd-update IDS`: who checks the keys visually to prevent a _man-in-the-middle attack_?  Who uses a verified checking tool from authorized media (else the keys can look ok but the tool is compromized)?  I can only trust that the relevant parts of the source code  are beeing conscientiously peer-reviewed and do what they're documented to do.  And then, still there will be bugs.  Remember the OpenSSL fiasko of Debian & derived distros.


I'm actually a teenager that loves unix and is more than average with computer exploits. I plan to read the FreeBSD handbook soon but right now i'm trying to improve my spagetti coding . I was giving a example of what I will have to run into perhaps if I were to deal with the wrong person. My goal is to make a operating system based on FreeBSD (Plan on mixing other kernels together) for a private device that will give strong anonymity, a retarded ammount of security that could break the system. But alot of the reasons I don't want to use pkg when doing things is  that I wan't to write all the programs myself for satisfaction and the way it connects to the internet is going to be weird. I have already started programming it. It will have a custom computer based on a raspberry pi zero (Maybe with AMD64 instead) with a hardware firewall that will go into the computer using a microcontroller. And other stuff. I'm creating new ideas as I go and I am crazy about privacy, security and more. Also like elazar said "Governement Backdoors", as far as I am aware because I watched a conference about alot of Snowden document and have a 2gb copy of the files. I have studied all of that stuff. And I know that nothing is hack proof, but the goal is to make it hard to traverse and if they disable things like a firewall they can't because the system will detect any file changes and shutdown quickly and also the hardware firewall can't listen to the pc. Only send data to the pc. Sorry for making this long I try to make my text small and remove things I don't need..


----------



## Mjölnir (Jul 31, 2020)

Deather said:


> I've got ideas for that one.


If you have my laptop, which I secured up to the max, you can simply pull out the battery & CMOS battery, wait an hour or night, and then reset the BIOS, e.g. search the internet for how to disable many parts of the ME & break a stolen machine.  S/t such procedure is even neccessary when you bought a refurbished system.   Older laptops have a hole to stick in a small nail to reset the BIOS.  But that wouldn't be it: just take out the HDD/SSD...  I'm not aware of how to make some machine specific token part of the key, so that the non-volatile storage does only work w/ a specific machine.
Back on topic.  How would you adress perfect forward secrecy, if your opponent uses that?
Alain De Vos , you would easily qualify for the natural HardenedBSD user?


----------



## Mjölnir (Jul 31, 2020)

For you self written IDS FreeBSD has the filemon(4) kernel module, to enhance your online privacy & anonymity see this thread.


----------



## Deather (Jul 31, 2020)

mjollnir said:


> For you self written IDS FreeBSD has the filemon(4) kernel module, to enhance your online privacy & anonymity see this thread.


I am decent with understand networking. But I could have sworn there was a way to use a proxy in the url like 127.0.0.1:8080/google.com or something. But I couldn't find anything like it. If I can do that then I can probably add proxifying to the system rn. As the custom programs all run under the same process for the most part. And it will use os command injection to take some commands away from the machine.


----------



## George (Jul 31, 2020)

Or maybe create a read-only environment?

There are some hints on this here:








						FreeBSD and Solid State Devices
					

The use of solid state disk devices in FreeBSD




					www.freebsd.org


----------



## Alain De Vos (Jul 31, 2020)

In fact "/usr/local" could be a read-only mount except at the moments you do "pkg upgrade".
But you can shoot yourself in the foot by complexity. I don't know a good way to do this
I also don't know how you can have "/" a read-only mount but "/var/tmp" a read-write mount.


----------



## Mjölnir (Jul 31, 2020)

Alain De Vos said:


> In fact "/usr/local" could be a read-only mount except at the moments you do "pkg upgrade".
> But you can shoot yourself in the foot by complexity. I don't know a good way to do this
> I also don't know how you can have "/" a read-only mount but "/var/tmp" a read-write mount.


By putting it on it's own filesystem. Like /tmp in fstab(5): 
`none    /tmp    tmpfs    rw,size=8G,nosuid,noexec,mode=1777,gid=0,uid=0    0    0`
could also be  UFS or ZFS fs.


----------



## Alain De Vos (Jul 31, 2020)

Thanks.
Question on the kernel.
Let's say i remove each of these one by one in my kernel config.
I would not surprise me if compat_freebsd4 has non solved security problems due to it's ancienty.
How far can i go before I run into serious problems ? [ I did not found any info ]


options     COMPAT_FREEBSD4        # Compatible with FreeBSD4
options     COMPAT_FREEBSD5        # Compatible with FreeBSD5
options     COMPAT_FREEBSD6        # Compatible with FreeBSD6
options     COMPAT_FREEBSD7        # Compatible with FreeBSD7
options     COMPAT_FREEBSD9        # Compatible with FreeBSD9
options     COMPAT_FREEBSD10    # Compatible with FreeBSD10
options     COMPAT_FREEBSD11    # Compatible with FreeBSD11


----------



## Deather (Jul 31, 2020)

Elazar said:


> Or maybe create a read-only environment?
> 
> There are some hints on this here:
> 
> ...


That won't work, my program is designed to detect if there's a intrusion by monitoring change dates of files, their contents and size in bytes. So that if they are edited (it will check when the tui starts/boots, it will quickly say what it found and shut down. Then I can reset it.


----------



## Alain De Vos (Aug 1, 2020)

Note as a test i've commented out in the kernel config

```
#options     COMPAT_FREEBSD4        # Compatible with FreeBSD4
#options     COMPAT_FREEBSD5        # Compatible with FreeBSD5
#options     COMPAT_FREEBSD6        # Compatible with FreeBSD6
#options     COMPAT_FREEBSD7        # Compatible with FreeBSD7
#options     COMPAT_FREEBSD9        # Compatible with FreeBSD9
```
Most stuff continue to work perfectly.


----------



## ralphbsz (Aug 1, 2020)

gpb said:


> An individual would be much better off starting with Plan 9.


The real question is what the OPs goals are.

If their goal is to learn programming and how an OS is put together, as a purely academic and skill-building exercise, then I like your suggestion of Xv6; or one could use Tanenbaum's book and Minix.

If they want to learn about computer security, I would say that "learning by doing" just doesn't scale: the problem with learning from one's own mistakes is that one has to make them first, and there is only limited time. There has been an extremely active computer security community, with conferences and journals and textbooks, and one should probably learn by reading all of those. Just as a starting point, Usenix makes proceedings of older conferences available for free, so just start reading all security-related papers from their various conferences, and understand them. Go to college, become a CS major, and sign up for computer security classes (yes, they exist, I know at least UMich and Stanford have specialized programs, or at least had in the past).

But they want to build a custom OS for an appliance that is exceedingly secure, above they refer to it as "a retarded amount of security" and "strong anonymity". They want to rewrite all packages from scratch, because they don't trust other people's coding. They worry about having future run-ins with government agencies, which is why they need this level of protection. In that case, they are already completely screwed. No single individual can build a full-function OS with modern protocol stack that is reasonably secure all alone, it is just way too much work, and requires way too much knowledge and experience. And honestly, there is a reason I made the joke about calibers when asking how he was going to face nation-state adversaries: if you really manage to piss off the big government agencies, a little bit of encryption and closing IP ports won't help against armored vehicles and paramilitary police. Remember the footage from when Kim Dotcom was arrested?

And given what the original poster has written in other threads, it is also possible that they are trying to figure out how to hack into FreeBSD systems; they have pointed out their track record as a hacker, and whether they're a white hat or a black hat isn't obvious to me.

I think in reality the OP is a confused teenager, who doesn't know what they want. In that case, the best advice is to read books, play with the system, learn about it, and stay the heck away from other people's computers.


----------



## mark_j (Aug 1, 2020)

Deather said:


> I'm actually a teenager that loves unix and is more than average with computer exploits. I plan to read the FreeBSD handbook soon but right now i'm trying to improve my spagetti coding . I was giving a example of what I will have to run into perhaps if I were to deal with the wrong person. My goal is to make a operating system based on FreeBSD (Plan on mixing other kernels together) for a private device that will give strong anonymity, a retarded ammount of security that could break the system. But alot of the reasons I don't want to use pkg when doing things is  that I wan't to write all the programs myself for satisfaction and the way it connects to the internet is going to be weird. I have already started programming it. It will have a custom computer based on a raspberry pi zero (Maybe with AMD64 instead) with a hardware firewall that will go into the computer using a microcontroller. And other stuff. I'm creating new ideas as I go and I am crazy about privacy, security and more. Also like elazar said "Governement Backdoors", as far as I am aware because I watched a conference about alot of Snowden document and have a 2gb copy of the files. I have studied all of that stuff. And I know that nothing is hack proof, but the goal is to make it hard to traverse and if they disable things like a firewall they can't because the system will detect any file changes and shutdown quickly and also the hardware firewall can't listen to the pc. Only send data to the pc. Sorry for making this long I try to make my text small and remove things I don't need..


You would be best to buy a beaglebone black, grab minix for arm and hack away.





						developersguide:minixonarm [Wiki]
					






					wiki.minix3.org
				




Attempting to strip down a huge monolithic kernel and OS like FreeBSD to remove all its identity is just madness. You're a teenager now but in 20 years from now while you're still attempting to hit a moving target you might regret your decision.

Minix is extremely well documented from the kernel standpoint. Minix also will support pkgsrc for ARM. Soon. Maybe.
Minix is not monolithic so by design its more secure, but there are drawbacks; performance. Microkernels are such an elegant design IMO.


----------



## olli@ (Aug 3, 2020)

Alain De Vos said:


> In fact "/usr/local" could be a read-only mount except at the moments you do "pkg upgrade".
> But you can shoot yourself in the foot by complexity. I don't know a good way to do this
> I also don't know how you can have "/" a read-only mount but "/var/tmp" a read-write mount.


The /var file system should always be separate from the root file system (/), except maybe for very small (embedded) machines like NanoBSD. Making the root file system read-only is not really much of a problem, you only have to keep in mind that you won’t be able to make changes to files in /etc (you’ll have to enter single-user mode for that).

Alternatively, you can make critical files and directories system-immutable, and run the kernel at an increased security level. See chflags(1), chflags(2) and security(7). This has the additional advantage that raw disk devices cannot be opened for writing, which could otherwise be used to circumvent read-only mounts. Furthermore, it prevents loading of malicious kernel modules that could circumvent various security measures.


----------



## olli@ (Aug 3, 2020)

Alain De Vos said:


> Question on the kernel.
> Let's say i remove each of these one by one in my kernel config.
> I would not surprise me if compat_freebsd4 has non solved security problems due to it's ancienty.


That _would_ surprise me. Note that the `COMPAT_FREEBSD*` options just implement systemcalls compatible with older versions of FreeBSD. That does _not_ mean this is ancient code. When a problem with a systemcall is discovered – no matter if it’s a compatibility systemcall or a regular one – the problem is fixed promptly, of course.


> How far can i go before I run into serious problems ? [ I did not found any info ]


Well, as I mentioned above, those options enable legacy systemcalls used by older binaries. Note that you will also need to install the appropriate `compat*x` port/package that provides libraries and other files needed by such older binaries. One doesn’t work without the other (except maybe statically compiled binaries that don’t require libraries).

You can remove these options without any problems if you don’t have old binaries, i.e. if you use only binaries compiled for your current version of FreeBSD. Then you need neither the above `COMPAT_FREEBSD*` kernel options nor the accompanying `compat*x` package.

Having the `COMPAT_FREEBSD*` option in your kernel is also very valuable when upgrading to a new major version of FreeBSD. That way your installed ports / packages continue to work, and you can upgrade (reinstall) them without pressure. Also, when something goes wrong during the update and your machine ends up with a new kernel but with old userland binaries, you might be in trouble if you don’t have the compatibility option in your kernel.


----------



## Mjölnir (Aug 3, 2020)

Alain De Vos said:


> Thanks.
> Question on the kernel.
> Let's say i remove each of these one by one in my kernel config.
> I would not surprise me if compat_freebsd4 has non solved security problems due to it's ancienty.
> ...


This does not mean there's ancient source code, but only the old _interface_ to system calls.  E.g. the order & type of parameters, name of variables & functions, etc.


----------



## olli@ (Aug 3, 2020)

mjollnir said:


> This does not mean there's ancient source code, but only the _interface_ to system calls.  E.g. the order of parameters, name of variables & functions, etc.


Yes, in particular, a lot of systemcalls have grown larger arguments, for example device numbers where changed from 16bit to 32bit, block counts (of files) where changed from 32bit to 64bit, and so on. That’s why the stat(2) systemcall has gone through several versions during FreeBSD’s evolution. The old compatibility syscalls of stat(2) basically just copy the `struct stat` and change the width of its elements as appropriate, the call the “real” (current) implementation of stat(2).

That’s actually quite similar to what the Linuxulator does. The Linux compatibility shim also translates between systemcalls, changing arguments as necessary. Only in very few cases, when there is no direct FreeBSD equivalent of a certain Linux syscall, it has to do some more work.


----------



## SirDice (Aug 3, 2020)

I already ran into several applications that are still using the pre-12.0 stat(2) structures. Zabbix was one of them. It required enabling COMPAT_FREEBSD11 in the kernel or it would simply fail to get any meaningful data. I found this out the hard way on a 12-STABLE custom kernel that had no COMPAT_* enabled. 

Also note that they are cumulative. So if you enable COMPAT_FREEBSD9, you also need to enable COMPAT_FREEBSD10 and COMPAT_FREEBSD11.


----------



## Alain De Vos (Aug 3, 2020)

I've kept COMPAT_FREEBSD11 and COMPAT_FREEBSD10. Just in case.

On read-only , read-write, of directories and security
You can mount / in ro.

But then you must mount a few directies in rw.
I don't know if I have the complete list , i was thinking.
/tmp
/var
/var/tmp
/root
/usr/home/myuser
- For ease of use:
/usr/local/etc
- Maybe
/etc

Can I put /root or /etc in fstab without running into problems ?


----------

