Page MenuHomeFreeBSD

Capsicum-ize brandelf
AbandonedPublic

Authored by allanjude on Sep 3 2016, 8:25 PM.
Tags
None
Referenced Files
Unknown Object (File)
Dec 22 2023, 11:16 PM
Unknown Object (File)
Nov 1 2023, 12:41 AM
Unknown Object (File)
Sep 30 2023, 2:38 AM
Unknown Object (File)
Mar 23 2023, 6:45 AM
Unknown Object (File)
Mar 6 2023, 4:15 AM
Unknown Object (File)
Mar 21 2017, 8:24 AM
Unknown Object (File)
Dec 13 2016, 9:25 AM
Unknown Object (File)
Nov 27 2016, 8:28 AM
Subscribers

Details

Reviewers
emaste
jonathan
oshogbo
Group Reviewers
capsicum
Summary

If only a single file is to be branded, open the fd, enter the sandbox, process the file

If more files are provided, fork for each fd (max 3 concurrent), and kqueue until they are all finished.
Close the fd on the parent once the fork has started, and the fork will close the fd as soon as it is finished.
This should prevent the FD limit from being encountered even with a large number of files.

Diff Detail

Repository
rS FreeBSD src repository - subversion
Lint
Lint Passed
Unit
No Test Coverage
Build Status
Buildable 5034
Build 5111: arc lint + arc unit

Event Timeline

allanjude retitled this revision from to Capsicum-ize brandelf.
allanjude updated this object.
allanjude edited the test plan for this revision. (Show Details)
usr.bin/brandelf/brandelf.c
261

the warn/warnx etc were replaced with fprintf(stderr, ...) to avoid output being interleaved.

typo fixes

usr.bin/brandelf/brandelf.c
127

s/kqeueu/kqueue/

271

s/Brand/brand/

I'm not a fan of introducing additional forks into otherwise straightforward programs. I think we might introduce more bugs that way than we mitigate with capsicum. I'd rather just allocate a list or array and preopen all inputs.

In D7773#164148, @cem wrote:

I'm not a fan of introducing additional forks into otherwise straightforward programs. I think we might introduce more bugs that way than we mitigate with capsicum. I'd rather just allocate a list or array and preopen all inputs.

I think I could see this going in one of two ways. As @cem says, pre-opening all of the files to be branded would be a less invasive change in terms of the event model (and, for that matter, the need for warnx->fprintf). On the other hand, if we want strong isolation between the files being branded, I'd be tempted to move some of the pdfork logic into brand_fd. However, that might be overkill. Either way, I'm a bit leery of introducing logic that creates sandboxes differently depending on the number of input files.

usr.bin/brandelf/brandelf.c
204

Should these types of stylistic changes be done separately from the Capsicumization?

234

Is there a wiki page listing targets for library-ification?

usr.bin/brandelf/brandelf.c
204

Yes. @allanjude just go ahead and commit the style changes directly first if you like.

Note that I'm pondering a future migration to the slightly updated brandelf now in ELF Tool Chain. I'll upstream any style changes there independently, and then merge the Capsicum changes over.

https://sourceforge.net/p/elftoolchain/code/HEAD/tree/trunk/brandelf/brandelf.c