Handbook WG - Security

[carlavilla]

Summary

Rework the Security chapter.

Changes:

• Rework the Security Accounts section and put in there the sudo/doas section
• Rework the Intrusion Detection System using mtree
• Add new Secure levels section
• Add new File flags section
• Rework OpenSSH section
• Rework OpenSSL section
• Upgrade Access Control Lists section and add info about NFSv4 ACLs
• Add capsicum section with a brief introduction and a naive example
• Upgrade resource limits section
• Upgrade FreeBSD Security Advisories section showing a current report

Removed VPN over IPSec, I think this fits better in a separated article (new article) or in the network services chapter.

Output:

https://people.freebsd.org/~carlavilla/handbook-wg/security.html
https://people.freebsd.org/~carlavilla/handbook-wg/vpn-ipsec-article.html

[• karels]

documentation/content/en/books/handbook/security/_index.adoc

1473–1474

remove "that want" (classes don't want things)

1501

1525

This and the previous sentence are partly redundant.

1527

s/need/needs/, or s/need to/must/

1543

either add a comma or "by" before executing.

1651

The final "mailing lists" looks redundant when the list links are expanded. I'd just remove it.

[• karels]

documentation/content/en/books/handbook/security/_index.adoc

253–254

That was "reparse" not "repairs" before the spell autocorrect got it.

[philip]

documentation/content/en/books/handbook/security/_index.adoc

6–7

We do use Kerberos in the cluster.

While our primary means of identifying committers is SSH keys, we use Kerberos for services that require a password: Bugzilla and SMTP. In principle, things like Phabricator and the wiki could/should also authenticate against Kerberos but they don't for Hysterical Raisins.

[philip]

documentation/content/en/books/handbook/security/_index.adoc

87

Is there a separate article on IPSEC we can link to? That's still (very) relevant too.

160–161

I would remove mention of DES and MD5 here. While they are supported, they are strongly discouraged. Perhaps simply write "several algorithms (e.g. SHA256, SHA512, and Blowfish)" so this article remains accurate when we eventually add others.

408–410

Possibly mention freebsd-update IDS here?

488

We should really not be encouraging md5 or sha1 in 2023. The original example had sha256 digests. Can we update the current example accordingly?

[emaste]

documentation/content/en/books/handbook/security/_index.adoc

138

It has not yet been removed.

160–161

or "several algorithms, including SHA256, ..."

1826

Note that SAs still include Subversion details, as long as 12.x is supported.

[carlavilla]

Fixed some issues, I'm gonna upgrade the diff right now.

documentation/content/en/books/handbook/security/_index.adoc

138

Well, although the user toor has not been deleted yet, I like the idea that Ed has proposed, so we can save ourselves problems in the future when the user has been deleted.

408–410

I thought about putting it, but since the "final" idea is to remove freebsd-update I didn't put it

616–617

hmm, can you please provide a little paragraph with this info please?

628

Removed, np :)

701

TBH, no idea, maybe @emaste or @philip can help us.

706

FreeBSD marks it as enabled by default in the installer and the user decides if they _don't_ want it.
But by default, yes, you're right, it is enabled.

726

Sorry, wrong config property, and it's not enabled by default

750

No, seems not enabled by default (taken from the git repo https://cgit.freebsd.org/src/tree/crypto/openssh/sshd_config):

#LoginGraceTime 2m
#PermitRootLogin no
#StrictModes yes
#MaxAuthTries 6
#MaxSessions 10

752

Same, not enabled by default :(

https://cgit.freebsd.org/src/tree/crypto/openssh/sshd_config

1269

hehehe, spanish word, sorry

1357

hmmm, can you please provide a paragraph to replace this one?

1473–1474

hahahaha, best comment ever ;)

1826

I've restored it, but we're a few months from the end of Subversion, I'll be back in the future to remove the reference.

[carlavilla]

documentation/content/en/books/handbook/security/_index.adoc

6–7

Ok, I restored the kerberos section, can you please take a look and tell me if there's something wrong?
To have a more pleasant reading, you can check it here https://docs.freebsd.org/en/books/handbook/security/#kerberos5

87

I just added it as an article, it's exactly the same as what we have now, you can check it out here: https://docs.freebsd.org/en/books/handbook/security/#ipsec

[emaste]

documentation/content/en/books/handbook/security/_index.adoc

138

Note that the toor example has been removed in main already in 70fec4c1c5799844f2269aade3e558535e3d2e79, so maybe this is a diff from an older commit?

[emaste]

documentation/content/en/books/handbook/security/_index.adoc

87

Aside, we should also have OpenVPN (DCO) and WireGuard docs.

119

"Security Accounts" sounds strange. Securing Accounts?

121–123

This seems overly verbose, probably only needs to be a sentence or two.

273

Should probably be a date in the future but not so far that it seems unreasonable.

283

True, but even administrators should limit their privileges when not needed, so we probably want to make reference to that concept as well.

347–350

Simpler: "This avoids sharing passwords, which is a poor practice."

357

I'm not sure how 2FA factors in, we probably just want to say "Sudo can be configured to permit ... by using NOPASSWD".

371

maybe "ported from OpenBSD"?

408–410

I think it's useful to leave "basic" or something similar in -- running mtree(8) can be useful but is fairly minimal.

408–410

that's true but freebsd-update will persist for at least 14 so I think it would be fine to include.
once we finally deprecate it we'll have to sweep the tree for freebsd-update references so it wouldn't be left behind accidentally

430

that's the same combination I have on my luggage!

it's certainly easier to match with later examples than 3483151339707503. we might want to add something like "represents the seed, and should be chosen randomly..." below

539

but now the user has a /bin/cat which doesn't match the mtree spec they've saved away, and would always get this complaint

maybe mention that we're presenting this as an example of what would be observed with a metadata change but suggest the user not do it on their real system?

or make a longer example starting with making a /tmp/mtree-experiment directory or so?

564–568

we should explain what is different between "permanently insecure mode" and "insecure mode"

629

More concise: File flags allow users to attach additional metadata or attributes to files and directories beyond basic permissions and ownership.

638

I don't think we need to repeat this right away, the above text is only a few sentences ago :)

672

more concise: remove "effectively"

689

We should provide some comment on choosing one or the other.

Maybe

As stated, this chapter will cover the base system version of OpenSSH. A version of OpenSSH is also available from the security/openssh-portable port or package, which ..."

but I'm not quite sure what to say about it. it may provide additional (configuration) options, and from time to time may be more up-to-date than the one in base

701

I think the text moved around, what does "this" refer to?

721

we should add a note about verifying the host key out of band

738–739

We should mention that public key auth is preferred over passwords.

741

strike "RSA"
also default key type is changing to ed25519
we should also describe FIDO security keys, however I'm fine with getting this document into the tree and iterating on it there

752

I'd rather avoid a telnet example. Maybe a http example of something like 8080:localhost:80

753–755

I would avoid this first sentence, probably just say something like "Keys should be protected by a passphrase. Using a key without a passphrase is dangerous[, because...]"

757

Start a new section for "from"
Also should explain authorized_keys for this.

866–870

It's not necessary to uncomment that line - the comments in sshd_config show the defaults, so

#PermitRootLogin no

indicates that root login is already not permitted by default. If you wanted root login you would need to change it to

#PermitRootLogin without-password

or

#PermitRootLogin yes

Note that OpenSSH upstream has without-password as the default, no is a change in FreeBSD's base system sshd

874

#MaxAuthTries 6

indicates default is 6

882–883

PubkeyAuthentication defaults to yes, so we should probably rephrase this. Mention that both pubkey and password authentication are enabled by default. To allow *only* pubkey (recommended), change

Note also that PasswordAuthentication defaults to no. By default passwords are handled via ChallengeResponseAuthentication and PAM. To disable passwords both must be no.

883

PermitEmptyPasswords already defaults to no

883

maybe "recommended" to verify? otherwise it may imply that it will not function without sshd -t

911

libcrypto is part of openssl and provides a lot of stuff
instead of "related cryptography standards required by them" I would use something like "and many cryptography routines" or something like that

921

it can also be used for bencmarking the crypto routines

1187

I think we should just call it "TCP wrappers" everywhere

1187

more concise: "TCP Wrappers is a host-based network access control system."

1188–1192

yes for inetd-based services, but tcp wrappers are also used by e.g. sshd and do not involve inetd.

note that inetd_flags includes Ww by default

1190

what other layers?

1230–1231

we should not document/encourage this support and should remove it from our tcp wrapper implementation

opened D41921 for that

1269

complexity may be unavoidable, but careful planning is required to ensure that the desired security properties are being provided

1309–1315

I'm not sure that too much detail about Capsicum belongs in the handbook. This introduction is good, but Capsicum details are only of use to application developers. So I would leave out the C source examples.

[carlavilla]

documentation/content/en/books/handbook/security/_index.adoc

87

Yes, the idea of moving it to an article is to later add WireGuard, etc. to that article

283

Done in a TIP section

741

Ok, I'll add the FIDO security keys after the 4th version of the handbook is done

753–755

I write it again, I think right now it's better :)

866–870

Removed then :)

874

Also removed.

883

Removed :)

1188–1192

So, instead of "To enable TCP Wrapper in FreeBSD, execute :" put "To enable TCP Wrappers in FreeBSD for inetd execute:"?

1188–1192

Removed # sysrc inetd_flags="-Ww"

1190

I removed the paragraph.

1309–1315

Done!

[carlavilla]

Fix @emaste comments

[emaste]

documentation/content/en/books/handbook/security/_index.adoc

1188–1192

Well, tcp wrappers is enabled by default in some 3rd party software (e.g. sshd) and by default in inetd, so there's no specific step that needs to be taken to "enable" it. We could mention that TCP Wrappers support is built-in to some applications (like sshd) and enabled by default settings for inetd.

[carlavilla]

Fix last comment from @emaste