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

1733–1734

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

1761

1785

This and the previous sentence are partly redundant.

1787

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

1802

either add a comma or "by" before executing.

1910

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

258–259

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

74

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

145–146

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.

422

Possibly mention freebsd-update IDS here?

500

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

117

It has not yet been removed.

145–146

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

2085

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

117

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.

422

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

622–623

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

632

Removed, np :)

696

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

701

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.

708

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

712

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

722

Same, not enabled by default :(

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

1353

hehehe, spanish word, sorry

1611

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

1733–1734

hahahaha, best comment ever ;)

2085

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

74

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

117

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

74

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

106

"Security Accounts" sounds strange. Securing Accounts?

108–110

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

278

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

288

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

357–359

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

366

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

381

maybe "ported from OpenBSD"?

422

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

422

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

442

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

541

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?

570–574

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

633–634

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

644–645

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"

687

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

696

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

704

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

704–705

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

704–705

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

718–720

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...]"

722

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

728

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

806–809

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

812

#MaxAuthTries 6

indicates default is 6

817–818

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.

818

PermitEmptyPasswords already defaults to no

840

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

860

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

869

it can also be used for bencmarking the crypto routines

1242

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

1242

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

1244–1249

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

1245

what other layers?

1310–1312

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

opened D41921 for that

1352

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

1569–1573

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

74

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

288

Done in a TIP section

704–705

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

718–720

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

806–809

Removed then :)

812

Also removed.

818

Removed :)

1244–1249

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

1244–1249

Removed # sysrc inetd_flags="-Ww"

1245

I removed the paragraph.

1569–1573

Done!

[carlavilla]

Fix @emaste comments

[emaste]

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

1244–1249

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