DaemonForums  

Go Back   DaemonForums > OpenBSD > OpenBSD Packages and Ports

OpenBSD Packages and Ports Installation and upgrading of packages and ports on OpenBSD.

Reply
 
Thread Tools Display Modes
  #1   (View Single Post)  
Old 11th June 2020
jonsec jonsec is offline
Fdisk Soldier
 
Join Date: Jul 2019
Posts: 71
Default [OpenBSD] Which ports are secure?

I believe security is 99.99% but is not 100%. (unless you are god).
a bad day for security people is a time of hacking.
and i believe OpenBSD Bare is near to 99.99%.
OpenBSD say:
Quote:
"Secure by Default" :
To ensure that novice users of OpenBSD do not need to become security experts overnight (a viewpoint which other vendors seem to have), we ship the operating system in a Secure by Default mode. All non-essential services are disabled. As the user/administrator becomes more familiar with the system, he will discover that he has to enable daemons and other parts of the system. During the process of learning how to enable a new service, the novice is more likely to learn of security considerations.

This is in stark contrast to the increasing number of systems that ship with NFS, mountd, web servers, and various other services enabled by default, creating instantaneous security problems for their users within minutes after their first install.
https://www.openbsd.org/security.html
when i install or config some packages or own OpenBSD then i can cause increase or decrease this value.(but more `decrease`)

decrease : bad config or bug
increase : good config and no bug

according to above details , this question came to my mind.
Which ports are secure?
Do port can be a backdoor or virus or like them?

this subject is reason of create this topics :
http://daemonforums.org/showthread.php?t=11427
http://daemonforums.org/showthread.php?p=69137
Reply With Quote
  #2   (View Single Post)  
Old 11th June 2020
bsdun bsdun is offline
Real Name: Steve
Fdisk Soldier
 
Join Date: Feb 2020
Posts: 48
Default

With ports you have 2 options:
1) Audit the source code yourself
2) Trust ports' maintainers

If it is a small or medium sized program, written in language I know (c, perl, python, lua), then I audit the source code. No problems found so far.
If it is an abomination written in Rust language, I have to trust the maintainers.
Quote:
Which ports are secure?
There are thousands of ports, what exactly are you looking for?
Secure text editor and file manager with Powerful GUI?
That Powerful GUI makes program much more complex and much harder to audit the source code. I guess, you can just trust maintainers: those people have good reputation.
Reply With Quote
  #3   (View Single Post)  
Old 11th June 2020
jonsec jonsec is offline
Fdisk Soldier
 
Join Date: Jul 2019
Posts: 71
Default

in one Sentence : dont unsafe your OpenBSD with install untrusted package.

audit is hard for some people and is good for a big company that have team.

so better solution is maintainers but how i can know this maintainers.
Reply With Quote
  #4   (View Single Post)  
Old 12th June 2020
jggimi's Avatar
jggimi jggimi is offline
More noise than signal
 
Join Date: May 2008
Location: USA
Posts: 7,977
Default

  • The base system is maintained by a small group of developers -- the Project members -- and the code is in constant review. This manual audit sometimes uncovers bugs.
  • The third party programs from which packages are built are not audited by the Project. They may be audited by others, they may be reviewed by individual members, but there is no review by the Project itself for safety, security, code correctness, or any other code quality assessment.
The preparing of third party programs for use with OpenBSD is known as "porting." OpenBSD has a Ports tree which contains only the instructions used to build third party packages that can be installed. Port testing is generally limited to ensuring that a program installs and runs correctly -- auditing of program behavior is generally not part of the process.

All third party programs are considered to be untrusted by the Project as a matter of policy, and, also untrusted as a matter of process. See the section in the dpb(1) man page called "THE SECURITY MODEL OF DPB" for details on security isolation during ports building.

The group of people who create and support the porting instructions used to build packages are "ports maintainers." They include Project members, as well as people in the user community. I'm one of the latter, and maintain a handful of ports.

One of the ports I used to maintain -- but no longer do -- was a complicated application with more than 80,000 lines of completely undocumented code, filled with #ifdef preprocessor instructions which significantly altered operational flow Even so, I was able to limit possible destructive behavior by adding pledge(2) security functionality to the program. But then, after several years of having the upstream developers ignore published CVEs, I asked to be removed as maintainer of the OpenBSD port. I did not -- and still do not -- trust the application, because I do not trust the upstream developers. They do not recognize security problems as a priority.

This application is still in the ports tree, as it has unique functionality. It still has my pledge() calls, limiting what damage it can do if it goes awry. But I do not trust it.

--

So, before you blindly run a third party package -- do some research, because the only trust you should have for these programs is in yourself.

  • What version is available on OpenBSD?
  • Are there any open CVEs against that version?
  • Has the upstream project addressed the CVEs?
  • Is there a maintainer assigned to ask about applying upstream fixes to any CVEs? (pkg_info(1) will give you the name and Email address of the port maintainer)

Last edited by jggimi; 12th June 2020 at 10:54 AM. Reason: typos
Reply With Quote
  #5   (View Single Post)  
Old 13th June 2020
hitest's Avatar
hitest hitest is offline
Real Name: George Nielsen
VPN Cryptographer
 
Join Date: Sep 2008
Location: B.C., Canada
Posts: 373
Default

This is somewhat related. I don't use ports; I install packages. My understanding, as discussed above, is that the base install is very secure.
Are the packages that are available for install when you invoke pkg_add audited for flaws, security holes? I'm assuming this is the case.
__________________
hitest
Reply With Quote
  #6   (View Single Post)  
Old 13th June 2020
IdOp's Avatar
IdOp IdOp is offline
Too dumb for a smartphone
 
Join Date: May 2008
Location: twisting on the daemon's fork(2)
Posts: 1,027
Default

According to the FAQ the packages are just ported programs compiled and bundled up. They do "not go through the same thorough security audit that is performed on the OpenBSD base system" because there aren't "enough resources to ensure the same level of robustness and security".
Reply With Quote
  #7   (View Single Post)  
Old 13th June 2020
hitest's Avatar
hitest hitest is offline
Real Name: George Nielsen
VPN Cryptographer
 
Join Date: Sep 2008
Location: B.C., Canada
Posts: 373
Smile

Quote:
Originally Posted by IdOp View Post
According to the FAQ the packages are just ported programs compiled and bundled up. They do "not go through the same thorough security audit that is performed on the OpenBSD base system" because there aren't "enough resources to ensure the same level of robustness and security".
Thanks for the explanation. I appreciate that. So as end users we need to do our own research and be cautious as we add applications to the base install.
__________________
hitest
Reply With Quote
  #8   (View Single Post)  
Old 13th June 2020
jggimi's Avatar
jggimi jggimi is offline
More noise than signal
 
Join Date: May 2008
Location: USA
Posts: 7,977
Default

You bet, Hitest. Each package you install was built from the instructions in a port. A port contains ONLY the instructions to build a package, but does not contain any third party software. Instructions such as:
  • Where to find the source code.
  • Checksums to make sure the source code hasn't changed.
  • OpenBSD-specific patches, if any are needed, so the program will successfully build and run on OpenBSD.
  • Dependencies needed to be installed in advance to build or run the package.
  • Dependent libraries (and versions) that must be in base or installed to run the package.
  • Which compiler must be used to build the package, on which architectures.
  • What files get packaged into the package, and where they get placed when installed.
  • pkg-readme files containing OpenBSD-specific documentation for provisioning and running the package.
  • rc.subr(8) scripts and reserved userids for any daemons included with the package, so the daemons can be managed with rcctl(8).
Should you ever run -current, one of the nicest things you can do for the Project is subscribe to the ports@ mailing list, and pick up the skills needed to test ports -- new and updates -- for packages you use or want to use. It takes positive reports ("hey, this works for me on my arm64 system!") from people to get changes to the ports tree committed. Also, if there's a problem building or running the port on some architecture, the port maintainer will want to know. If you can build a port and test the resulting package it creates, you can give back to the community.

Testing ports only requires learning how to build 'em. The ports(7) man page and the introductory chapter to the Porter's Handbook are great place to start learning how to help, for anyone who uses -current. A programmer or developer skillset is not needed.
Reply With Quote
  #9   (View Single Post)  
Old 13th June 2020
fvgit's Avatar
fvgit fvgit is offline
Spikes in tights
 
Join Date: May 2016
Location: perl -MMIME::Base64 -le 'print decode_base64("U2hlcndvb2QgRm9yZXN0")'
Posts: 314
Default

Quote:
Originally Posted by jggimi View Post
This application is still in the ports tree, as it has unique functionality. It still has my pledge() calls, limiting what damage it can do if it goes awry. But I do not trust it.
Thanks for the reality check, mate! I've occasionally used the application you're referring to. But I don't recall ever checking for the existence of any CVEs or anything. My face while scrolling down the commit messages for the Makefile: > > >

Just goes to show that archivers should be treated like daemons running on a public ip. They make a prime attack surface considering that they often get files thrown at them coming from virtually anywhere.
Reply With Quote
Old 14th June 2020
jggimi's Avatar
jggimi jggimi is offline
More noise than signal
 
Join Date: May 2008
Location: USA
Posts: 7,977
Default

Keep in mind, CVEs are just formal security bug announcements. I do not trust software that has open, unaddressed CVEs.

But that doesn't mean that software that has no open CVEs is secure. Just that it has no formal security bugs published at the moment.
Reply With Quote
Old 16th June 2020
ibara ibara is offline
OpenBSD language porter
 
Join Date: Jan 2014
Posts: 783
Default

Ports that have updates to address CVEs will be upgraded if you're running -stable. The ports system has a mechanism to record when CVEs are addressed.

Best thing people can do is alert to CVEs when they come up. Even better, send diffs to update vulnerable/outdated ports.
Reply With Quote
Reply

Tags
security openbsd port

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump

Similar Threads
Thread Thread Starter Forum Replies Last Post
[OpenBSD] secure file manager jonsec OpenBSD Packages and Ports 2 27th June 2020 12:49 PM
[OpenBSD] secure text editor jonsec OpenBSD General 11 10th June 2020 08:39 PM
Secure Boot and OpenBSD Head_on_a_Stick Guides 0 12th December 2015 10:25 PM
Is OpenBSD secure by default from ssh users? steamrent OpenBSD Security 2 19th December 2011 09:21 PM
Cisco Secure ACS 4.1 syslog OpenBSD 3.9 cyberpaisalegionair OpenBSD General 1 24th July 2008 06:42 PM


All times are GMT. The time now is 03:59 PM.


Powered by vBulletin® Version 3.8.4
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
Content copyright © 2007-2010, the authors
Daemon image copyright ©1988, Marshall Kirk McKusick