Page MenuHomeFreeBSD

protect.1: document existence of _oomprotect
ClosedPublic

Authored by debdrup on May 18 2021, 2:25 PM.
Referenced Files
Unknown Object (File)
Sun, Jul 7, 10:31 AM
Unknown Object (File)
Sat, Jul 6, 5:16 PM
Unknown Object (File)
Wed, Jul 3, 11:58 AM
Unknown Object (File)
Mon, Jul 1, 6:24 AM
Unknown Object (File)
Wed, Jun 26, 6:12 PM
Unknown Object (File)
Jun 7 2024, 10:33 AM
Unknown Object (File)
Jun 5 2024, 8:44 AM
Unknown Object (File)
Jun 5 2024, 8:44 AM
Subscribers

Details

Summary

Documenation related to the recent addition in https://reviews.freebsd.org/D30330

There is also no documentation on how to check whereas protect(1) works. This is possible to obtain by inspecting the output of ps -O flags,flags2 and knowing which bits in the bitmask correspond to -i and protect. Should we document it here also?

Suggested commit message:

commit 2aba7677d77e795613a9fe1516b3733941f7c012 (HEAD -> main)
Author: Adam Wolk <a.wolk@fudosecurity.com>
Date:   Tue May 18 16:19:18 2021 +0200

    protect.1: document existence of _oomprotect
    
    Improve discoverability of the functionality by mentioning in the userland tool
    manual. Add a SEE ALSO entry to rc.conf(5) where more details are provided.
    
    Sponsored by:   Fudo Security

Diff Detail

Repository
rG FreeBSD src repository
Lint
Lint Not Applicable
Unit
Tests Not Applicable

Event Timeline

Yes, it would be good to have a documented method of checking the protected flag, so go ahead and add that.

Once ready, I'll push this along with the other commit.

Yes, it would be good to have a documented method of checking the protected flag, so go ahead and add that.

Once ready, I'll push this along with the other commit.

Word of warning. This is a pretty barebones method that relies on knowing the magic values.

This would be something akin to:

In order to check if protect is properly applied to processes
one can use ps -O flags,flags2 -p pid and read the bits:

root@aw:~ # grep PROTECT /usr/include/sys/proc.h
#define P_PROTECTED     0x100000 /* Do not kill on memory overcommit. */
#define P2_INHERIT_PROTECTED 0x00000001 /* New children get P_PROTECTED. */ 

+ /usr/bin/protect -i su -m awolk -c ./main
 P: 64430
  PID        F       F2 TT  STAT    TIME COMMAND
64430 10104002 00000001  5  S+   0:00.00 ./main

Do we still want that in and if so what level of assumptions should I make? Should I show the grep or just state that nth bit corresponds to the setting?

Document how to obtain the current protection status using ps(1).

Updated suggested commit message:

commit 5461eebe63f10fdcee015fa4b43cc0c5827691fe
Author: Adam Wolk <a.wolk@fudosecurity.com>
Date:   Tue May 18 16:19:18 2021 +0200

    protect.1: document existence of _oomprotect
    
    Improve discoverability of the functionality by mentioning in the userland tool
    manual. Add a SEE ALSO entry to rc.conf(5) where more details are provided.
    
    While here document how to obtain the current protection status using ps(1).
    
    Sponsored by:   Fudo Security

Make the pid used in ps(1) call match the sample output.

Updated the raw diff using the git show -U999999 <commit-hash> > change.diff method.

Have you tested with textproc/igor and mandoc -T lint?

usr.bin/protect/protect.1
93
101

Have you tested with textproc/igor and mandoc -T lint?

I have not. Updating manpages is not something I frequently do so I was not aware of the tools/functionality. Will run it on both reviews in a bit.

Includes changes suggested by @debdrup and ran the tool against igor and mandoc -T lint fixing reported problems.

Fixed one more sentence not started on a new line.

debdrup edited reviewers, added: a.wolk_fudosecurity.com; removed: debdrup.

I apologize deeply for losing track of this one (and the change to rc.subr(8), although I think I managed to address that one).

I've gone over it again, and I'm happy with it now, so I'll go ahead and do the needful. Hopefully it's better late than never. :)

This revision was not accepted when it landed; it landed in state Needs Review.Apr 11 2022, 10:26 PM
This revision was automatically updated to reflect the committed changes.