Computer Protection Program Berkeley Lab
Computer Protection Program at Berkeley Lab Security
Ernest Orlando Lawrence Berkeley National Laboratory
Emergencies | Site Index | Contact Us
CPP Home
Contacts
Policy Guidelines
Scan Information
System Procedures
Tools & Services
ALERTS
Recent CPP Actions
News & Articles
CPP Intranet
 
 
  PROCEDURES FOR SECURING SYSTEMS  
The Basics of Writing Secure Applications  

<< Back to Desktop Security

________

You can configure your system for a high level of security, yet there may be many opportunities to defeat security mechanisms because of security-related flaws in application programs that run on your system. Here are some quick tips for writing more secure applications:

  • Develop highly modularized applications. To the maximum degree possible, compartmentalize functions that must run with privileges from other, nonprivileged functions.
  • Assign permissions that prevent application users from changing the executable itself as well as configuration and data files (with the exception of data files intended to be accessed for the purpose of updating data). Additionally, avoid giving any kind of access to command interpreters and compilers to anyone but system administrators.
  • When data are transmitted over a network, be aware that other systems on the network may capture the traffic. It is thus often appropriate to incorporate encryption in network applications.


  • Be sure to allocate enough memory to be able to hold all the input that the application may receive. In general, allocate two to three times more memory than you think you need. This will help prevent buffer overflows.


  • Ensure that each application checks for and rejects weird and irregular input, such as excessive amounts of input, specially encoded characters that the application cannot process normally, and so forth.


  • If feasible, avoid giving those who need access to your application anything more than normal user privileges. If privileges need to be elevated in one or more routines, rescind these privileges when users exit from each routine.


  • Avoid shared accounts for accessing applications. Have each user login to a separate account with a separate password to access these applications.


  • If a password is required to access an application, follow the guidelines for creating strong passwords.
    • Do not send users their passwords in cleartext over the network. Instead send their passwords in sealed envelopes via Lab or US mail.
  • In Web-based applications, encrypt cookies and avoid using URL variables for storing state information. If possible, avoid server side includes altogether (because they can enable an attacker to execute rogue code).

Here are some additional quick tips for writing more secure UNIX and Linux applications:

  • Do not allow application programs that are SUID root (and possibly SUID other) to run on your system without strong justification based on scientific or operational needs.


  • If there is a strong justification for running a SUID root program, try running it as SUID to an unprivileged user or SGID to a group that does not have access to privileged commands.


  • SUID root programs should be compiled code, not shell scripts. Unauthorized modification is more difficult for the former, since it requires access to a compiler. Additionally, subtle security issues abound in SUID scripts.


  • Creating temporary files with predictable names can create the potential for abuse. Either use a private directory for temporary files or ensure that such files are created with unpredictable names and with file modes that disallow unauthorized access.

  •  

 

Home | Contacts | Policy Guidelines | System Procedures | Tools & Services | ALERTS | News & Articles