US5913024A - Secure server utilizing separate protocol stacks - Google Patents

Secure server utilizing separate protocol stacks Download PDF

Info

Publication number
US5913024A
US5913024A US08/605,320 US60532096A US5913024A US 5913024 A US5913024 A US 5913024A US 60532096 A US60532096 A US 60532096A US 5913024 A US5913024 A US 5913024A
Authority
US
United States
Prior art keywords
burb
server
domain
bound
network
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Expired - Lifetime
Application number
US08/605,320
Inventor
Michael W. Green
Andrew W. Jensen
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
McAfee LLC
Original Assignee
Secure Computing LLC
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Secure Computing LLC filed Critical Secure Computing LLC
Priority to US08/605,320 priority Critical patent/US5913024A/en
Assigned to SECURE COMPUTING CORPORATION reassignment SECURE COMPUTING CORPORATION ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: GREEN, MICHAEL W., JENSEN, ANDREW W.
Priority to US09/255,111 priority patent/US6332195B1/en
Application granted granted Critical
Publication of US5913024A publication Critical patent/US5913024A/en
Priority to US09/850,261 priority patent/US20010047486A1/en
Assigned to CITICORP USA, INC. AS ADMINISTRATIVE AGENT reassignment CITICORP USA, INC. AS ADMINISTRATIVE AGENT SECURITY AGREEMENT Assignors: CIPHERTRUST, INC., SECURE COMPUTING CORPORATION
Assigned to SECURE COMPUTING CORPORATION reassignment SECURE COMPUTING CORPORATION ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: CITICORP USA, INC.
Assigned to SECURE COMPUTING, LLC reassignment SECURE COMPUTING, LLC CHANGE OF NAME (SEE DOCUMENT FOR DETAILS). Assignors: SECURE COMPUTING CORPORATION
Assigned to MCAFEE, INC. reassignment MCAFEE, INC. ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: SECURE COMPUTING, LLC
Anticipated expiration legal-status Critical
Assigned to MCAFEE, LLC reassignment MCAFEE, LLC CHANGE OF NAME (SEE DOCUMENT FOR DETAILS). Assignors: MCAFEE, INC.
Assigned to SECURE COMPUTING CORPORATION reassignment SECURE COMPUTING CORPORATION CORRECTIVE ASSIGNMENT TO CORRECT THE PROPERTY NUMBERS PREVIOUSLY RECORDED AT REEL: 021523 FRAME: 0713. ASSIGNOR(S) HEREBY CONFIRMS THE RELEASE OF PATENT SECURITY AGREEMENT. Assignors: CITICORP USA, INC.
Expired - Lifetime legal-status Critical Current

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/28Restricting access to network management systems or functions, e.g. using authorisation function to access network configuration
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • G06F9/06Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46Multiprogramming arrangements
    • G06F9/468Specific access rights for resources, e.g. using capability register
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00Payment architectures, schemes or protocols
    • G06Q20/38Payment protocols; Details thereof
    • G06Q20/40Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/02Network architectures or network communication protocols for network security for separating internal from external traffic, e.g. firewalls
    • H04L63/0227Filtering policies
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/02Network architectures or network communication protocols for network security for separating internal from external traffic, e.g. firewalls
    • H04L63/0281Proxies
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/10Network architectures or network communication protocols for network security for controlling access to devices or network resources
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/01Protocols
    • H04L67/02Protocols based on web technology, e.g. hypertext transfer protocol [HTTP]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/16Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
    • H04L69/161Implementation details of TCP/IP or UDP/IP stack architecture; Specification of modified or new header fields
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/16Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
    • H04L69/161Implementation details of TCP/IP or UDP/IP stack architecture; Specification of modified or new header fields
    • H04L69/162Implementation details of TCP/IP or UDP/IP stack architecture; Specification of modified or new header fields involving adaptations of sockets based mechanisms
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/40Network security protocols
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/16Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/30Definitions, standards or architectural aspects of layered protocol stacks
    • H04L69/32Architecture of open systems interconnection [OSI] 7-layer type protocol stacks, e.g. the interfaces between the data link level and the physical level
    • H04L69/322Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions
    • H04L69/329Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions in the application layer [OSI layer 7]

Definitions

  • the present invention relates to computer security, and more particularly, to an apparatus and method for providing increased computer security to commercial transactions across the Internet.
  • Boebert teaches that modifications can be made to the kernel of the operating system in order to add type enforcement protections to the operating system kernel. This protection mechanism can be added to any other program by modifications to the program code made prior to compiling. It cannot, however, be used to add type enforcement protection to program code after that program code has been compiled.
  • a secure commerce server system includes a plurality of regions or burbs, including an internal burb and an external burb, a commerce server and an administration server. Processes and data objects associated with the administration server are bound to the internal burb. Processes and data objects associated with the commerce server are bound to the external burb. Processes bound to one burb cannot communicate directly to processes and data objects bound to other burbs. The admistration server cannot be manipulated by a process bound to the external burb.
  • FIG. 1 is a representation of a system having an internal and external interface connected via two separate protocol stacks;
  • FIGS. 2a-d are representations of communication protocols
  • FIG. 3 is a representation of one form of interprocessor communication which can be used in a system having a plurality of separate protocol stacks;
  • FIG. 4 is a more detailed representation of one embodiment of the form of interprocessor communication shown in FIG. 3;
  • FIG. 5 is an alternate embodiment of the system of FIG. 1 in which all communications between regions (burbs) pass through system space before being passed to another burb;
  • FIG. 6 is a flowchart illustrating the steps taken in securing compiled program code according to the present invention.
  • FIG. 7 is a flowchart illustrating the steps taken in applying network separation to compiled program code according to the present invention.
  • FIG. 8 is a representation of a system built using the steps shown in FIGS. 6 and 7.
  • a secure computer is used to connect a private network having a plurality of workstations to a public network.
  • a protocol package (such as TCP/IP) running on the secure computer implements a communications protocol used to communicate between each workstation and the secure computer.
  • a Local Cryptography function can be integrated into the protocol package in order to protect and authenticate traffic on the private network.
  • Program code running on the secure computer is used to communicate through the private network to the workstation's protocol package.
  • the secure computer is an Intel Pentium-based machine running a hardened form of BSD386 Unix.
  • BSD386 Unix A system based on a 90 MHz Pentium microprocessor with 32 megabytes of memory, 2 gigabytes of hard disk space, a DAT tape for backup and a CD-ROM for software loads has been found to be adequate.
  • program code running on the secure computer is used to communicate through a public network interface to a public network such as the Internet.
  • the program code used to communicate with the Internet is part of a set of Internet protocols which communicate with computers on the Internet through an Internet connection.
  • different protocols and cryptographic methods may be used when communicating with different entities on the Internet.
  • a tcp wrapper package operating in the Internet protocols is used to sit on the external, public network so that information about external probes can be logged. It is most likely that the open nature of the public network will favor the use of public-key cryptography in this module.
  • the secure computer is an Intel Pentium-based machine running a hardened form of Berkeley's BSD386 Unix.
  • BSD386 is hardened by adding a type enforcement mechanism which restricts the access of processes to data.
  • Type enforcement operates in conjunction with page access control bits in the virtual page translator of the Pentium to control access to objects stored in the memory of the secure computer.
  • system calls in the basic BSD386 kernel were modified so that type enforcement checks cannot be avoided. Certain other system calls were either disabled or had certain options disabled.
  • Type enforcement controls are enforced by the kernel and cannot be circumvented by applications.
  • Type enforcement is used to implement data flow structures called Assured Pipelines. Assured pipelines are made possible by the so-called "small process" model of computation used by Unix. In this model, a computational task is divided up into small virtual units that run in parallel to each other. Unix provides a crude and loosely-controlled way of sharing data between processes. Type enforcement supplants this with the rigorously controlled, configurable structure of assured pipelines. It should be noted that Type EnforcementTM works best as a supplement to the normal Unix permissions. That is, the Unix permissions are the first line of defense; when processes get past the Unix permissions, however, they run into the type enforcement checks.
  • the secure computer has been configured under BSD386 to run in one of two states: administrative and operational.
  • administrative state all network connections are disabled and the Server will only accept commands from a properly authenticated System Administrator accessing the system from the hard-wired administrative terminal. This feature prevents anyone other than the System Administrator from altering the security databases in the secure computer.
  • the two states are reflected in two separate kernels.
  • the administrative kernel is not subject to type enforcement. Instead, it is network isolated and accessible only to authorized personnel. This means that in administrative kernel mode, the secure computer cannot be seeded with malicious software by any but the people charged with system administration.
  • the operational kernel is subject to type enforcement. This means, for instance, that executable files stored in the memory of the secure computer cannot be executed without explicit execution privileges. In one such embodiment, executable files cannot be give execution privileges from within the operational kernel. Instead, the secure computer must enter administrative kernel to grant execution privileges. This prevents execution of malicious software posted to memory of the secure computer. Instead, only executables approved by operational administrators while in administrative kernel mode ever become executable within operational kernel mode of the secure computer. In one such embodiment, administrative kernel can be entered only from either a manual interrupt of the boot process to boot the administrative kernel or by booting the secure computer from a floppy that has a pointer to the administrative kernel.
  • Virtual memory translation circuitry within the Pentium processor includes a mechanism for assigning access privileges to pages of virtual memory. This ensures that control is imposed on every fetch from, or store to, the machine memory. In this way, the protection is made continuous.
  • the Pentium access control mechanism enforces the following modes of access:
  • R Read Only
  • RE Read Execute
  • Read Write Data values can be fetched from memory and used as inputs to operations, and may also be stored back in modified form.
  • No Access The data cannot be fetched from memory for any purpose, and it may not be modified.
  • These hardware-enforced accesses can be used to force data flowing from the internal private network to the Internet to go through a filter process, without any possibility that the filter is bypassed or that filtered data is tampered with by possibly vulnerable software on the Internet side of the filter.
  • the access a process has to a data object via type enforcement is defined by an entry in a central, protected data structure called the Domain Definition Table (DDT).
  • DDT Domain Definition Table
  • a Domain name denotes an equivalence class of processes. Every process in execution has associated with it two Domain names which are used to control its interaction with objects and with other Domains.
  • the real Domain of a process is used to control Domain to Domain interactions and to grant or deny special, object-independent privileges.
  • the effective Domain of a process is used to control its access to objects.
  • the real and effective Domains of a process will generally be identical; the circumstances in which they differ are described below.
  • a Type name denotes an equivalence class of objects.
  • Objects are, in general, the "base types" of BSD/386 Unix: files, directories, etc. There are eight default subtypes: file, directory, socket, fifo, device, port, executable, and gate. The implied default subtype pipe is, in effect, untyped because no check is made on access to pipes.
  • Type names consist of two parts and, in the preferred embodiment, are written in documentation and comments as creator:subtype.
  • the creator field is the four-character name of the Domain which created the object.
  • the subtype field denotes the "class" of the object within that Domain. Subtype names are also four characters long and may contain any printable character except ⁇ * ⁇ or whitespace.
  • Subtypes can be assigned one of three ways:
  • the default subtypes exec and gate are "static."
  • the operational kernel will not create any objects of those subtypes, change those subtypes into any other subtype, or change any other subtypes into a gate or exec.
  • the Domain/Type relationship is used to define the modes and consequences of accesses by processes to objects.
  • the modes and consequences of accesses are defined by access attributes which are store in the DDT database.
  • the DDT database is "indexed" by three values:
  • the creator field of the object Type is The creator field of the object Type.
  • attribute is used instead of "mode” because some of the attributes define immediate side effects.
  • selection of attributes was governed by the following considerations.
  • Implicit gating permits a process to temporarily become a member of another Domain.
  • the "home" or permanent Domain of the process is called its real Domain and the temporary or assumed Domain is called the effective Domain.
  • Implicit gating is used when it is necessary to strictly control the manner in which the effective Domain's accesses are used.
  • Implicit gating "ties" the temporary Domain change to a specific executable which has been subjected to extra scrutiny to insure that the effective Domain's accesses are used safely.
  • the “tying" of the Domain change is done because the Domain change is a side effect of execve'ing a special executable: one whose subtype is gate.
  • Implicit gating also allows Domain changes to be defined by changing the Type of an executable instead of inserting explicit calls into the source code.
  • Explicit gating is used when a looser control on the temporary Domain transition is appropriate, or when the "tying" of the gating to a specific executable would require excessive restructuring of existing software.
  • the logical structure of the DIT is a table with an entry for each Domain.
  • the logical structure of each entry is that of two pointers, one to a list of allowed real Domains and the other to a list of allowed effective Domains.
  • the real Domain of the process selects the entry and the Domain given by the domainname argument must be on the list of allowed real Domains for the Domain change to happen.
  • the Domain given in the domainname argument must be on the list of allowed effective Domains.
  • the creator Domain of that executable must appear on the list of allowed effective Domains.
  • Certain kernel syscalls are restricted to processes executing out of privileged Domains.
  • two levels of checks are made. First, the normal BSD UNIX permissions are checked; if these permissions cause the operation to fail, the system call returns the normal error code. If the UNIX permissions are adequate, the type enforcement (TE) privileges are checked next, (and thus in addition to the UNIX permissions).
  • TE type enforcement
  • the first group of system calls that require modification are those that set or affect the identity and/or state of the computer. Two of these system calls affect the computer's internal time: settimeofday and adjtime. Both of these system calls have been modified to require the ⁇ can -- set -- clock> privilege before the request will be honored. In the event of a privilege violation, the system call will raise an Alarm, will not honor the request, but will return success.
  • system calls which affect the computer's notion of self identity are sethostname and sethostid. Both of these system calls have been modified to require the ⁇ is-startup> privilege before the request will be honored. In the event of a privilege violation, the system call will raise an Alarm, will not honor the request, and will return the EPERM error flag.
  • the last system call affects the computers runtime status, reboot. The reboot system call has been modified to require the ⁇ admin-reboot> privilege before the request will be honored. If the request is honored, the computer will boot to the admin kernel (single-user mode only with networking disabled). In the event of a privilege violation, the system call will raise an Alarm, will not honor the request, and will return the EPERM error flag.
  • the second group of system calls that require modification are those that allow interaction with the computer's file system.
  • the open system call has been modified to become the primary TE check. After performing the normal BSD UNIX permission checks, the TE check is performed. An Alarm is raised if the TE check returns null (no permissions), or if the caller asks for read but the ⁇ ddt -- read> privilege is not set, or if the caller asks for write but the ⁇ ddt -- write> privilege is not set.
  • the creat system call has been modified to set the new file's Type to ⁇ creator:file>.
  • the unlink and rename system calls are modified in Like manner.
  • the unlink system call requires the ⁇ ddt -- destroy> privilege.
  • the rename system call requires the ⁇ ddt -- rename> privilege on the "from" file, and if the "to" file exists, it further requires the ⁇ ddt -- destroy> privilege on the "to" file. In the event of a privilege violation, both the unlink and rename system calls will raise an Alarm, will not honor the request, but will return success.
  • the access system call is modified to require the ⁇ mode> privilege on the file pointed to by the path. In the event of a privilege violation, the access system call will raise an Alarm, will not honor the request, but will return success.
  • the chflags, fchflags and quotacl system calls are modified in like manner. All are modified to perform no functions. Attempts to call them will raise an Alarm, will not honor the request, and will return EPERM.
  • the mknod system call is modified to perform no function. Attempts to call it will raise an Alarm, will not honor the request, and will return EPERM.
  • the third group of system calls that require modification are those concerning process creation, maintenance and tracing.
  • the fork system call has been modified so that the child process inherits both the real and effective Domains of the parent process.
  • the execve system call is modified to require the ⁇ ddt -- exec> privilege on the file pointed to by the path before the request will be honored.
  • the real and effective Domains of the process remain unchanged.
  • the system call will raise an Alarm, will not honor the request, but will return success.
  • the ktrace, ptrace and profil system calls are modified in like manner. All are modified to perform no function. Attempts to call them will raise an Alarm, will not honor the request.
  • the ktrace and ptrace system calls will return EPERM, whereas the profil system call will return EFAULT.
  • the mprotect system call is modified to perform no function. Attempts to call it will raise an Alarm, will not honor the request, and will return EPERM.
  • the fourth group of system calls that require modification are those that relate processes to user ids.
  • the setuid and seteuid and old.seteuid system calls are modified in like manner. All are modified to require the ⁇ suppress -- su -- alarm> privilege before the request will be honored. In the event of a privilege violation, the system call will raise an Alarm, will not honor the request, and will return success.
  • the acct system call is modified to perform no function. Attempts to call it will raise an Alarm, will not honor the request, and will return EPERM.
  • the setlogin system call is modified to require the ⁇ can -- setlogin> privilege. In the event of a privilege violation, the access system call will raise an Alarm, will not honor the request, but will return success.
  • a final set of system calls consists of those that are removed entirely from the BSD UNIX kernel. This set of system calls includes:
  • the goal of network separation is to provide an operating system kernel with support for multiple networking protocol stacks.
  • a system 10 having such an operating system kernel is illustrated in FIG. 1.
  • System 10 is split into separate regions, with a domain 16 and a protocol stack 12 assigned to each region.
  • Each protocol stack (12.0, 12.1) has a fixed set of interfaces bound to it.
  • two or more ethernet drivers can be connected to, for instance, protocol stack 12.0.
  • a given socket will be bound to a single protocol stack 12 at creation time.
  • Each protocol stack 12 will have its own independent set of data structures including routing information and protocol information. No data will pass between protocol stacks without going through proxy space and being sent back down another protocol stack by a proxy program 14. Proxy 14 acts as a go-between, therefore, for transfers between domains 16.0 and 16.1. No user applications will have direct access to either network.
  • the embodiments discussed will only cover (common networking support, such as the media layer drivers like PPP, ethernet, and SLIP and the TCP/IP suite of protocols.
  • the BSD kernel supports other protocols such as CCITT/X.25 and XNS. These are not covered here, although it should be apparent that network separation can be extended to other protocols by dividing the protocol stacks associated with the protocol layers into multiple protocol stacks with the number of (and the name of) stacks being the same across all protocol suites.
  • BSD The BSD/OS 2.0 Unix operating system as based upon the BSD 4.4 Lite distribution.
  • the code is virtually identical across all 4.4 derived Unixes (NetBSD1.0, FreeBSD 2.0, and BSD/OS 2.0).
  • the only significant differences are the hardware device drivers in terms of how they autoconfig during boot, which ones are present, and their internal code. Their interfaces to the rest of the networking code is effectively identical.
  • BSD kernel The BSD/OS 2.0 kernel.
  • Burb The aggregation of a protocol stack with all the processes that can access that stack. Processes that can access a particular protocol stack are said to be bound to that protocol stack.
  • NBURBS The number of protocol stacks or network interfaces to which all networking processes and related entities are bound to.
  • Kernel space The address and code space of the running kernel. This includes kernel data structures and functions internal to the kernel. Technically the kernel can access the memory of the current process as well, but "kernel space” generally means the memory (including code and data) that is private to the kernel and not accessible by any user process.
  • User space The address and code space of processes running that isn't kernel space. A running process will often execute inside of the kernel during system calls, but that's kernel space since the kernel *always* is running with the context of the current process except during the few moments of the actual context switch-in a kernel without SMP support and kernel threads.
  • user space refers to code and data allocated by a code that is loaded from an executable and is available to that process, not counting the kernel private code data structures.
  • Protocol stack The set of data structures and logical entities associated with the networking interfaces. This includes sockets, protocol drivers, and the media device drivers.
  • Link level & hardware drivers These are the (almost in some cases) bottom layer drivers that talk a particular physical and/or link level protocol (ethernet, PPP, SLIP). They may be a hardware driver, in the case of most ethernet drivers, or they may sit on top of yet other drivers, such as PPP on a TTY on the COM port driver or even a parallel port Ethernet driver on top of the LPT port driver. Most of these drivers have two layers, a generalized layer that handles the common parts of the link level protocol (ethernet, ppp, etc.) and the hardware specific driver.
  • ethernet physical and/or link level protocol
  • PPP physical and/or link level protocol
  • SLIP link level protocol
  • One of the goals of a secure operating system kernel is to allow dividing the network interfaces into distinct regions so that there is assurance that packets are never quietly passed through the kernel between those regions.
  • the following rules must be met to ensure secure control of packet transfer between regions:
  • a single user process can only send and receive information (packets) from one region at a time.
  • Incoming packets can only go to processes that are in the region associated with the interface the packet arrived on.
  • Any data passing through the computing system to a different region must come into user process and be handed off to a different process that has access to the other region, a proxy program, to be sent out again.
  • Packet Filtering would be done using conventional approaches similar to current firewalls and screening routers. This could be enhanced with additional filters based on interface rather thin address to prevent certain types of spoofing.
  • Packet Separation A given message, incoming or outgoing, would be assigned a type based on the interface it arrived on or the socket it was sent from. The packet would then be thrown out at the top or bottom level if that type didn't match the type of the interface it was being sent on.
  • Protocol stacks would be separated into multiple instances with a given interface or socket existing on only one.
  • the packet typing approach had merit, but required extensive code changes as all of the various layers would have to be rewritten to handle additional fields in all of the various structures (mbufs, sockets, etc.).
  • the other problem with the packet typing approach was how to deal with kernel internally generated messages like ICMP messages.
  • the separate protocol stack approach was selected because it gives a very clear split of the regions making assurance easier. It also requires surprisingly few code changes. Rather than change the existing data structures, they are simply replicated as needed for the various regions.
  • the initial reference has to be fixed, but most references are done by cached pointers within the various structures, so many of the functions and layers of the protocol stack require no changes at all. For instance, the hardware drivers require absolutely no changes.
  • the socket code requires only a minor change during the socket instantiation, subsequent references done using the already fixed pointer to the particular protocol driver. This also gives a performance win because there are basically no lookups done dynamically, only an extra level of indirection during initialization, but not subsequently.
  • the general structure of the design chosen involves duplicating all of the protocol stacks where each stack is independent of the others.
  • the routing to a given stack is done at the very top or bottom of the dataflow so that a given packet, piece of data, control message, etc. is bound to a particular stack at creation.
  • burb ID is an ordinal number.
  • FIG. 2a The general picture of the protocol stacks in a normal BSD kernel is shown in FIG. 2a. An expanded view of this picture to include the various IP protocol drivers is shown in FIG. 2b.
  • a socket When a socket is actually created, it is explicitly, during the initial socket() call 20, bound to one of the protocol drivers 22 via a pair of pointers in the socket structure, the so -- proto member (a pointer to a struct protosw), and the so -- pcb member.
  • the protosw structure is unique per protocol driver, but there is only one per protocol driver.
  • the so -- pcb pointer is an opaque pointer to a socket specific structure that has the protocol specific information for a socket (such as the TCP state information for a TCP socket).
  • the generic media drivers 24 (ethernet, ppp, slip) put incoming packets on a per protocol family (IP, XNS, CCITT, etc.) queue, ipintrq in the case of IP.
  • each burb/protocol stack has a name, that name maps onto a number, starting at 0, that is used as an index.
  • Each static structure is converted into an array. This also makes it easy to change the number of burbs supported.
  • FIG. 2d illustrates a system having two burbs and limited to just IP.
  • a generic system having N burbs is shown in FIG. 3.
  • a specific TCP/IP system having N burbs is shown in FIG. 4.
  • the advantage of duplicating the protocol stacks in their entirety is that the number of data structures to be duplicated, and the points that those are referenced, is manageable, much more so that making a given datum have a type and/or domain and having to "route" within the kernel based on that at every layer.
  • the basic approach is that all shared data structures are replicated N times, 1 for each burg. These data structures are a reasonably finite list. They include:
  • a family and a type is specified, such as socket (AF -- INET, SOCK -- STREAM).
  • the socket creation routine first looks up the top level protocol in the family list, ala: AF -- INET, which returns a 2nd level table of protosw structures that has the individual protocol drivers.
  • the 2nd level table is in the form of XXX domain, such as inetdomain.
  • the first level list is called "domains".
  • the design replicates only the tables (when that family supports separate burbs, such as IP, route). In the case of things like the AF -- UNIX domain, each list will point at the same table. The lookup will then return a protosw structure unique to the instance of the protocol driver, such as inetsw proto! burb!, instead of inetsw proto!. The routing structure will be replicated into routesw NBURBS!.
  • Protocols each have an input queue for incoming packets. Each queue is a simple mbuf list. So queues for protocols will be replicated, becoming things like ipintrq NBURBS! instead of just ipintrq.
  • a reassembly queue Similar to the IP interrupt queue, there is a reassembly queue, ipq, to reassemble fragmented IP packets. All network interfaces have a maximum transmission unit (MTU). Outgoing packets larger than the MTU are fragmented by the IP layer into smaller packets for transmission. When the fragmented packets arrive at the destination, they are placed on a reassembly queue waiting for reassembly. This queue is also replicated into ipq NBURBS!.
  • MTU maximum transmission unit
  • Each interface, including the loopback will be bound at boot time to a given burb by a one time system call.
  • a burb field will be added to the ifnet structure, ifnet.if -- burb, which is unique per interface so that it knows which burb it's in and which interrupt queues to send data to.
  • the binding will also be one shot, so that once an interface is bound, it can't be rebound to a different burb.
  • the loopback interface IP address will have to be unique per interface. In other words, the recommended loopback address 127.0.0.1 cannot be shared between the interfaces.
  • the loopback interface data structure will be replicated, loif NBURBS!. Loopback addresses will be subnetted, with netmask 255.255.0.0, to give each interface a unique IP address, 127.burb.0.1.
  • Each protocol maintains its own list of protocol control blocks, which hold various pieces of information required for the socket operations. These lists will be replicated and maintained on a burb basis: tcb NBURBS! for TCP, udb NBURBS! for UDP, and rawcb NBURBS! for routing sockets.
  • rt -- tables family! There is a single master routing table, rt -- tables family!, that is a linked list of routes. This table will be separated into one table per burb, rt -- tables family! NBURBS!. There will be no master routing table.
  • routing tables will be used as lookup tables so that the incoming end of a proxy knows which outgoing proxy to connect to. For outgoing packets, the search always starts with the local table. If a route cannot be found, then the system searches other tables. If a route is found on a non-local table, then the networking code will hand the packets off to the proxy processes.
  • the data structures for a socket are created dynamically for each socket, so no fixed replication needs to be done.
  • the alternation of the protocol driver lookup code means that a socket will automatically get the pointer to the protocol driver in the correct burb without any changes to the socket code except the domain list search routines.
  • a burb field will be added to the socket structure, socket.so -- burb, so that it knows which burb it's in.
  • a message doesn't normally have an intrinsic burb, but it will be added as a debugging aid during development.
  • Each major data structure that is burb dependent (the input queues, the protosw structures, etc.) will always have a field giving its burb. So at various points, these fields can be compared against during development as a debugging aid.
  • Critical hand off stages (like socket initialization) will have sanity checks that are done all the time because the overhead is negligible.
  • the kernel is implemented to respond to connection requests that are not intended for the computer system itself. For instance, when an internal client requests a connection to an external Internet host, the kernel will answer the request as if it were the external host. Meanwhile, it will attempt to set up the connection with the external host. This process occurs transparently to the internal client. Such support allows the secure computer to answer in a secure manner connections intended for outside boxes.
  • Each burb will have its own routing tables.
  • the general algorithm for each incoming packet will be, see if it's to one of the local addresses, if so accept it (as this is standard behavior). If not, route it within the burb. If that fails, then see if there is a route in another burb (using other burbs' routing tables). If not, then toss the packet. If so, accept the packet and pass it up the stack, which eventually should arrive at the proxies.
  • the existing TCP and UDP drivers will hurt accept the packet and pass it onto a socket if it exists. If it's to an already established TCP connection or a UDP socket, it will get there normally. If it's a new incoming TCP connection that is accepted, it will create the socket, and fill in the local address from the incoming packet. The process doing the accept () can call getsockname () to get that address. In other words, the UDP and TCP drivers trust the lower layer IP driver that the packet is for the machine, so no change to those layers need to be done at all to support this, only the secondary routing lookup in the IP layer.
  • This functionality means a couple of things. For this to work, there still have to be unique IP addresses all around, so no hacks are done to support hidden IP addresses that conflict with external ones. Also, there can only be one default route on the machine still. If there were one per burb, the burb routing lookup wouldn't know where to send it. This isn't hard. Generally the default route will be for one of the outside burbs. Other burbs will simply have to have complete routing for the internal network. This isn't a problem as it's really already the case. A host with a complex internal network already has to have proper routing for all of those networks if it uses a default route.
  • the degree to which network separation protects a network from malicious attack is enhanced through the use of type enforcement.
  • DDT Domain Definition Table
  • DIT Domain Interaction Table
  • An instantiated domain is one that has several instances with identical access rights to itself and other domains. Take two instantiated domains, www0 and www1. They both have identical access to all other domains and subtypes. They also have equivalent access to their instances and no access to other instances. In the domain specification language, these domains are specified with a ⁇ X ⁇ as the last character, where X represents the burb id. So if you say:
  • the DDT/DIT is created like:
  • the DDT/DIT is created like:
  • Protocol is a domain name corresponding to the protocol type.
  • the subtype is an asciish number that is the prot that binding is allowed to.
  • the ftp0 domain would have access to ftp 0:0020 and ftp 0:0021 to give it access to the ftp control and data ports (20 and 21).
  • ddt -- create privilege to create the socket at all.
  • ddt -- read gives the ability to read () or recvmsg ()
  • ddt -- write gives access to write () and sendmsg ().
  • ddt -- read gives access to bind (), listen (), and accept () so that the process can receive an incoming connection.
  • ddt -- write gives access to bind () and connect () so that the process can initiate an outgoing connection.
  • the subtype grants access to a specific type of socket.
  • the types currently include ⁇ icmp ⁇ , only valid under the IP domain (ipoX:icmp), which gives access to ICMP sockets.
  • Subtype ⁇ sock ⁇ is used during the socket creation so the kernel can verify access to a given network domain.
  • the port isn't known at this point, and an exhaustive search of the DIT would be expensive, so any domain that has access to any networking domain has to be given access to the ⁇ sock ⁇ subtype as well.
  • Network configuration programs such as ifconfig, nss, and sysctl must have access to "network -- domain:conf".
  • tcpX:conf allows the Unix commands ifconfig to configure network interfaces and sysctl to set networking configurables.
  • a network interface is bound to a burb at boot time.
  • a given socket is bound to a particular burb at the socket creation time. The rules for this are pretty simple.
  • FIG. 5 An example of a type enforced, network separated system 70 is shown in FIG. 5.
  • ftp0 and ftp 1 are two instantiated domains (72.0 and 72.1, respectively). Each instantiated domain has access to its own protocol stack (74.0 and 74.1). Transfers from one domain to another are made through a ftp proxy 75 via calls to kernel 76.
  • socketburb replaces the old socket () system call. It performs the same function and takes one additional argument, burbid.
  • the old socket () still exists, but its gut has been replaced by a call to socketburb ().
  • int socketburg int domain, int type, int protocol, unsigned long burbid
  • sock1 socket (AF -- INET, SOCK -- STREAM, 0);
  • sock2 socket (AF -- INET, SOCK -- RAW, IPPROTO -- ICMP);
  • Interfaces are bound to a particular burb. This is implemented by a few new socket ioctls()s which set and get the burb id of an interface.
  • Access to a socket for controlling interfaces and other shared parameters is controlled by access to the various conf subtypes.
  • Parameters specific to a protocol like TCP tunables, are controlled by access to the protocol specific type, such as ⁇ tcp0:conf ⁇ .
  • IP layer things like the IP address and burbness of an interface are controlled by the types like ⁇ ip0:conf ⁇ .
  • socket ()-- is used by a process to create a socket that is bound to a particular burb. If socket () is called, the socket is either bound implicitly to the burb id that matches the number of the instantiated domain, or fails.
  • the burb filed is passed as an additional argument to the socketburb () call:
  • EDBOM! returned and an audit generated if the calling process is not in a burb-bound domain.
  • the bind () call has been extended to allow a process to set the local address arbitrarily, it needs ddt -- rename access to "ipoX:spuf".
  • ipoX:spuf no domains have this spoofing capability, i.e., no domains have ddt -- rename access to "ipo.X:spuf”.
  • the calling process also must have the following privileges to successfully bind:
  • EADDRNOTAVAIL! returned and an audit generated if the calling process doesn't have ddt -- rename privilege.
  • EPERM! returned and an audit generated if the calling process doesn't have ddt -- read or has -- rootness privilege.
  • connect ()--initiates a connection from a socket to a specified address and port number.
  • the calling process must have these privileges to the listed domains: subtypes to successfully connect.
  • the ioctl () call is used to manipulate the underlying device parameters.
  • Several new socket ioctl () commands have been added. Most will work with a "struct ifreq" argument and be handled similar to the other set/get ioctls of an interface. If an ordinal value is being set or retrieved such as the burb id, then it will be passed in the ifr -- metric field.
  • ioctl () commands now require is -- startup or is -- admin privilege to execute: SIOCSIFFLAGS, SIOCSIFMETRIC, SIOCADDMULTI, and SIOCDELMULTI. EPERM is returned and an audit is generated if the calling process doesn't have the correct privilege.
  • the burb id is passed in the ifr -- metric field.
  • the calling process must have is -- startup or is -- admin privilege.
  • a sample call would look like:
  • EPERM! returned and an audit generated if the calling process doesn't have is -- startup or is -- admin privilege.
  • the burb id is passed in the ifr -- metric field.
  • the burb id is passed in the ifr -- metric field. A sample call would look like:
  • SIOCGMSGIFNAME get the name of the interface that the pending message arrived on. It is used as a debugging aid or to filter on the basis of the specific interface of the message.
  • the interface name is returned in the ifr -- name field.
  • a sample call would look like:
  • the kernel searches each routing table and returns the first route found.
  • the IP address is passed in the ifr -- addr field.
  • the burb id is returned in the ifr -- metric field on success. Since there can be more than one burb, this command is used by an incoming proxy to find which outing proxy to connect to.
  • a sample call would look like:
  • EHOSTUNREACH! returned and an audit generated if no route can be found for the given address.
  • Network audit is another type of kernel audit. These are logged to /var/log/audit.asc and /var/log/audit.attack.asc. Currently, network audits are generated for ICMP, TCP, UDP, and IP packets.
  • ICMP--ICMP messages are used to communicate error and administrative messages between systems.
  • ICMP audits are the only network audits that can be configurable. This is implemented via the Unix command sysctl and the field burb.X.net.inet.ip.icmpaudit, where X is the burb id.
  • the default state of the secure computer is level 1, audit only icmp-redirects.
  • ICMP audits can be configured at 3 levels:
  • the source-routed packet option is configurable via the sysctl command, by disabling or enabling the fields burb.X.net.inet.ip.forwarding and burb.X.net.inet.ip.forwsrcrt. As default, both of these fields are disabled so the secure computer will not forward any source-routed packets.
  • TCP--the kernel will generate an audit for any TCP attempts to synchronize sequence numbers without a valid protocol control block. These types of packets are viewed as hostile probing attempts.
  • the kernel will also generate a probing attempt audit for any UDP attempts to connect without a valid protocol control block.
  • the art display and command line interface will remain the same. Only the internal implementation will be modified to handle the replicated arp tables.
  • inetd-- is the internet-service daemon that runs at boot time and listens for connections on certain internet sockets. This daemon will be replaced by the Network Services Sentry, NSS. NSS will be "burb aware" and able to start network services in the appropriate domain. Resident servers will be launched from a similar master utility, such as /etc/rc, so that they run in the correct burb. For more information, see the proxy design specification.
  • netstat--formats and displays various network-related status and data structures.
  • the formatting will be modified so that when appropriate, the -I or -i flags and when printing IP sockets, it will include a burb id column in its output.
  • sysctl-- is used to retrieve kernel state and allows processes with appropriate privilege to set kernel state.
  • Network states are replicated appropriately into NBURBS. For the curious, execute "sysctl-a" and you'll be glad you did it.
  • telnet and ftp All services supported on the secure computer, such as telnet and ftp, pass their data through a set of proxies (see, e.g. ftp proxy 75 in FIG. 5).
  • the proxy will accept () the connection or rcvmsg ()/recvmsg () the packet and look at the incoming address, either in the mesg structure for UDP or via getsockname () for TCP. It will then find out which burb has a route to that destination, via ioctl (SIOCGSUBURBRT), and establish a socket connection in the outgoing burb.
  • SIOCGSUBURBRT ioctl
  • That connection will be via a Unix domain socket.
  • Each service will have a proxy directory in /var/run, such as /var/run/telnetp/. In that directory each outgoing proxy will have already opened a domain socket.
  • These sockets exist in the file namespace, so they already have access control via the domain and type of the socket node.
  • the burb functionality guarantees that a given process can only access one burb, and the type enforcement on the socket guarantees that process can't cheat and access another service's proxies.
  • the types on the sockets can give a finer control within a service if needed.
  • telnet proxy servicing a telnet from the external network Net1, into the internal network, Net0.
  • /etc/rc is the boot up script
  • telnetd is the telnet daemon
  • nss is the Network Services Sentry daemon.
  • Packets can be filtered as part of the process. Filtering could go before the proxy, it could go after the proxy, or it could go inside the proxy.
  • proxies have to watch for PORT and PASV requests and set up the data channel and proxy it. Additional channels can be either setup in advance with a standard protocol, or created on the fly by having proxies set up a control channel and bind additional separate domain sockets.
  • UDP proxies are also more complex.
  • the proxies may have to maintain state information about requests, so that they know which request goes where.
  • a UDP (or other datagram) proxy can work two ways. It can either have a single proxy per burb that just forwards and filters packets one at a time (in which case the connecting Domain socket is a datagram socket as well), or it can create a proxy for each "pseudo" connection and track state to optimize things (like sending acks, etc.). In this case there could be a pair of proxies on the fly that created a stream connection between themselves. They could be routed by port (for protocols that have a unique port and each end negotiated on the fly, like gopher or DNS), otherwise a single proxy still has to handle incoming packets and dispatch them.
  • Type enforcement can be used to extend the access protections inherent to a particular program, without access to the source code for that program.
  • An overview of the process used to install any pre-compiled application binary (i.e. the program) onto the secure computer system is shown in FIG. 6.
  • the first step (100) is to install the binary to a location from which it can be executed. Some (but not all) examples of how this can be accomplished are: (a) copying from the installation floppy disk(s) to the internal hard drive, (b) copying from the installation cdrom to the internal hard drive, (c) mounting external media containing the application binary, (d) copying the application binary via the network to the internal hard drive.
  • the secure computer system is placed in a different state than the fully secure operational state.
  • This state is called the development state, since in best practice (i.e. for highest security) this state is only available to developers.
  • the development state has all of the type enforcement checks that the operational state has; however, the consequences of a violation are different.
  • operational state a type enforcement violation results in denying the requested access.
  • development state a type enforcement violation results in allowing the requested access.
  • a log entry is produced which records the type enforcement violation. This logging capability is needed to determine which type enforcement violations the program is generating.
  • the system does not have to be placed in development state to perform this procedure. All that is absolutely required is the logging capability. However, by placing the system in development state, the time and effort required to perform this procedure is greatly reduced. In practice, the procedure detailed in FIG. 6 is followed under in the operational state only when an error was made when performing the procedure under the development state.
  • the program is executed. Because this program was developed using non-type enforcement techniques, this program will make assumptions about its execution environment that will not be true under the type enforcement execution environment. These faulty assumptions will manifest themselves as type enforcement violations.
  • Some sample faulty assumptions that the program can make include (but is not limited to): (a) the program can create files in the system-wide temporary file area, (b) the program can read files that have Unix "global-read" permissions set to true, etc. These faulty assumptions are a direct consequence of the program being non-type enforcement aware: the program is unaware that, in addition to the Unix security restrictions that it is expecting, there are type enforcement security restrictions. Every type enforcement violation must be successfully dealt with in order for the program to function properly while under the operational state.
  • Some violations can be safely ignored. For example, some programs attempt to determine how busy the system is, in order to behave differently under different conditions. If, however, the program is unable to determine how busy the system is (because of a type enforcement violation), the program will simply assume that the system is not busy and continue. For some programs this is an acceptable response, and requires no further action; in these cases (108), type enforcement violations can be ignored.
  • Some violations can be removed by changing the environment that the program is running under. For example, some programs attempt to change their effective user identification after some resource has been acquired. The most common situation of this kind is when the program runs as "root” long enough to open a file, but then changes to "wwwdaemon" immediately thereafter. Under type enforcement, this ability to change to another user will result in a violation under the default operational state. In cases such as these, it is more security effective to remove the need for the program to change to another user by following these steps:
  • step (3) set the type enforcement permissions on the file such that it can be read by the domain in which the process started in step (1) is executing.
  • step (2) results in a security vulnerability. It is only through step (3) that the security vulnerability is closed.
  • Some violations can be removed by granting the program appropriate type enforcement permission(s), so that what was a violation now is a granted permission. Once it is determined that the violation can neither be ignored nor transformed, this action is performed (112).
  • type enforcement violations There are three general kinds of type enforcement violations. They are: (1) File access, (2) Process-to-Process communication, and (3) System Environment Access. Therefore, a check must be made at 114 to determine the variety of type enforcement violation.
  • Programs typically need access to many different sorts of files: configuration files, temporary or scratch files, permanent data files, etc.
  • the only factor that distinguishes these sorts of files from another in the type enforcement sense is whether or not the file is a shared file or not.
  • An example of a non-shared file could be a temporary file.
  • An example of a non-shared file could be a database file containing a list of every user of the system.
  • a shared type must be used. Sometimes, this shared type will not yet exist, and must be created. This can occur, for instance, when two new programs both access the same new file (for example, a configuration file that one program writes and the other program reads). Sometimes, the shared file will already exist. This can occur, for instance, when the new program accesses a system-wide file (for example, a database file containing a list of every user of the system.) If the shared file already exists, it will already have a type. This type is used at 118.
  • the final step is to add at 120 a direct permission to the type enforcement database.
  • This type enforcement permission will grant the domain (in which the program is running) permission on the type (and the file is then set to that type).
  • the fact that the file is not shared is manifested in that there will not be another domain with permission on the type.
  • the fact that the file is shared is manifested in that there will be another domain with permission on the type.
  • the second kind of violation concerns process-to-process communication.
  • Some programs require the ability to communicate with another program via a process-level mechanism.
  • a direct permission is added to the type enforcement database. This permission will grant the sending domain (in which the first program is running) permission on the receiving domain (in which the second program is running).
  • Permissions of this kind are called domain-to-domain interactions, and effectively control the permitted lines of communication between processes.
  • the third kind of violation concerns system environment access. This kind captures all the kinds of violations that do not concern file access or process-to-process communication. An example would be the ability to determine how busy the system is. Previously, this functionality was used to demonstrate a case where the ability could be removed. However, if the ability was required, then dealing with the type enforcement violation would be handled under this kind of violation. To deal with this kind of violation, one determines the specific functionality required. Then, at 124 a direct permission is added to the type enforcement database. This permission will grant the program's domain permission to invoke the required system function.
  • network separation is used to increase the overall security of the system.
  • the system consists of two programs: a production-side program and an administration-side program.
  • the production-side program reside in an unprotected (e.g. Internet) burb.
  • the administration-side program is placed in a protected (e.g. internal) burb.
  • Network Separation if one program has been "bound" to one burb (e.g. Internet) and another program has been "bound” to another burb (e.g. internal), the Network Separation mechanism will preclude the ability for the first program to establish a connection to the second program via a network communication connection; thus it precludes the ability for program to program communication using the network.
  • One way of viewing Type Enforced Network Separation is to acknowledge this lack of direct network to network communication: since the networks cannot be shared, they are separated.
  • the production-side program must be bound to an Internet burb, and it is clear from a security standpoint that the administration-side program should be bound to an internal burb.
  • tradeoffs must be made between availability and security. Binding a program to an Internet burb increases availability but also enormously increases security risks. Binding a program to an internal burb decreases security risks, but results in a decrease in availability.
  • a "partially bound" program is a program which can interact with a specific burb under a reduced set of Network Separation rules. That is, a partially bound program can perform process to process communication with another burb but not network to network communication. Specifically, it is possible for the partially bound program in a first burb to signal a program that has been completely bound to another, separate burb, while simultaneously maintaining other connections to the first burb. Therefore, communication between burbs assigned to different burbs is permitted in a limited way and the problem is solved.
  • a program "P” is completely bound to a burb when the following syntax is used:
  • program "P” can access any of the burbs 0 through 9 (as signified by the character ⁇ # ⁇ above).
  • program "P” When program "P” first starts running, it has its choice of burbs (e.g. www0, www1, . . . www9) to establish a connection. But after the first connection, the program "P” is fully bound to that burb and the domain that is associated with that burb, and cannot establish a connection to any network in another burb.
  • burbs e.g. www0, www1, . . . www9
  • a program "P” is "partially bound" to a burb when the following syntax is used:
  • program "P” loses some of its flexibility (it can now connect only to burb adm0) but it gains the "partially bound” status. Furthermore, since such an approach is treated as if there are no other instantiated domains (i.e. no adm1, adm2, etc.), program P running in domain adm0 can now connect to all other "#"-defined domains.
  • the Netscape Commerce Server version 1.1, available from Netscape Computer, Inc., is a server for use in conducting commercial transactions over the Internet. This server provides user authentication, SSL protection to http connections, and a forms interface for server administration. As such, it is critical that care be taken to protect a malicious attacker from gaining access to and subverting the program.
  • FIG. 8 A type enforced, network separated embodiment 160 of the Netscape Commerce server system is shown in FIG. 8.
  • the Netscape Commerce server system includes two distinct servers: the Commerce server 162 and the administration server 164.
  • one administration server 164 should be able to administer and configure a plurality of separate Commerce servers.
  • the dashed lines indicate a user level permission check such as the Unix file permissions.
  • components of the system are placed within domains 166, 168 and 172 for a higher level of security.
  • Commerce server 162 is installed via an HTML forms driven interface. Administration and configuration after installation is done in the same manner. Installation operates as follows:
  • the user runs the script ns-setup in the source tree (the directory structure from which files are copied to install the Netscape Commerce Server).
  • the user is prompted for the hostname of the host machine.
  • the installation server binds to an arbitrary, non-reserved port.
  • the user is prompted for the name of a Web browser to start up. It then starts the browser on the port the installation server is listening on.
  • the rest of the installation is HTML forms-driven through the browser.
  • Various items such as port number for the Commerce server, UID to run the server under, install directory, logging, administration password, and other server configuration are entered via three forms.
  • Commerce servers 162 can be run on the same machine, binding to different ports (or even the same port, using different IP addresses) and having their own configuration. Each server preforks 16 processes (number is configurable) to serve requests. This can load the system down if many servers are running.
  • the Commerce server is administered via forms using any forms-capable browser and connecting to a separate administration server running on its own port.
  • This server is started and stopped manually, except during installation when it is started automatically. (It is recommended by Netscape that it be stopped when not being used.)
  • the administration server is also configurable via forms (it configures itself). It can be configured to require a password to access it, and to allow only certain hostnames or IP addresses to connect to it.
  • the Commerce server once running, serves Web pages from a directory tree whose root is configurable. CGI script location, URL mappings, user authentication, access control by host, logging, and other items are also configurable via the administration server. Configuring some items causes creation of files, such as generating a key, installing a certificate, and creating a user database.
  • the installation process will be done completely in the administrative kernel (no type enforcement checks), so setting file types in the source tree is not necessary. All file types must be set after the install process is complete since Netscape is not type-enforcement (TE) aware. To accomplish this, a script is used to set all types appropriately. The script must be able to find the appropriate directories, because paths are configurable, and the server files are in a directory named for the port it binds to. This info is passed via arguments or entered by the installer via prompts.
  • Commerce Server 162 runs in domain 166. In one embodiment, this is the same domain in which the CERN server (not shown) runs. Domain 166 is a bound (burbed) domain which is extended to handle the Commerce Server. That is, the Commerce Server is extended to be able to bind to port 443 (https), 80 (http), 8000, 8001, and 8080. In addition, to allow site flexibility, Commerce Server 162 must be able to bind to selected reserved port ranges.
  • Administration Server 164 runs in a new Netscape Admin domain, domain 168.
  • Domain 168 must be a burbed domain, since it does a non-burb-aware socket () call. Transfers between domains must be done through proxy programs acting in concert with kernel 170.
  • CGI scripts run in a CGI processor 171 in burbed CGI domain 172. Since, however, the Netscape server cannot be modified to do a makedomain () to run the CGI script in the proper domain, there will need to be a :tran type added to CGI domain 172. Then , all CGI scripts will be of type tran. In an alternate embodiment, a line could be added to the CGI script itself which causes the script to automatically transition into CGI domain 172. To run a CGI script, Commerce Server 162 initiates a new process which executes in CGI processor 171 within CGI domain 172. The results are then transferred back to Commerce Server 162. In one embodiment, the CERN server also executes CGI scripts within CGI domain 172.
  • the administration server The administration server.
  • CGI scripts for the admin server that generate forms, interpret responses, change config files, administer servers, generate keys, etc.
  • Icons for the Commerce server used for gopher and ftp listings.
  • Key pair file Initially non-existent, generated by admin server when requested by the administrator. Path is configurable.
  • Certificate file Initially non-existent, installed by admin server from the Certificate Authority's certificate response when requested by the administrator. Path is configurable.
  • HTML form to allow users to change their own password.
  • HTML form to analyze access logs.
  • Path is configurable.
  • Path is configurable.
  • Path is configurable.
  • Netscape Commerce Web server 162 runs in the Web server domain (domain 166), the same domain that the CERN Web server runs in. Therefore, the Web server domain needs execute permission to the following:
  • the Web server domain needs write permission to these files:
  • the server Since the server normally runs as root, if it were able to execute arbitrary code, this would be bad. We can address this by not having it run as root, taking advantage of the type enforcement protection of the sockets. This allows users other than root to connect to low numbered sockets. Other than needing to bind to port 80 or 443, there is no other reason the server needs to run as root. Therefore, the server will run as user "www” and group "www” with no need to run as root.
  • the CGI bin executables present a potential security concern. Since the Commerce server is allowed to execute these files, if someone were able to put their own executable on the secure computer, the server may be compromised. TE only allows the Web server domain to transition to the CGI domains and no others. It does not have permission to create or write to files of any executable type. This helps prevent the possibility of an external user subverting the server and uploading an executable file.
  • the entire directory tree containing the html documents which the Commerce server accesses will be write protected from the Web server domain.
  • a separate writable directory will be set aside for all the data created by external users. This is where the CGI executables will put their results.
  • the CGI domain will be allowed to create files in this directory, but not to read or destroy them. These files may later be read and moved internally by the webmaster using mail or FTP.
  • the password administration program will run in the Netscape Admin domain (domain 168). This domain will have all the accesses required to maintain the Admin server and all Commerce servers on the secure computer.
  • the Admin domain needs execute access to the following:
  • the Admin domain needs read access for:
  • the Admin domain needs both read and write access for:
  • CGI scripts run in CGI domain 172.
  • the following files will be of cgix: tran type and will run in the CGI domain:
  • Commerce Server 162 is controlled by the various configuration files maintained by administration server 164. In one embodiment, it may be advantageous to add the ability to start and stop administrative server 164 from another system administration program running in another domain.
  • each domain can have the following privileges: "is -- admin” indicates the domain is an administrative domain, "has -- rootness” means that the domain can violate Unix permissions if the process UID is root, "can -- setlogin” indicates that the domain can set the login name of a process.
  • each domain's DIT could have the following permissions: “dt” indicates that transition to the named domain is allowed, “sABRT” indicates that sending an ABRT signal to the named domain is allowed, “sjob” indicates that sending a job control signal to the named domain is allowed, “sHUP” indicates that sending a HUP signal to the named domain is allowed, and “sUser” indicates that sending a USR1 or USR2 signal to the named domain is allowed.
  • each DDT uses the following permissions: “w” is permission to write, “r” is permission to read, “d” is permission to destroy, “n” is permission to rename, “c” is permission to create and “e” is permission to execute.

Abstract

A secure commerce server system and method. A secure commerce server system includes a plurality of regions or burbs, including an internal burb and an external burb, a commerce server and an administration server. Processes and data objects associated with the administration server are bound to the internal burb. Processes and data objects associated with the commerce server are bound to the external burb. Processes bound to one burb cannot communicate directly to processes and data objects bound to other burbs. The administration server cannot be manipulated by a process bound to the external burb.

Description

BACKGROUND OF THE INVENTION
1. Field of the Invention
The present invention relates to computer security, and more particularly, to an apparatus and method for providing increased computer security to commercial transactions across the Internet.
2. Background Information
There has been an explosion in the growth of computer networks as organizations realize the benefits of networking their personal computers and workstations. Increasingly, these networks are falling prey to malicious outsiders who hack into the network, reading and sometimes destroying sensitive information. Exposure to such attacks has increased as companies connect to outside systems such as the Internet.
To protect themselves from attacks by malicious outsiders, organizations are turning to mechanisms for increasing network security. One such mechanism is described in "SYSTEM AND METHOD FOR PROVIDING SECURE INTERNETWORK SERVICES", U.S. patent application Ser. No. 08/322078 filed Oct. 12, 1994 by Boebert et al., the discussion of which is hereby incorporated by reference. Boebert teaches that modifications can be made to the kernel of the operating system in order to add type enforcement protections to the operating system kernel. This protection mechanism can be added to any other program by modifications to the program code made prior to compiling. It cannot, however, be used to add type enforcement protection to program code after that program code has been compiled.
As use of the Internet has grown, companies are increasingly interested in providing goods and services across the Internet. Software companies such as Netscape have responded by providing commerce server software. Such software typically will be partitioned into a commerce server which is accessible to the Internet shopper and an administration server which is used to maintain the commerce server and which, for security reasons, must be kept inaccessible to all but system administrators. Security mechanisms used to date have not sufficiently protected the administration server from malicious attack. What is needed is a system and method for protecting the administration servers of systems used in Internet commerce from malicious attack.
SUMMARY OF THE INVENTION
The present invention is a secure commerce server system and method. A secure commerce server system includes a plurality of regions or burbs, including an internal burb and an external burb, a commerce server and an administration server. Processes and data objects associated with the administration server are bound to the internal burb. Processes and data objects associated with the commerce server are bound to the external burb. Processes bound to one burb cannot communicate directly to processes and data objects bound to other burbs. The admistration server cannot be manipulated by a process bound to the external burb.
BRIEF DESCRIPTION OF THE DRAWINGS
FIG. 1 is a representation of a system having an internal and external interface connected via two separate protocol stacks;
FIGS. 2a-d are representations of communication protocols;
FIG. 3 is a representation of one form of interprocessor communication which can be used in a system having a plurality of separate protocol stacks;
FIG. 4 is a more detailed representation of one embodiment of the form of interprocessor communication shown in FIG. 3;
FIG. 5 is an alternate embodiment of the system of FIG. 1 in which all communications between regions (burbs) pass through system space before being passed to another burb;
FIG. 6 is a flowchart illustrating the steps taken in securing compiled program code according to the present invention;
FIG. 7 is a flowchart illustrating the steps taken in applying network separation to compiled program code according to the present invention; and
FIG. 8 is a representation of a system built using the steps shown in FIGS. 6 and 7.
DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS
In the following Detailed Description of the Preferred Embodiments, reference is made to the accompanying Drawings which form a part hereof, and in which are shown by way of illustration specific embodiments in which the invention may be practiced. It is to be understood that other embodiments may be utilized and structural changes may be made without departing from the scope of the present invention. Various trademarks, including INTEL™, PENTIUM™, and UNIX™ are referred to herein. These trademarks, and any others mentioned, are the property of their respective owners. PENTIUM™ brand microprocessors are made by Intel and UNIX™ is the name of a particular type of computer operating system.
Computer systems which use a single communications protocol stack to handle communication between an internal and an external network are widely in use. This is the communication model used, for instance, in BSD 4.4. The problem with such a system is that once a process receives privileges within the system, it can use those privileges to access other network files. This can lead to a dangerous breach of network security. Two approaches can be used to beef up the security of such a system: type enforcement and network separation. Type enforcement adds an additional level of protection to the process of accessing files. Network separation divides a system into a set of independent regions. Through network separation a malicious attacker who gains control of one of the regions is prevented from being able to compromise processes executing in other regions. Type enforcement and network separation will be described next.
Type Enforcement
In "SYSTEM AND METHOD FOR PROVIDING SECURE INTERNETWORK SERVICES", U.S. patent application Ser. No. 08/322078 filed Oct. 12, 1994, Boebert et al. describe a way of extending type enforcement protection to a computer system having both an internal private network and an external public network. In one embodiment of such a system, a secure computer is used to connect a private network having a plurality of workstations to a public network. A protocol package (such as TCP/IP) running on the secure computer implements a communications protocol used to communicate between each workstation and the secure computer. A Local Cryptography function can be integrated into the protocol package in order to protect and authenticate traffic on the private network.
Program code running on the secure computer is used to communicate through the private network to the workstation's protocol package. In one embodiment, the secure computer is an Intel Pentium-based machine running a hardened form of BSD386 Unix. A system based on a 90 MHz Pentium microprocessor with 32 megabytes of memory, 2 gigabytes of hard disk space, a DAT tape for backup and a CD-ROM for software loads has been found to be adequate.
Likewise, program code running on the secure computer is used to communicate through a public network interface to a public network such as the Internet. In an Internet embodiment, the program code used to communicate with the Internet is part of a set of Internet protocols which communicate with computers on the Internet through an Internet connection. In one embodiment, different protocols and cryptographic methods may be used when communicating with different entities on the Internet. In one embodiment, a tcp wrapper package operating in the Internet protocols is used to sit on the external, public network so that information about external probes can be logged. It is most likely that the open nature of the public network will favor the use of public-key cryptography in this module.
As noted above, in one embodiment the secure computer is an Intel Pentium-based machine running a hardened form of Berkeley's BSD386 Unix. In that embodiment, BSD386 is hardened by adding a type enforcement mechanism which restricts the access of processes to data. Type enforcement operates in conjunction with page access control bits in the virtual page translator of the Pentium to control access to objects stored in the memory of the secure computer. To accomplish this, system calls in the basic BSD386 kernel were modified so that type enforcement checks cannot be avoided. Certain other system calls were either disabled or had certain options disabled.
The type enforcement controls are enforced by the kernel and cannot be circumvented by applications. Type enforcement is used to implement data flow structures called Assured Pipelines. Assured pipelines are made possible by the so-called "small process" model of computation used by Unix. In this model, a computational task is divided up into small virtual units that run in parallel to each other. Unix provides a crude and loosely-controlled way of sharing data between processes. Type enforcement supplants this with the rigorously controlled, configurable structure of assured pipelines. It should be noted that Type Enforcement™ works best as a supplement to the normal Unix permissions. That is, the Unix permissions are the first line of defense; when processes get past the Unix permissions, however, they run into the type enforcement checks.
In one embodiment, the secure computer has been configured under BSD386 to run in one of two states: administrative and operational. In the administrative state all network connections are disabled and the Server will only accept commands from a properly authenticated System Administrator accessing the system from the hard-wired administrative terminal. This feature prevents anyone other than the System Administrator from altering the security databases in the secure computer.
In the operational state the network connections are enabled and the Server will execute only software which has been compiled and installed as executable by an assured party.
The two states are reflected in two separate kernels. The administrative kernel is not subject to type enforcement. Instead, it is network isolated and accessible only to authorized personnel. This means that in administrative kernel mode, the secure computer cannot be seeded with malicious software by any but the people charged with system administration.
On the other hand, the operational kernel is subject to type enforcement. This means, for instance, that executable files stored in the memory of the secure computer cannot be executed without explicit execution privileges. In one such embodiment, executable files cannot be give execution privileges from within the operational kernel. Instead, the secure computer must enter administrative kernel to grant execution privileges. This prevents execution of malicious software posted to memory of the secure computer. Instead, only executables approved by operational administrators while in administrative kernel mode ever become executable within operational kernel mode of the secure computer. In one such embodiment, administrative kernel can be entered only from either a manual interrupt of the boot process to boot the administrative kernel or by booting the secure computer from a floppy that has a pointer to the administrative kernel.
The flow of data between processes is limited to transfers through assured pipelines controlled, in one embodiment, by the access enforcement mechanism of the Intel Pentium processor. Virtual memory translation circuitry within the Pentium processor includes a mechanism for assigning access privileges to pages of virtual memory. This ensures that control is imposed on every fetch from, or store to, the machine memory. In this way, the protection is made continuous. The Pentium access control mechanism enforces the following modes of access:
Read Only (R): Data values may be fetched from memory and used as inputs to operations, but may not be modified or used as program text.
Read Execute (RE): Data values may be fetched from memory and used as inputs to operations, and may also be used as program text, but may not be modified.
Read Write (RW): Data values can be fetched from memory and used as inputs to operations, and may also be stored back in modified form.
No Access: The data cannot be fetched from memory for any purpose, and it may not be modified.
These hardware-enforced accesses can be used to force data flowing from the internal private network to the Internet to go through a filter process, without any possibility that the filter is bypassed or that filtered data is tampered with by possibly vulnerable software on the Internet side of the filter.
The access a process has to a data object via type enforcement is defined by an entry in a central, protected data structure called the Domain Definition Table (DDT). A Domain name denotes an equivalence class of processes. Every process in execution has associated with it two Domain names which are used to control its interaction with objects and with other Domains. The real Domain of a process is used to control Domain to Domain interactions and to grant or deny special, object-independent privileges. The effective Domain of a process is used to control its access to objects. The real and effective Domains of a process will generally be identical; the circumstances in which they differ are described below.
A Type name denotes an equivalence class of objects. Objects are, in general, the "base types" of BSD/386 Unix: files, directories, etc. There are eight default subtypes: file, directory, socket, fifo, device, port, executable, and gate. The implied default subtype pipe is, in effect, untyped because no check is made on access to pipes. Type names consist of two parts and, in the preferred embodiment, are written in documentation and comments as creator:subtype. The creator field is the four-character name of the Domain which created the object. The subtype field denotes the "class" of the object within that Domain. Subtype names are also four characters long and may contain any printable character except `*` or whitespace.
Subtypes will not be shared; thus Mail:file means, in effect, "the files private to the Mail Domain." When objects are created they are automatically assigned the appropriate default subtype. Objects which are to be shared between Domains must have their subtype changed from the default to an explicit subtype.
Subtypes can be assigned one of three ways:
By having a default subtype assigned when the object is created by the operational kernel.
By having an explicit subtype assigned by the privileged chtype or fchtype syscalls. Thus a file which was to be shared between the Mail Domain and some other Domain would first be created as Mail:file and then changed to, e.g., Type Mail:Publ. If a subtype is changed to a default subtype, then the object becomes private.
By having a default or explicit subtype assigned administratively by the administrative kernel.
The default subtypes exec and gate are "static." The operational kernel will not create any objects of those subtypes, change those subtypes into any other subtype, or change any other subtypes into a gate or exec.
The Domain/Type relationship is used to define the modes and consequences of accesses by processes to objects. The modes and consequences of accesses are defined by access attributes which are store in the DDT database. The DDT database is "indexed" by three values:
The effective Domain of the process requesting the access or action.
The creator field of the object Type.
The subtype field of the object Type.
The result of "indexing" is the retrieval of a set of access attributes. The term "attribute" is used instead of "mode" because some of the attributes define immediate side effects. The selection of attributes was governed by the following considerations.
To constrain the modes of access which processes may exercise on objects.
To prevent the execution of any application software other than that which has been installed through the controlled administrative environment.
To enable the spoofing of attackers so that the attack response facilities can be used to trace them at the physical packet level.
This required a more sophisticated response to illegal accesses than just shutting down the offending process.
Gating permits a process to temporarily become a member of another Domain. The "home" or permanent Domain of the process is called its real Domain and the temporary or assumed Domain is called the effective Domain. Implicit gating is used when it is necessary to strictly control the manner in which the effective Domain's accesses are used. Implicit gating "ties" the temporary Domain change to a specific executable which has been subjected to extra scrutiny to insure that the effective Domain's accesses are used safely. The "tying" of the Domain change is done because the Domain change is a side effect of execve'ing a special executable: one whose subtype is gate. Implicit gating also allows Domain changes to be defined by changing the Type of an executable instead of inserting explicit calls into the source code.
Explicit gating is used when a looser control on the temporary Domain transition is appropriate, or when the "tying" of the gating to a specific executable would require excessive restructuring of existing software.
Domain changes are controlled by the DIT. The logical structure of the DIT is a table with an entry for each Domain. The logical structure of each entry is that of two pointers, one to a list of allowed real Domains and the other to a list of allowed effective Domains. Thus, if a process executed a makedomain or changedomain, the real Domain of the process selects the entry and the Domain given by the domainname argument must be on the list of allowed real Domains for the Domain change to happen. Likewise, if a process executes a gate, the Domain given in the domainname argument must be on the list of allowed effective Domains. Finally, if a process executes an execve of an executable whose subtype is gate, the creator Domain of that executable must appear on the list of allowed effective Domains.
Certain kernel syscalls are restricted to processes executing out of privileged Domains. In one embodiment two levels of checks are made. First, the normal BSD UNIX permissions are checked; if these permissions cause the operation to fail, the system call returns the normal error code. If the UNIX permissions are adequate, the type enforcement (TE) privileges are checked next, (and thus in addition to the UNIX permissions).
The following BSD system calls have been modified to properly implement type enforcement. The modified calls have been grouped into four groups for ease of explanation.
The first group of system calls that require modification are those that set or affect the identity and/or state of the computer. Two of these system calls affect the computer's internal time: settimeofday and adjtime. Both of these system calls have been modified to require the <can-- set-- clock> privilege before the request will be honored. In the event of a privilege violation, the system call will raise an Alarm, will not honor the request, but will return success.
Other system calls which affect the computer's notion of self identity are sethostname and sethostid. Both of these system calls have been modified to require the <is-startup> privilege before the request will be honored. In the event of a privilege violation, the system call will raise an Alarm, will not honor the request, and will return the EPERM error flag. The last system call affects the computers runtime status, reboot. The reboot system call has been modified to require the <admin-reboot> privilege before the request will be honored. If the request is honored, the computer will boot to the admin kernel (single-user mode only with networking disabled). In the event of a privilege violation, the system call will raise an Alarm, will not honor the request, and will return the EPERM error flag.
The second group of system calls that require modification are those that allow interaction with the computer's file system. The open system call has been modified to become the primary TE check. After performing the normal BSD UNIX permission checks, the TE check is performed. An Alarm is raised if the TE check returns null (no permissions), or if the caller asks for read but the <ddt-- read> privilege is not set, or if the caller asks for write but the <ddt-- write> privilege is not set. The creat system call has been modified to set the new file's Type to <creator:file>. Additionally, the creation of a new file implies a write operation on the directory, which in turn implies that the TE-modified open system call will be used to open the directory file, which in turn implies that TE can be used to control the success or failure of the creat system call. The unlink and rename system calls are modified in Like manner. The unlink system call requires the <ddt-- destroy> privilege. The rename system call requires the <ddt-- rename> privilege on the "from" file, and if the "to" file exists, it further requires the <ddt-- destroy> privilege on the "to" file. In the event of a privilege violation, both the unlink and rename system calls will raise an Alarm, will not honor the request, but will return success. The access system call is modified to require the <mode> privilege on the file pointed to by the path. In the event of a privilege violation, the access system call will raise an Alarm, will not honor the request, but will return success. The chflags, fchflags and quotacl system calls are modified in like manner. All are modified to perform no functions. Attempts to call them will raise an Alarm, will not honor the request, and will return EPERM. The mknod system call is modified to perform no function. Attempts to call it will raise an Alarm, will not honor the request, and will return EPERM.
The third group of system calls that require modification are those concerning process creation, maintenance and tracing. The fork system call has been modified so that the child process inherits both the real and effective Domains of the parent process. The execve system call is modified to require the <ddt-- exec> privilege on the file pointed to by the path before the request will be honored. The real and effective Domains of the process remain unchanged. In the event of a privilege violation, the system call will raise an Alarm, will not honor the request, but will return success. The ktrace, ptrace and profil system calls are modified in like manner. All are modified to perform no function. Attempts to call them will raise an Alarm, will not honor the request. The ktrace and ptrace system calls will return EPERM, whereas the profil system call will return EFAULT.
The mprotect system call is modified to perform no function. Attempts to call it will raise an Alarm, will not honor the request, and will return EPERM.
The fourth group of system calls that require modification are those that relate processes to user ids. The setuid and seteuid and old.seteuid system calls are modified in like manner. All are modified to require the <suppress-- su-- alarm> privilege before the request will be honored. In the event of a privilege violation, the system call will raise an Alarm, will not honor the request, and will return success. The acct system call is modified to perform no function. Attempts to call it will raise an Alarm, will not honor the request, and will return EPERM. The setlogin system call is modified to require the <can-- setlogin> privilege. In the event of a privilege violation, the access system call will raise an Alarm, will not honor the request, but will return success.
A final set of system calls consists of those that are removed entirely from the BSD UNIX kernel. This set of system calls includes:
obs-- vtrace, nfssvc, asynch-- daemon, getfh, shmsys, sfork, getdescriptor, and setdescriptor.
Network Separation
The goal of network separation is to provide an operating system kernel with support for multiple networking protocol stacks. A system 10 having such an operating system kernel is illustrated in FIG. 1. System 10 is split into separate regions, with a domain 16 and a protocol stack 12 assigned to each region. Each protocol stack (12.0, 12.1) has a fixed set of interfaces bound to it. For example, two or more ethernet drivers can be connected to, for instance, protocol stack 12.0.
A given socket will be bound to a single protocol stack 12 at creation time. Each protocol stack 12 will have its own independent set of data structures including routing information and protocol information. No data will pass between protocol stacks without going through proxy space and being sent back down another protocol stack by a proxy program 14. Proxy 14 acts as a go-between, therefore, for transfers between domains 16.0 and 16.1. No user applications will have direct access to either network.
The embodiments discussed will only cover (common networking support, such as the media layer drivers like PPP, ethernet, and SLIP and the TCP/IP suite of protocols. The BSD kernel supports other protocols such as CCITT/X.25 and XNS. These are not covered here, although it should be apparent that network separation can be extended to other protocols by dividing the protocol stacks associated with the protocol layers into multiple protocol stacks with the number of (and the name of) stacks being the same across all protocol suites.
The following terminology will be used throughout the document:
BSD The BSD/OS 2.0 Unix operating system as based upon the BSD 4.4 Lite distribution. In the case of the networking functionality the code is virtually identical across all 4.4 derived Unixes (NetBSD1.0, FreeBSD 2.0, and BSD/OS 2.0). The only significant differences are the hardware device drivers in terms of how they autoconfig during boot, which ones are present, and their internal code. Their interfaces to the rest of the networking code is effectively identical.
BSD kernel The BSD/OS 2.0 kernel.
Burb The aggregation of a protocol stack with all the processes that can access that stack. Processes that can access a particular protocol stack are said to be bound to that protocol stack.
NBURBS The number of protocol stacks or network interfaces to which all networking processes and related entities are bound to.
Kernel space The address and code space of the running kernel. This includes kernel data structures and functions internal to the kernel. Technically the kernel can access the memory of the current process as well, but "kernel space" generally means the memory (including code and data) that is private to the kernel and not accessible by any user process.
User space The address and code space of processes running that isn't kernel space. A running process will often execute inside of the kernel during system calls, but that's kernel space since the kernel *always* is running with the context of the current process except during the few moments of the actual context switch-in a kernel without SMP support and kernel threads. In general user space refers to code and data allocated by a code that is loaded from an executable and is available to that process, not counting the kernel private code data structures.
Protocol stack The set of data structures and logical entities associated with the networking interfaces. This includes sockets, protocol drivers, and the media device drivers.
Link level & hardware drivers These are the (almost in some cases) bottom layer drivers that talk a particular physical and/or link level protocol (ethernet, PPP, SLIP). They may be a hardware driver, in the case of most ethernet drivers, or they may sit on top of yet other drivers, such as PPP on a TTY on the COM port driver or even a parallel port Ethernet driver on top of the LPT port driver. Most of these drivers have two layers, a generalized layer that handles the common parts of the link level protocol (ethernet, ppp, etc.) and the hardware specific driver.
One of the goals of a secure operating system kernel is to allow dividing the network interfaces into distinct regions so that there is assurance that packets are never quietly passed through the kernel between those regions. In one embodiment, the following rules must be met to ensure secure control of packet transfer between regions:
A single user process can only send and receive information (packets) from one region at a time.
Once a process is bound to a region, it can only access that region.
Incoming packets can only go to processes that are in the region associated with the interface the packet arrived on.
Any data passing through the computing system to a different region must come into user process and be handed off to a different process that has access to the other region, a proxy program, to be sent out again.
The reasons for these design requirements are fairly simple. The goal is that any information passing through the computer between different regions has to be passed through a predefined, or assured, pipeline.
There are three ways of achieving this goal:
1) Packet Filtering Packet filtering would be done using conventional approaches similar to current firewalls and screening routers. This could be enhanced with additional filters based on interface rather thin address to prevent certain types of spoofing.
2) Packet Separation A given message, incoming or outgoing, would be assigned a type based on the interface it arrived on or the socket it was sent from. The packet would then be thrown out at the top or bottom level if that type didn't match the type of the interface it was being sent on.
3) Separate Protocol Stacks The protocol stacks would be separated into multiple instances with a given interface or socket existing on only one.
In arriving at our current approach, the packet filtering solution was quickly discarded. Although you could eliminate several kinds of spoofing, many of them would still remain. For filtering to work at all, IP packet forwarding must be enabled, but then you are vulnerable to all sorts of nasty things sneaking through the computer system using the normal sorts of attacks with various forms of spoofing, piggybacking, and just plain misconfiguration of complex filtering expressions.
The packet typing approach had merit, but required extensive code changes as all of the various layers would have to be rewritten to handle additional fields in all of the various structures (mbufs, sockets, etc.). The other problem with the packet typing approach was how to deal with kernel internally generated messages like ICMP messages.
The separate protocol stack approach was selected because it gives a very clear split of the regions making assurance easier. It also requires surprisingly few code changes. Rather than change the existing data structures, they are simply replicated as needed for the various regions. The initial reference has to be fixed, but most references are done by cached pointers within the various structures, so many of the functions and layers of the protocol stack require no changes at all. For instance, the hardware drivers require absolutely no changes. The socket code requires only a minor change during the socket instantiation, subsequent references done using the already fixed pointer to the particular protocol driver. This also gives a performance win because there are basically no lookups done dynamically, only an extra level of indirection during initialization, but not subsequently.
The general structure of the design chosen involves duplicating all of the protocol stacks where each stack is independent of the others. The routing to a given stack is done at the very top or bottom of the dataflow so that a given packet, piece of data, control message, etc. is bound to a particular stack at creation.
A name was needed for each of these protocol stacks, and the processes and related entities bound to them, the name that was chosen was burb.
Second, the decision whether to replicate and subdivide into separate burbs is made on a protocol family by protocol family basis. Generally all external supported networking protocol families will be divided. The internal Unix domain socket family won't be replicated. This is important because the Unix Domain sockets (AF-- UNIX) will continue to exist in one common region for the entire system. This feature becomes important for the pipeline structure given later.
To identify the network/socket access a process is given a burb id that says which burb it is in. In one embodiment, the burb ID is an ordinal number.
The general picture of the protocol stacks in a normal BSD kernel is shown in FIG. 2a. An expanded view of this picture to include the various IP protocol drivers is shown in FIG. 2b.
When a socket is actually created, it is explicitly, during the initial socket() call 20, bound to one of the protocol drivers 22 via a pair of pointers in the socket structure, the so-- proto member (a pointer to a struct protosw), and the so-- pcb member. The protosw structure is unique per protocol driver, but there is only one per protocol driver. The so-- pcb pointer is an opaque pointer to a socket specific structure that has the protocol specific information for a socket (such as the TCP state information for a TCP socket).
At the bottom level, the generic media drivers 24 (ethernet, ppp, slip) put incoming packets on a per protocol family (IP, XNS, CCITT, etc.) queue, ipintrq in the case of IP.
The picture then for a created socket becomes something like the system of FIG. 2c.
So, the fundamental concept of the kernel portion of the design is that the protocol stacks are replicated N times (with N being a fixed small constant, typically 2-10), with all protocol level and other shared data structures being replicated. In practice, each burb/protocol stack has a name, that name maps onto a number, starting at 0, that is used as an index. Each static structure is converted into an array. This also makes it easy to change the number of burbs supported. FIG. 2d illustrates a system having two burbs and limited to just IP. A generic system having N burbs is shown in FIG. 3. A specific TCP/IP system having N burbs is shown in FIG. 4.
Once the socket is created then the picture becomes much simpler again, because the individual data structures are then bound explicitly and no lookup or search stage occurs again. All activity then occurs within one of the burbs (e.g., TCP 0!).
The advantage of duplicating the protocol stacks in their entirety is that the number of data structures to be duplicated, and the points that those are referenced, is manageable, much more so that making a given datum have a type and/or domain and having to "route" within the kernel based on that at every layer. As mentioned before, the basic approach is that all shared data structures are replicated N times, 1 for each burg. These data structures are a reasonably finite list. They include:
Protocol Domain List and Tables (domains, protosw)
When a socket is created, a family and a type is specified, such as socket (AF-- INET, SOCK-- STREAM). The socket creation routine first looks up the top level protocol in the family list, ala: AF-- INET, which returns a 2nd level table of protosw structures that has the individual protocol drivers. The 2nd level table is in the form of XXX domain, such as inetdomain. The first level list is called "domains".
The design replicates only the tables (when that family supports separate burbs, such as IP, route). In the case of things like the AF-- UNIX domain, each list will point at the same table. The lookup will then return a protosw structure unique to the instance of the protocol driver, such as inetsw proto! burb!, instead of inetsw proto!. The routing structure will be replicated into routesw NBURBS!.
Protocol Interrupt Queues (ipintrq)
External networking; protocols each have an input queue for incoming packets. Each queue is a simple mbuf list. So queues for protocols will be replicated, becoming things like ipintrq NBURBS! instead of just ipintrq.
IP Fragmentation Queues (ipq)
Similar to the IP interrupt queue, there is a reassembly queue, ipq, to reassemble fragmented IP packets. All network interfaces have a maximum transmission unit (MTU). Outgoing packets larger than the MTU are fragmented by the IP layer into smaller packets for transmission. When the fragmented packets arrive at the destination, they are placed on a reassembly queue waiting for reassembly. This queue is also replicated into ipq NBURBS!.
Interfaces (ifnet)
Each interface, including the loopback will be bound at boot time to a given burb by a one time system call. A burb field will be added to the ifnet structure, ifnet.if-- burb, which is unique per interface so that it knows which burb it's in and which interrupt queues to send data to. The binding will also be one shot, so that once an interface is bound, it can't be rebound to a different burb.
Other data structures are already unique per interface. The other item to be replicated is the list of interfaces. There will be one list per interface. The interface binding call will set the burb of the interface and tell it which interface list to put itself on during initialization.
Loopback Interface (loif)
The loopback interface IP address will have to be unique per interface. In other words, the recommended loopback address 127.0.0.1 cannot be shared between the interfaces. The loopback interface data structure will be replicated, loif NBURBS!. Loopback addresses will be subnetted, with netmask 255.255.0.0, to give each interface a unique IP address, 127.burb.0.1.
Protocol Control Blocks (tcb, udb, rawcb)
Each protocol maintains its own list of protocol control blocks, which hold various pieces of information required for the socket operations. These lists will be replicated and maintained on a burb basis: tcb NBURBS! for TCP, udb NBURBS! for UDP, and rawcb NBURBS! for routing sockets.
Routing Tables (rt-- tables)
There is a single master routing table, rt-- tables family!, that is a linked list of routes. This table will be separated into one table per burb, rt-- tables family! NBURBS!. There will be no master routing table.
These routing tables will be used as lookup tables so that the incoming end of a proxy knows which outgoing proxy to connect to. For outgoing packets, the search always starts with the local table. If a route cannot be found, then the system searches other tables. If a route is found on a non-local table, then the networking code will hand the packets off to the proxy processes.
ARP Tables and Queues (llinfo-- arp, arpintrq)
There are no data structures at the common link level (ethernet, ppp, slip) except the ARP table and the ARP interrupt queue, llinfo-- arp and arpintrq. This again is a list of interfaces with just the information needed for ARP and a queue for incoming ARP packets. Both of these data structures will be replicated, llinfo-- arp NBURBS! and arpintrq NBURBS!.
Sockets (struct socket)
The data structures for a socket are created dynamically for each socket, so no fixed replication needs to be done. The alternation of the protocol driver lookup code means that a socket will automatically get the pointer to the protocol driver in the correct burb without any changes to the socket code except the domain list search routines. A burb field will be added to the socket structure, socket.so-- burb, so that it knows which burb it's in.
There are some other issues. A message doesn't normally have an intrinsic burb, but it will be added as a debugging aid during development. Each major data structure that is burb dependent (the input queues, the protosw structures, etc.) will always have a field giving its burb. So at various points, these fields can be compared against during development as a debugging aid. Critical hand off stages (like socket initialization) will have sanity checks that are done all the time because the overhead is negligible.
The kernel is implemented to respond to connection requests that are not intended for the computer system itself. For instance, when an internal client requests a connection to an external Internet host, the kernel will answer the request as if it were the external host. Meanwhile, it will attempt to set up the connection with the external host. This process occurs transparently to the internal client. Such support allows the secure computer to answer in a secure manner connections intended for outside boxes.
Each burb will have its own routing tables. The general algorithm for each incoming packet will be, see if it's to one of the local addresses, if so accept it (as this is standard behavior). If not, route it within the burb. If that fails, then see if there is a route in another burb (using other burbs' routing tables). If not, then toss the packet. If so, accept the packet and pass it up the stack, which eventually should arrive at the proxies.
The existing TCP and UDP drivers will happily accept the packet and pass it onto a socket if it exists. If it's to an already established TCP connection or a UDP socket, it will get there normally. If it's a new incoming TCP connection that is accepted, it will create the socket, and fill in the local address from the incoming packet. The process doing the accept () can call getsockname () to get that address. In other words, the UDP and TCP drivers trust the lower layer IP driver that the packet is for the machine, so no change to those layers need to be done at all to support this, only the secondary routing lookup in the IP layer.
This functionality means a couple of things. For this to work, there still have to be unique IP addresses all around, so no hacks are done to support hidden IP addresses that conflict with external ones. Also, there can only be one default route on the machine still. If there were one per burb, the burb routing lookup wouldn't know where to send it. This isn't hard. Generally the default route will be for one of the outside burbs. Other burbs will simply have to have complete routing for the internal network. This isn't a problem as it's really already the case. A host with a complex internal network already has to have proper routing for all of those networks if it uses a default route.
This also means there can be no duplicate routes in the replicated routing tables. If there were duplicate routes, the routing lookup would always return the first route found.
Network Separation Using Type Enforcement
The degree to which network separation protects a network from malicious attack is enhanced through the use of type enforcement.
As noted above, in a type enforcement scheme processes and files are assigned to a domain and subtype, domain:subtype. Process-to-file, or domain-to-domain:subtype, access is controlled by the Domain Definition Table (DDT), that specifies the permissions:
create--ddt-- create
write--ddt-- write
read--ddt-- read
destroy--ddt-- destroy
execute--ddt-- execute
rename--ddt-- rename
Subtypes allow a finer division of file types (file=file, diry=directory, sock=socket, exec=executable, etc.).
Interactions between the processes, or domain-to-domain, such as signals, are enforced by the Domain Interaction Table (DIT), that specifies the allowed signals (sHUP, sABRT, sJob, etc.)
An instantiated domain is one that has several instances with identical access rights to itself and other domains. Take two instantiated domains, www0 and www1. They both have identical access to all other domains and subtypes. They also have equivalent access to their instances and no access to other instances. In the domain specification language, these domains are specified with a `X` as the last character, where X represents the burb id. So if you say:
______________________________________
       wwwX:
           has read access to WWW#:conf
           has write access to Slog:sock
______________________________________
the DDT/DIT is created like:
______________________________________
www0:
   has ddt.sub.-- read access to www0:conf
   has ddt.sub.-- write access to Slog:sock
www1:
   has ddt.sub.-- read access to www1:conf
   has ddt.sub.-- write access to Slog:sock
   If another domain is given access to a general instantiated
______________________________________
type,
then it gets equal access to all instances, for instance:
______________________________________
Admn:
    has write, read, create access to www/#:conf
______________________________________
the DDT/DIT is created like:
______________________________________
Admn:
has ddt.sub.-- write, ddt.sub.-- read, ddt.sub.-- create access to
www0:conf
has ddt.sub.-- write, ddt.sub.-- read, ddt.sub.-- create access to
www1:conf
______________________________________
There are a set of special domains that are used to actually grant access to the networks themselves. These domains are in the form of Protocol:port. Protocol is a domain name corresponding to the protocol type. Current domains and what type of socket they map to include:
______________________________________
Domain Name
          Network Domain
                       Socket Family/Protocol
______________________________________
tcpX      TCP          AF.sub.-- INET/SOCK.sub.-- STREAM
udpX      UDP          AF.sub.-- INET/SOCK.sub.-- DGRAM
ipoX      Raw IP       AF.sub.-- INET/SOCK.sub.-- RAW
rteX      Route        PF.sub.-- ROUTE/SOCK.sub.-- RAW
______________________________________
For sockets that have port numbers, such as tcp and udp, the subtype is an asciish number that is the prot that binding is allowed to. For instance, the ftp0 domain would have access to ftp 0:0020 and ftp 0:0021 to give it access to the ftp control and data ports (20 and 21).
The access given corresponds to the directionality of communication. There must be ddt-- create privilege to create the socket at all. For datagram sockets, ddt-- read gives the ability to read () or recvmsg (), and ddt-- write gives access to write () and sendmsg ().
With stream sockets, ddt-- read gives access to bind (), listen (), and accept () so that the process can receive an incoming connection. ddt-- write gives access to bind () and connect () so that the process can initiate an outgoing connection.
The following subtypes give access to random and reserved ports:
rall--bind to all reserved ports explicitly
rany--bind to any arbitrary reserved ports
nall--bind to all non-reserved ports explicitly
nany--bind to any arbitrary non-reserved ports
For portless types, the subtype grants access to a specific type of socket. The types currently include `icmp`, only valid under the IP domain (ipoX:icmp), which gives access to ICMP sockets. Some more network subtypes:
sock--flag access to a network type
conf--access to network configuration capability
Subtype `sock` is used during the socket creation so the kernel can verify access to a given network domain. The port isn't known at this point, and an exhaustive search of the DIT would be expensive, so any domain that has access to any networking domain has to be given access to the `sock` subtype as well.
Network configuration programs such as ifconfig, nss, and sysctl must have access to "network-- domain:conf". For example: tcpX:conf allows the Unix commands ifconfig to configure network interfaces and sysctl to set networking configurables.
A network interface is bound to a burb at boot time. A given socket is bound to a particular burb at the socket creation time. The rules for this are pretty simple.
An example of a type enforced, network separated system 70 is shown in FIG. 5. In FIG. 5, ftp0 and ftp 1 are two instantiated domains (72.0 and 72.1, respectively). Each instantiated domain has access to its own protocol stack (74.0 and 74.1). Transfers from one domain to another are made through a ftp proxy 75 via calls to kernel 76.
Processes running in an "instantiated domain" such as ftp0, intrinsically have access to one and only one burb, the burb that matches the numeric part of the domain name. In these cases, the system just binds that socket to the appropriate burb. It should be noted that a process is not actually bound to a burb until it tries to make a direct or indirect socket call to that burb.
Programs running within other domains either have no access or access to all burbs. In these cases, the caller must specify which burb they want. If they don't, it's an error. If they do specify a burb and they don't have access privileges to that burb, it's also an error.
This specification is implemented via a new system call, socketburb (). Basically, socketburb () replaces the old socket () system call. It performs the same function and takes one additional argument, burbid. The old socket () still exists, but its gut has been replaced by a call to socketburb ().
int socketburg (int domain, int type, int protocol, unsigned long burbid);
Ported applications and new programs will use the new socketburb (). Existing programs, in instantiated domains, using socket () wouldn't have to be changed and still work. Burbification of socket () calls to socketburb () should use the library call domain-- to-- burb () to convert and pass the burbid argument:
sock1=socket (AF-- INET, SOCK-- STREAM, 0);
sock2=socket (AF-- INET, SOCK-- RAW, IPPROTO-- ICMP);
would become:
______________________________________
int domain.sub.-- to.sub.-- burb (long domain);
sock1 =
      socketburb (AF.sub.-- INET, SOCK.sub.-- STREAM, 0, domain.sub.--
      to.sub.-- burb
      (domain));
sock2 =
      socketburb (AF-INET, SOCK-RAW, IPPROTO.sub.-- ICMP,
      domain.sub.-- to.sub.-- burb (domain));
______________________________________
Interfaces are bound to a particular burb. This is implemented by a few new socket ioctls()s which set and get the burb id of an interface.
Access to a socket for controlling interfaces and other shared parameters is controlled by access to the various conf subtypes. Parameters specific to a protocol, like TCP tunables, are controlled by access to the protocol specific type, such as `tcp0:conf`. IP layer things like the IP address and burbness of an interface are controlled by the types like `ip0:conf`.
The following interfaces have been modified or added to support type enforcement, burbification, and transparent proxies. The objectives of these calls have not changed, although access to these calls has been made more restricted. Some new error codes, errno, have been added in the case of type enforcement failures. Only the modifications are described below.
socket ()--is used by a process to create a socket that is bound to a particular burb. If socket () is called, the socket is either bound implicitly to the burb id that matches the number of the instantiated domain, or fails.
socketburb ()--a new system call and it is used to create a socket in a given burb. The burb filed is passed as an additional argument to the socketburb () call:
______________________________________
int socket (int family, int type, int protocol);
int socketburb (int family, int type, int protocol, unsigned long burb);
int domain.sub.-- to.sub.-- burb (long domain);
sock1 = socket (AF.sub.-- INET, SOCK.sub.-- STREAM, 0);
sock2 = socketburb (AF.sub.-- INET, SOCK.sub.-- RAW, IPPROTO.sub.--
        ICMP,
        domain.sub.-- to.sub.-- burb (domain));
______________________________________
These new error codes, errno, are returned by socket () and socketburb ():
EDBOM! returned and an audit generated if the calling process is not in a burb-bound domain.
EPERM! returned and an audit generated if the calling process doesn't have ddt-- create privilege.
bind ()--assigns a local address and port number to a socket. The bind () call has been extended to allow a process to set the local address arbitrarily, it needs ddt-- rename access to "ipoX:spuf". Currently, no domains have this spoofing capability, i.e., no domains have ddt-- rename access to "ipo.X:spuf". The calling process also must have the following privileges to successfully bind:
______________________________________
ddt.sub.-- read
tcpX:port
ddt.sub.-- read
udpX:port
ddt.sub.-- read
ipoX:port, for raw IP
has.sub.-- rootness
reserved ports (0-1023)
______________________________________
EADDRNOTAVAIL! returned and an audit generated if the calling process doesn't have ddt-- rename privilege.
EPERM! returned and an audit generated if the calling process doesn't have ddt-- read or has-- rootness privilege.
connect ()--initiates a connection from a socket to a specified address and port number. The calling process must have these privileges to the listed domains: subtypes to successfully connect.
______________________________________
           ddt.sub.-- write - tcpX:port
           ddt.sub.-- write - udpX:port
______________________________________
EPERM! returned and an audit generated if the calling process doesn't have ddt-- write privilege.
The ioctl () call is used to manipulate the underlying device parameters. Several new socket ioctl () commands have been added. Most will work with a "struct ifreq" argument and be handled similar to the other set/get ioctls of an interface. If an ordinal value is being set or retrieved such as the burb id, then it will be passed in the ifr-- metric field.
The following ioctl () commands now require is-- startup or is-- admin privilege to execute: SIOCSIFFLAGS, SIOCSIFMETRIC, SIOCADDMULTI, and SIOCDELMULTI. EPERM is returned and an audit is generated if the calling process doesn't have the correct privilege. These new ioctl () commands are added to support burbness in the secure computer:
SIOCGIFBURB/SIOCSIFBURB--get and set the burb id of a network interface. The burb id is passed in the ifr-- metric field. To set the interface's burb id, the calling process must have is-- startup or is-- admin privilege. A sample call would look like:
______________________________________
int ioctl (int socket.sub.-- descriptor, unsigned long command, char
*argp);
struct ifreq if;
int burb, so;
ifr.ifr.sub.-- metric = burb;
if (ioctl (so, SIOCSIFBURB, (caddr.sub.-- t) & ifr) < 0 perror ("ioctl
  (SIOCSIFBURB)");
if (ioctl (so, SIOCGIFBURB, (caddr.sub.-- t) & ifr) < 0) perror ("ioctl
  (SIOCGIFBURB)");
______________________________________
EPERM! returned and an audit generated if the calling process doesn't have is-- startup or is-- admin privilege.
EINVAL! returned and an audit generated if the calling process doesn't have access to subtype ":conf".
SIOCGSOCKBURB--get the burb that a socket is bound to. This is mainly a debugging aid. The burb id is passed in the ifr-- metric field.
SIOCGMSGBURB--get the burb of the pending message. It should always be the same as the burb of the socket. This is mainly a debugging aid. The burb id is passed in the ifr-- metric field. A sample call would look like:
______________________________________
struct ifreq ifr;
int burb, so;
if (ioctl (so, SIOCMSGBURB, (caddr.sub.-- t) & ifr) < 0 perror ("ioctl
  (SIOCMSGBURB)");
burb = ifr.ifr.sub.-- metric;
______________________________________
ENOENT! returned and an audit generated if the socket cannot be read.
SIOCGMSGIFNAME--get the name of the interface that the pending message arrived on. It is used as a debugging aid or to filter on the basis of the specific interface of the message. The interface name is returned in the ifr-- name field. A sample call would look like:
______________________________________
struct ifreq ifr;
int so;
if (ioct (so, SIOCMSGIFNAME, (caddr.sub.-- t & ifr) < 0 perror ("ioctl
  (SIOCMSGIFNAME)");
printf ("interface : %s", ifr.ifr.sub.-- name);
______________________________________
ENOENT! returned and an audit generated if the socket cannot be read.
SIOGSUBURBRT--returns a burb id for a given IP addresses. The kernel searches each routing table and returns the first route found. The IP address is passed in the ifr-- addr field. The burb id is returned in the ifr-- metric field on success. Since there can be more than one burb, this command is used by an incoming proxy to find which outing proxy to connect to. A sample call would look like:
______________________________________
struct ifreq ifr;
int so;
ifr.ifr.sub.-- addr = tempaddr;
if (ioctl (so, SIOCGBURBRT, (caddr.sub.-- t) & ifr) < 0) perror ("ioctl
  (SIOCGBURBRT)");
printf ("route %d", ifr.ifr.sub.-- metric);
______________________________________
EHOSTUNREACH! returned and an audit generated if no route can be found for the given address.
The getsockopt () and set sockopt () calls manipulate the options associated with a socket. The following socket options have been added:
______________________________________
#include <sys/types.h>
#include <sys/socket.h>
int getsockopt (int so, int level, int optname, void *optval, int
*optlen);
int setsockopt (int so, int level, int optname, const void *optval, int
  optlen);
______________________________________
SO-- STATE--returns the state of the socket, the so-- state field of the struc socket. This is used by applications that wish to be more intelligent in their handling of a socket depending on its state.
SO-- SOCKBURB--returns the burb id of the socket, similar to ioctl (SIOCGSOCKBURB). A sample call would look like:
______________________________________
int value, length, error;
length = sizeof (value);
if ((error = getsockopt (sockfd, SOL.sub.-- SOCKET, SO.sub.-- SOCKBURB,
  value, & length return error;
return value;
______________________________________
SO-- MSGBURB--returns the burb id of the pending message, similar to ioctl (SIOCGMSGBURB) via an unsigned long.
ENOENT! returned and an audit generated if the socket cannot be read.
SO-- MSGIFNAME--returns the burb id of the pending message, similar to ioctl (SIOCGMSGIFNAME) via an unsigned long.
ENOENT! returned and an audit generated if the socket cannot be read.
Most of the kernel auditings will be generated by type enforcement checks such as check-- ddt (), check-- dit (), and check-- ddt-- net () and user privilege check such as psuser (). These audits are logged to /var/log/audit.asc and /var/log/audit.te.asc.
Network audit is another type of kernel audit. These are logged to /var/log/audit.asc and /var/log/audit.attack.asc. Currently, network audits are generated for ICMP, TCP, UDP, and IP packets.
ICMP--ICMP messages are used to communicate error and administrative messages between systems. ICMP audits are the only network audits that can be configurable. This is implemented via the Unix command sysctl and the field burb.X.net.inet.ip.icmpaudit, where X is the burb id. The default state of the secure computer is level 1, audit only icmp-redirects. ICMP audits can be configured at 3 levels:
0=no icmp audits
1=icmp redirects only (default)
2=all icmp messages, except echo and reply
IP--if the source-routed packets option is disabled (0), the kernel will generate a "source-routed packets dropped" audit for each source-routed packet. The source-routed packet option is configurable via the sysctl command, by disabling or enabling the fields burb.X.net.inet.ip.forwarding and burb.X.net.inet.ip.forwsrcrt. As default, both of these fields are disabled so the secure computer will not forward any source-routed packets.
TCP--the kernel will generate an audit for any TCP attempts to synchronize sequence numbers without a valid protocol control block. These types of packets are viewed as hostile probing attempts.
UDP--similar to TCP, the kernel will also generate a probing attempt audit for any UDP attempts to connect without a valid protocol control block.
There are a number of system utilities that configure or retrieve the network states. These utilities are also modified to support burbness.
arp--displays and modifies the Internet-to-Ethernet address resolution. The art display and command line interface will remain the same. Only the internal implementation will be modified to handle the replicated arp tables.
ifconfig--is used to configure network interface parameters. It is modified to accept a "burb id" entry so that it can be used to set the burb of an interface. It will also print the burb of an interface as part of its normal output. Example: if config ef0 inet 172.17.128.79 netmask 255.255.0.0 burb 0.
inetd--is the internet-service daemon that runs at boot time and listens for connections on certain internet sockets. This daemon will be replaced by the Network Services Sentry, NSS. NSS will be "burb aware" and able to start network services in the appropriate domain. Resident servers will be launched from a similar master utility, such as /etc/rc, so that they run in the correct burb. For more information, see the proxy design specification.
netstat--formats and displays various network-related status and data structures. The formatting will be modified so that when appropriate, the -I or -i flags and when printing IP sockets, it will include a burb id column in its output.
sysctl--is used to retrieve kernel state and allows processes with appropriate privilege to set kernel state. Network states are replicated appropriately into NBURBS. For the curious, execute "sysctl-a" and you'll be glad you did it.
All services supported on the secure computer, such as telnet and ftp, pass their data through a set of proxies (see, e.g. ftp proxy 75 in FIG. 5). There is one proxy for each type of service, http proxy for web, telnet proxy for telnet, and so on. The proxy will accept () the connection or rcvmsg ()/recvmsg () the packet and look at the incoming address, either in the mesg structure for UDP or via getsockname () for TCP. It will then find out which burb has a route to that destination, via ioctl (SIOCGSUBURBRT), and establish a socket connection in the outgoing burb.
That connection will be via a Unix domain socket. Each service will have a proxy directory in /var/run, such as /var/run/telnetp/. In that directory each outgoing proxy will have already opened a domain socket. These sockets exist in the file namespace, so they already have access control via the domain and type of the socket node. Thus, the burb functionality guarantees that a given process can only access one burb, and the type enforcement on the socket guarantees that process can't cheat and access another service's proxies. The types on the sockets can give a finer control within a service if needed.
So the following example shows a telnet proxy servicing a telnet from the external network Net1, into the internal network, Net0. /etc/rc is the boot up script, telnetd is the telnet daemon, and nss is the Network Services Sentry daemon.
______________________________________
                 launches an nss for each burb
                   (nns0, nss1)
                 launches resident servers for each burb
                 launches service proxies (telnetp)
                  telnetd-out  Net 1!
                  psocket = socket (AF.sub.-- UNIX,
                    SOCK.sub.-- STREAM)
                  bind (psocket, "/var/run/proxies
                    /telnet/out-net1")
                  listen (psocket)
                  accept (psocket)
                  nss1  Net1!
                  receives connect () and accept()s
                  launches telnetd-in.
                 telnetd-in  Net0!
                 does getsockname () to get dest
                 does SIOCGSUBURBRT on dest
                 does a connect
                   (/var/run/proxies/telnet/out-Net1)
                  accept () returns
                 writes destination to proxy
                  read()s destination
                  does a connect () to the real
                  destination
                  passes back success
                 select () loop passing data select () loop passing data
                 cleanup on close cleanup on close
______________________________________
Packets can be filtered as part of the process. Filtering could go before the proxy, it could go after the proxy, or it could go inside the proxy.
Some things, like ftp, are more complex. The proxies have to watch for PORT and PASV requests and set up the data channel and proxy it. Additional channels can be either setup in advance with a standard protocol, or created on the fly by having proxies set up a control channel and bind additional separate domain sockets.
UDP proxies are also more complex. The proxies may have to maintain state information about requests, so that they know which request goes where. A UDP (or other datagram) proxy can work two ways. It can either have a single proxy per burb that just forwards and filters packets one at a time (in which case the connecting Domain socket is a datagram socket as well), or it can create a proxy for each "pseudo" connection and track state to optimize things (like sending acks, etc.). In this case there could be a pair of proxies on the fly that created a stream connection between themselves. They could be routed by port (for protocols that have a unique port and each end negotiated on the fly, like gopher or DNS), otherwise a single proxy still has to handle incoming packets and dispatch them.
Which approach used depends on a few things. If address hiding and masquerading is done, state must be maintained. If not, then simple packet forwarding can be done. Some protocols, like NFS (if ever done) will require extensive state. Further information on network separation can be found in "SYSTEM AND METHOD FOR ACHIEVING NETWORK SEPARATION", U.S. patent application Ser. No. xx/xxxxx by Gooderum et al., filed herewith, the details of which are hereby incorporated by reference.
Type Enforcement Protection of Compiled Program Code
Type enforcement can be used to extend the access protections inherent to a particular program, without access to the source code for that program. An overview of the process used to install any pre-compiled application binary (i.e. the program) onto the secure computer system is shown in FIG. 6. The first step (100) is to install the binary to a location from which it can be executed. Some (but not all) examples of how this can be accomplished are: (a) copying from the installation floppy disk(s) to the internal hard drive, (b) copying from the installation cdrom to the internal hard drive, (c) mounting external media containing the application binary, (d) copying the application binary via the network to the internal hard drive.
Once the application binary is accessible for execution, the secure computer system is placed in a different state than the fully secure operational state. This state is called the development state, since in best practice (i.e. for highest security) this state is only available to developers. The development state has all of the type enforcement checks that the operational state has; however, the consequences of a violation are different. In operational state, a type enforcement violation results in denying the requested access. In development state, a type enforcement violation results in allowing the requested access. In both the operational and development state, a log entry is produced which records the type enforcement violation. This logging capability is needed to determine which type enforcement violations the program is generating.
It should be noted that the system does not have to be placed in development state to perform this procedure. All that is absolutely required is the logging capability. However, by placing the system in development state, the time and effort required to perform this procedure is greatly reduced. In practice, the procedure detailed in FIG. 6 is followed under in the operational state only when an error was made when performing the procedure under the development state.
At step 102 the program is executed. Because this program was developed using non-type enforcement techniques, this program will make assumptions about its execution environment that will not be true under the type enforcement execution environment. These faulty assumptions will manifest themselves as type enforcement violations. Some sample faulty assumptions that the program can make include (but is not limited to): (a) the program can create files in the system-wide temporary file area, (b) the program can read files that have Unix "global-read" permissions set to true, etc. These faulty assumptions are a direct consequence of the program being non-type enforcement aware: the program is unaware that, in addition to the Unix security restrictions that it is expecting, there are type enforcement security restrictions. Every type enforcement violation must be successfully dealt with in order for the program to function properly while under the operational state.
There are three general ways to successfully deal with a type enforcement violation. They are: (1) ignore the violation, (2) remove the request that generated the violation, (3) grant additional permission(s) to remove violation. The criteria for choosing one branch over another branch are functionality and security. The less critical the functionality, the more likely that the violation can be ignored or the request removed. The more critical the functionality, the more likely that additional permission(s) will be granted.
Some violations can be safely ignored. For example, some programs attempt to determine how busy the system is, in order to behave differently under different conditions. If, however, the program is unable to determine how busy the system is (because of a type enforcement violation), the program will simply assume that the system is not busy and continue. For some programs this is an acceptable response, and requires no further action; in these cases (108), type enforcement violations can be ignored.
Some violations can be removed by changing the environment that the program is running under. For example, some programs attempt to change their effective user identification after some resource has been acquired. The most common situation of this kind is when the program runs as "root" long enough to open a file, but then changes to "wwwdaemon" immediately thereafter. Under type enforcement, this ability to change to another user will result in a violation under the default operational state. In cases such as these, it is more security effective to remove the need for the program to change to another user by following these steps:
(1) start the process as user "wwwdaemon" directly (thus, the program will no longer require the ability to change to another user);
(2) set the Unix permissions on the file such that it can be read by user "wwwdaemon"; and
(3) set the type enforcement permissions on the file such that it can be read by the domain in which the process started in step (1) is executing.
So, in this example, the original type enforcement violation is removed at 110 by changing the environment external to the program. Note that in a non-type enforcement system, step (2) results in a security vulnerability. It is only through step (3) that the security vulnerability is closed.
In the above example, one can think of the original type enforcement violation as being transformed into another type enforcement violation. The ability to "change user" was transformed into the ability to "read a file".
Some violations can be removed by granting the program appropriate type enforcement permission(s), so that what was a violation now is a granted permission. Once it is determined that the violation can neither be ignored nor transformed, this action is performed (112). There are three general kinds of type enforcement violations. They are: (1) File access, (2) Process-to-Process communication, and (3) System Environment Access. Therefore, a check must be made at 114 to determine the variety of type enforcement violation.
If the violation concerns general file access, a check is made at 116 to see if the file is a shared file. Programs typically need access to many different sorts of files: configuration files, temporary or scratch files, permanent data files, etc. The only factor that distinguishes these sorts of files from another in the type enforcement sense is whether or not the file is a shared file or not. An example of a non-shared file could be a temporary file. Here, only the program needs access, and no other. An example of a non-shared file could be a database file containing a list of every user of the system.
If the file is shared, then a shared type must be used. Sometimes, this shared type will not yet exist, and must be created. This can occur, for instance, when two new programs both access the same new file (for example, a configuration file that one program writes and the other program reads). Sometimes, the shared file will already exist. This can occur, for instance, when the new program accesses a system-wide file (for example, a database file containing a list of every user of the system.) If the shared file already exists, it will already have a type. This type is used at 118.
If the file is not shared, a new type must be created, and the file is set to this new type.
In either case (both shared and non-shared), the final step is to add at 120 a direct permission to the type enforcement database. This type enforcement permission will grant the domain (in which the program is running) permission on the type (and the file is then set to that type). The fact that the file is not shared is manifested in that there will not be another domain with permission on the type. The fact that the file is shared is manifested in that there will be another domain with permission on the type.
The second kind of violation concerns process-to-process communication. Some programs require the ability to communicate with another program via a process-level mechanism. To deal with this kind of violation, one determines the domain of the second program (the program that the first program is trying to communicate with). Then, at 122 a direct permission is added to the type enforcement database. This permission will grant the sending domain (in which the first program is running) permission on the receiving domain (in which the second program is running). Permissions of this kind are called domain-to-domain interactions, and effectively control the permitted lines of communication between processes.
The third kind of violation concerns system environment access. This kind captures all the kinds of violations that do not concern file access or process-to-process communication. An example would be the ability to determine how busy the system is. Previously, this functionality was used to demonstrate a case where the ability could be removed. However, if the ability was required, then dealing with the type enforcement violation would be handled under this kind of violation. To deal with this kind of violation, one determines the specific functionality required. Then, at 124 a direct permission is added to the type enforcement database. This permission will grant the program's domain permission to invoke the required system function.
The Use of Both Type Enforcement and Network Separation to Protect Compiled Program Code
The process described in the previous section is sufficient to handle those instances where programs do not have to be compartmentalized to achieve sufficient security (e.g. utilities such as screen savers or logging utilities). In that case, all programs can reside in and be bound to one region or burb. For systems which can be partitioned into distinct burbs, however, an additional degree of protection can be added by incorporating network separation.
In the case, for instance, where the program(s) to be installed can reside in multiple burbs, yet must maintain the ability to communicate with each other via a networking interface, network separation is used to increase the overall security of the system. One example of such a case is where the system consists of two programs: a production-side program and an administration-side program. In these instances, it is required that the production-side program reside in an unprotected (e.g. Internet) burb. But one does not want the administration-side program residing in an unprotected (e.g. Internet) burb. So instead, the administration-side program is placed in a protected (e.g. internal) burb.
However, by splitting the two programs (production and administration) into two burbs, one has again changed the actual execution environment away from the expected execution environment. The two programs expect (and rely on) the execution environment to allow process to process communication (e.g. signals) between the two programs. On a non-Type Enforced, non-Network Separated system, this assumption is valid. However, on a Network Separated system, the act of placing the administration-side program in a different burb than the production-side program will have the Network Separation side effect of disallowing process to process communication between the administration-side program and the production-side program. From a functionality standpoint, this is not acceptable.
To restore the required program to program communication functionality, one is required to perform steps outside of those explained in the previous section. The problem to be solved concerns the conflicting restrictions placed by the type enforcement system and the network separation system.
In Network Separation, if one program has been "bound" to one burb (e.g. Internet) and another program has been "bound" to another burb (e.g. internal), the Network Separation mechanism will preclude the ability for the first program to establish a connection to the second program via a network communication connection; thus it precludes the ability for program to program communication using the network. One way of viewing Type Enforced Network Separation is to acknowledge this lack of direct network to network communication: since the networks cannot be shared, they are separated.
So, the problem here can be restated as follows: given a program bound to one burb and another program bound to a different burb, how can we allow the two programs to communicate with each other without having access to the source code for either program.
The procedure to solve this problem is shown in FIG. 7:
First, at 140 decide to which burb each of the separate programs is to be bound. In the case of a production-side program and an administration-side program, it is clear that the production-side program must be bound to an Internet burb, and it is clear from a security standpoint that the administration-side program should be bound to an internal burb. In the case of more complicated sets of programs, tradeoffs must be made between availability and security. Binding a program to an Internet burb increases availability but also enormously increases security risks. Binding a program to an internal burb decreases security risks, but results in a decrease in availability.
Second, at 142 determine how the two programs interact. Again, it is important to note that source code is not available for this step. If source code is available for inspection and modification, then this procedure does not apply. Without source code, this step is accomplished by examining the type enforcement violations generated by either or both programs, as required.
Third, at 144 determine whether the type enforcement and network separation violations discovered in the second step can be eliminated. Techniques for removing TE violations (such as those shown in FIG. 6) can be used. In addition, one may be able to eliminate a type enforcement violation by placing one of the programs into a situation where it is "partially bound" to a particular burb. A "partially bound" program is a program which can interact with a specific burb under a reduced set of Network Separation rules. That is, a partially bound program can perform process to process communication with another burb but not network to network communication. Specifically, it is possible for the partially bound program in a first burb to signal a program that has been completely bound to another, separate burb, while simultaneously maintaining other connections to the first burb. Therefore, communication between burbs assigned to different burbs is permitted in a limited way and the problem is solved.
In one embodiment, one creates this "partially bound" program by using a type enforcement database trick. Normally, a program "P" is completely bound to a burb when the following syntax is used:
"P" runs in domain www#
which means that program "P" can access any of the burbs 0 through 9 (as signified by the character `#` above). When program "P" first starts running, it has its choice of burbs (e.g. www0, www1, . . . www9) to establish a connection. But after the first connection, the program "P" is fully bound to that burb and the domain that is associated with that burb, and cannot establish a connection to any network in another burb.
A program "P" is "partially bound" to a burb when the following syntax is used:
"P" runs in domain adm0
Here, the program "P" loses some of its flexibility (it can now connect only to burb adm0) but it gains the "partially bound" status. Furthermore, since such an approach is treated as if there are no other instantiated domains (i.e. no adm1, adm2, etc.), program P running in domain adm0 can now connect to all other "#"-defined domains.
For the production-side program "PP" and administration-side program "AA" example above, a full example might be:
"AA" runs in domain adm0
"PP" runs in domain prd#
Thus, since the program "AA" is "partially bound" to `adm0`, there can be no domains adm1 through adm9. Program "AA" has, however, gained the ability to interact with prd0 through prd9. Thus, the required signalling ability is re-established.
If it is not possible to place all but one of the programs in a "partially bound" burb, then this procedure must stop without succeeding. The only alternative at this point is to place all programs in the same burb. Then, since the additional Network Separation checks are no longer an issue, this procedure degenerates into the type enforcement only approach described previously.
Further information on increasing security of compiled program code can be found in "SYSTEM AND METHOD FOR SECURING COMPILED PROGRAM CODE", U.S. patent application Ser. No. xx/xxxxx by Haigh et al., filed herewith, the details of which are hereby incorporated by reference.
Secure Commerce Server
One embodiment of a binary program made secure through a combination of type enforcement and network separation is described next. The Netscape Commerce Server, version 1.1, available from Netscape Computer, Inc., is a server for use in conducting commercial transactions over the Internet. This server provides user authentication, SSL protection to http connections, and a forms interface for server administration. As such, it is critical that care be taken to protect a malicious attacker from gaining access to and subverting the program.
A type enforced, network separated embodiment 160 of the Netscape Commerce server system is shown in FIG. 8. The Netscape Commerce server system includes two distinct servers: the Commerce server 162 and the administration server 164. In the preferred embodiment, one administration server 164 should be able to administer and configure a plurality of separate Commerce servers. In the system of FIG. 8, the dashed lines indicate a user level permission check such as the Unix file permissions. In addition, components of the system are placed within domains 166, 168 and 172 for a higher level of security.
Commerce server 162 is installed via an HTML forms driven interface. Administration and configuration after installation is done in the same manner. Installation operates as follows:
1. The user runs the script ns-setup in the source tree (the directory structure from which files are copied to install the Netscape Commerce Server).
2. The user is prompted for the hostname of the host machine.
3. A temporary configuration is written in /tmp and a special WWW server is started using this configuration (the installation server).
4. The installation server binds to an arbitrary, non-reserved port.
5. The user is prompted for the name of a Web browser to start up. It then starts the browser on the port the installation server is listening on.
6. The rest of the installation is HTML forms-driven through the browser. Various items such as port number for the Commerce server, UID to run the server under, install directory, logging, administration password, and other server configuration are entered via three forms.
7. The configuration is verified and the actual installation takes place:
1. create destination directory and subdirectories
2. create document root directory
3. create server startup and shutdown scripts
4. create server configuration files
5. copy all binaries, administration forms, and other files from source tree to destination tree
6. change owner of directories
7. start administration server
8. start Commerce Server
9. remove files created in /tmp
8. Installation complete.
Many Commerce servers 162 can be run on the same machine, binding to different ports (or even the same port, using different IP addresses) and having their own configuration. Each server preforks 16 processes (number is configurable) to serve requests. This can load the system down if many servers are running.
After installation, the Commerce server is administered via forms using any forms-capable browser and connecting to a separate administration server running on its own port. This server is started and stopped manually, except during installation when it is started automatically. (It is recommended by Netscape that it be stopped when not being used.) The administration server is also configurable via forms (it configures itself). It can be configured to require a password to access it, and to allow only certain hostnames or IP addresses to connect to it.
The Commerce server, once running, serves Web pages from a directory tree whose root is configurable. CGI script location, URL mappings, user authentication, access control by host, logging, and other items are also configurable via the administration server. Configuring some items causes creation of files, such as generating a key, installing a certificate, and creating a user database.
High Level Design
This section describes what must be done to port the Netscape Commerce Server to the secure computer. Since we have no source code from Netscape, we cannot modify how the server or installation process operates. Thus, design will focus on what needs to be done outside the Netscape source code to handle type enforcement.
The installation process will be done completely in the administrative kernel (no type enforcement checks), so setting file types in the source tree is not necessary. All file types must be set after the install process is complete since Netscape is not type-enforcement (TE) aware. To accomplish this, a script is used to set all types appropriately. The script must be able to find the appropriate directories, because paths are configurable, and the server files are in a directory named for the port it binds to. This info is passed via arguments or entered by the installer via prompts.
Commerce Server 162 runs in domain 166. In one embodiment, this is the same domain in which the CERN server (not shown) runs. Domain 166 is a bound (burbed) domain which is extended to handle the Commerce Server. That is, the Commerce Server is extended to be able to bind to port 443 (https), 80 (http), 8000, 8001, and 8080. In addition, to allow site flexibility, Commerce Server 162 must be able to bind to selected reserved port ranges.
Administration Server 164 runs in a new Netscape Admin domain, domain 168. Domain 168 must be a burbed domain, since it does a non-burb-aware socket () call. Transfers between domains must be done through proxy programs acting in concert with kernel 170.
CGI scripts run in a CGI processor 171 in burbed CGI domain 172. Since, however, the Netscape server cannot be modified to do a makedomain () to run the CGI script in the proper domain, there will need to be a :tran type added to CGI domain 172. Then , all CGI scripts will be of type tran. In an alternate embodiment, a line could be added to the CGI script itself which causes the script to automatically transition into CGI domain 172. To run a CGI script, Commerce Server 162 initiates a new process which executes in CGI processor 171 within CGI domain 172. The results are then transferred back to Commerce Server 162. In one embodiment, the CERN server also executes CGI scripts within CGI domain 172.
For installing two servers on the same port, but with different IP addresses:
1. Follow the install directions twice, specifying everything the same except a different server name (which will need to resolve to the correct IP address), bind address, and document root.
2. Make an IP alias so that both IP addresses used for the bind addresses in the previous step access the secure computer. Type: ifconfig ef1 alias 172.17.128.199 to alias the IP address 172.17.128.199 to the external interface.
3. Access both servers using the different IP addresses.
Files Manifest
The following are files associated with the Commerce Server. In this section, /server-root/ will denote the path where the server files are installed. Also, the subdirectory https-443 will denote the directory containing all files specific to the server running on port 443. The actual name will contain the port number the server binds to in place of `443`.
Executables
/server-root/bin/https/ns-httpd
The Commerce server.
/server-root/admserv/ns-admin
The administration server.
/server-root/admserv/servlist
Part of the administration server.
/server-root/bin/https/admin/bin/*
CGI scripts for the admin server that generate forms, interpret responses, change config files, administer servers, generate keys, etc.
/server-root/extras/database/batchdb
Utility to convert NCSA-style user database to DBM database.
/server-root/extras/database/changepw.cgi
CGI script to allow users to change their own password via forms.
/server-root/extras/log-- anly/analyze
Analyze access logs.
/server-root/extras/log-- anly/a-- form.cgi
CGI script to analyze access logs via forms.
/server-root/https-443/restart
Restart the Commerce server.
/server-root/https-443/rotate
Rotate the log files.
/server-root/https-443/start
Start up the Commerce server.
/server-root/https-443/stop
Shut down the Commerce server.
/server-root/start-admin
Start up the administration server.
/server-root/stop-admin
Shut down the administration server.
Configuration Files
/server-root/admserv/admpw
User and password file for access to administration server.
/server-root/admserv/ns-admin.conf
Configuration file for the administration server.
/server-root/bin/https/admin/html/*
Forms templates for the administration server.
/server-root/bin/https/admin/icons/*
Icons for the administration server.
/server-root/mc-icons/*
Icons for the Commerce server, used for gopher and ftp listings.
/server-root/userdb/*
User databases. (Initially empty)
/server-root/https-443/config/admin.conf
Commerce server configuration file.
/server-root/https-443/config/magnus.conf
Commerce server configuration file.
/server-root/https-443/config/obj.conf
Commerce server configuration file.
/server-root/https-443/config/mime.types
Commerce server configuration file.
/server-root/https-443/config/ServerKey.der
Key pair file. Initially non-existent, generated by admin server when requested by the administrator. Path is configurable.
/server-root/https-443/config/ServerCert.der
Certificate file. Initially non-existent, installed by admin server from the Certificate Authority's certificate response when requested by the administrator. Path is configurable.
Log Files
/server-root/admserv/errors
Log file for administration server.
/server-root/https-443/logs/access
Commerce server access log. Path is configurable.
/server-root/https-443/logs/errors
Commerce server error log.
/server-root/https-443/logs/secure
Commerce server secure log. (All https accesses are logged here with the keysize used).
Temporary Files
/server-root/admserv/pid
Contains the process ID of the administration server when running.
/server-root/https-443/logs/pid
Contains the process ID of the Commerce server when running.
System Files
/etc/spwd.db
System password file containing encrypted passwords.
/etc/pwd.db
A shadow password file.
Other Files
/server-root/extras/database/changepw.htm
HTML form to allow users to change their own password.
/server-root/extras/log-- anly/a-- form.html
HTML form to analyze access logs.
/server-root/docs/index. html
Default home page for the Commerce server. Path is configurable.
CGI scripts
Path is configurable.
HTML pages
Path is configurable.
As noted previously, Netscape Commerce Web server 162 runs in the Web server domain (domain 166), the same domain that the CERN Web server runs in. Therefore, the Web server domain needs execute permission to the following:
/server-root/bin/https/ns-httpd
In addition, the Web server domain needs read permission to these files:
/server-root/mc-icons/*
/server-root/userdb/*
/server-root/https-443/config/admin.conf
/server-root/https-443/config/magnus.conf
/server-root/https-443/config/obj.conf
/server-root/https-443/config/mime.types
/server-root/https-443/config/ServerKey.der
/server-root/https-443/config/ServerCert.der
/server-root/extras/database/changepw.htm
/server-root/extras/log-- anly/a-- form.html
/server-root/docs/index.html
The Web server domain needs write permission to these files:
/server-root/https-443/logs/access
/server-root/https-443/logs/errors
/server-root/https-443/logs/secure
/server-root/https-443/logs pid
Since the server normally runs as root, if it were able to execute arbitrary code, this would be bad. We can address this by not having it run as root, taking advantage of the type enforcement protection of the sockets. This allows users other than root to connect to low numbered sockets. Other than needing to bind to port 80 or 443, there is no other reason the server needs to run as root. Therefore, the server will run as user "www" and group "www" with no need to run as root.
The CGI bin executables present a potential security concern. Since the Commerce server is allowed to execute these files, if someone were able to put their own executable on the secure computer, the server may be compromised. TE only allows the Web server domain to transition to the CGI domains and no others. It does not have permission to create or write to files of any executable type. This helps prevent the possibility of an external user subverting the server and uploading an executable file.
The entire directory tree containing the html documents which the Commerce server accesses will be write protected from the Web server domain. A separate writable directory will be set aside for all the data created by external users. This is where the CGI executables will put their results. The CGI domain will be allowed to create files in this directory, but not to read or destroy them. These files may later be read and moved internally by the webmaster using mail or FTP.
The password administration program will run in the Netscape Admin domain (domain 168). This domain will have all the accesses required to maintain the Admin server and all Commerce servers on the secure computer.
The Admin domain needs execute access to the following:
/server-root/admserv/ns-admin
/server-root/admserv/servlist
/server-root/bin/https/admin/bin/*
/server-root/extras/database/batchdb
/server-root/extras/log-- anly/a-- form.cgi
/server-root/extras/log-- anly/analyze
/server-root/https-443/restart
/server-root/https-443/rotate
/server-root/https-443/start
/server-root/https-443/stop
/server-root/start-admin
/server-root/stop-admin
The Admin domain needs read access for:
/server-root/bin/https/admin/html/*
/server-root/bin/https/admin/icons/*
/server-root/extras/database/changepw.htm
/server-root/extras/log-- anly/a-- form.html
HTML pages
The Admin domain needs both read and write access for:
/server-root/admserv/admpw
/server-root/admserv/ns-admin.conf
/server-root/admserv/pid
/server-root/admserv/errors
/server-root/userdb/*
/server-root/https-443/config/admin.conf
/server-root/https-443/config/magnus.conf
/server-root/https-443/config/obj.conf
/server-root/https-443/config/mime.types
/server-root/https-443/config/ServerKey.der
/server-root/https-443/config/ServerCert.der
/server-root/https-443/logs/access
/server-root/https-443/logs/errors
/server-root/https-443/logs/secure
/server-root/https-443/logs/pid
CGI scripts run in CGI domain 172. The following files will be of cgix: tran type and will run in the CGI domain:
/server-root/extras/database/changepw.egi
/server-root/extras/log-- anly/a-- form.cgi
CGI-scripts
Commerce Server 162 is controlled by the various configuration files maintained by administration server 164. In one embodiment, it may be advantageous to add the ability to start and stop administrative server 164 from another system administration program running in another domain.
Since the secure computer uses type enforcement on sockets, we can allow users other than root to bind to reserved ports. As a result, we run the Commerce server as user id "www" and group id "www". The "www" user is similar to "nobody" and has no log in capabilities. The administration server will still run as root. In addition, scripts that start and stop the servers need to execute /bin/sh (type $Sys:shel). These scripts are also not type-aware, so they need to be modified to execute in the correct domain.
In one embodiment, the following domains are used to define the commerce server system. It should be apparent that other combinations of domains, privileges or access rights could be used. In the list, each domain can have the following privileges: "is-- admin" indicates the domain is an administrative domain, "has-- rootness" means that the domain can violate Unix permissions if the process UID is root, "can-- setlogin" indicates that the domain can set the login name of a process. In addition, each domain's DIT could have the following permissions: "dt" indicates that transition to the named domain is allowed, "sABRT" indicates that sending an ABRT signal to the named domain is allowed, "sjob" indicates that sending a job control signal to the named domain is allowed, "sHUP" indicates that sending a HUP signal to the named domain is allowed, and "sUser" indicates that sending a USR1 or USR2 signal to the named domain is allowed.
Finally, each DDT uses the following permissions: "w" is permission to write, "r" is permission to read, "d" is permission to destroy, "n" is permission to rename, "c" is permission to create and "e" is permission to execute.
______________________________________
Domain: CGI `cgix`
{ CGI scripts run here - limited access to things }
Privs:
DIT:
CGI       sABRT     { }
Subtype: Script `scrp`
{ Used for CGI shell scripts }
DDT:
        CGI er  { }
        Webmaster
                wrdnc   { }
        www er  { }
Subtype: Transition `tran`
{ Used for CGI compiled executables, not shell scripts. }
DDT:
        Webmaster
                rewn    { }
        www e   { }
Subtype: File `file`
{ }
DDT:
        CGI  wrdnc  { }
        Webmaster
                wrdnc   { }
Subtype: Directory `diry`
{ }
DDT:
        CGI  wr { }
        Webmaster
                wrdnc   { }
        www     { }
Subtype: Save `save`
{ }
DDT:
        CGI  c  { }
        Webmaster
                wrdnc   { }
Domain: NetscapeAdmServ `nas0`
{ This domain is for the Netscape Admin Server. }
Privs:
can.sub.-- setlogin
DIT:
CGI  dt         { }
NetscapeAdmServ sJob sABRT { To control itself. }
www dt sJob     sHUP { }
Subtype: Executable `exec`
{ }
DDT:
NetscapeAdmServ  re  { }
Webmaster  re { }
Subtype: Config `conf`
{ The Netscape Admin Server configuration file }
DDT:
Webmaster  rwncd  { }
NetscapeAdmServ  rwdnc  { }
Subtype: File `file`
{ Default file type. This is the type created whenever the Admin
Server creates a file (Key/Certificate files, User Databases,
temporary files, etc.). }
DDT:
Webmaster  wrdnc  { }
NetscapeAdmServ  wrdnc  { }
www r         { To read Key and Certificate files, and User
              databases created by the Netscape admin
              server. }
Subtype: Directory `diry`
{ }
DDT:
NetscapeAdmServ  wrdnc  { }
Webmaster  wrdnc  { }
Domain: Webmaster `Webr`
{ This domain is for web admin work. }
Privs:
is.sub.-- admin
has.sub.-- rootness
DIT:
CGI  dt sJob    { }
NetscapeAdmServ  dt sJob  sABRT  { }
Webmaster  sJob sHUP sABRT
                     { }
www  dt sJob sHUP sABRT
                     { }
Subtype: File `file`
{ Default file type. }
DDT:
Webmaster  ewrdnc  { }
Subtype: Executable `exec`
{ }
DDT:
Webmaster  e  { }
Subtype: Directory `diry`
{ }
DDT:
Webmaster  wrdnc  { }
Domain: www `www#`
{ The www domain is where any Web servers will be run, such as
the Commerce Server. }
Privs:
DIT:
CGI  dt         { }
www  sUser sJob sHUP sABRT  { Needs to control itself. }
Subtype: Config `conf`
{ The httpd configuratin file(s). }
DDT:
NetscapeAdmServ  wr
                   { }
Webmaster  rwncd   { }
www  r  { }
Subtype: File `file`
{ Default file type. This is the type created whenever the
Commerce Server creates a file (log files, temporary files, etc.).}
DDT:
NetscapeAdm Serv  rn
                   { }
Webmaster  wrdnc   { }
www  wrdnc   { }
Subtype: Page `page`
{ web pages }
DDT:
NetscapeAdmServ  r { }
Webmaster  rwncd   { }
www  r   { }
Subtype: Directory `diry`
{ }
DDT:
CGI  r   { }
NetscapeAdmServ  wr
                   { }
Webmaster  wrdnc   { }
www  wrdc          { Web stores cached files in
                   dirs, needs to make and destroy
                   as needed}
Domain: wwwCommon `wwwc`
{ The common Web server domain (for items shared across burbs). }
Privs:
DIT:
Subtype: Executable `exec`
{ This is the Web Server executable type. }
DDT:
Webmaster  e  { }
www  e   { Need to be able to run the server. }
Subtype: Config `conf`
{ }
DDT:
NetscapeAdmServ  wrdnc  { }
Webmaster  wrdnc  { }
www  r   { }
Subtype: Directory `diry`
{ }
DDT:
CGI  r  { }
NetscapeAdmServ  wr
                   { }
Webmaster  wrdnc   { }
www  r   { }
Subtype: Page `page`
{ }
DDT:
CGI  r   { }
NetscapeAdmServ  r { }
Webmaster  wrdnc   { }
www  r   { }
______________________________________
Although the present invention has been described with reference to the preferred embodiments, those skilled in the art will recognize that changes may be made in form and detail without departing from the spirit and scope of the invention.

Claims (9)

What is claimed is:
1. A secure commerce server system, comprising:
a plurality of regions or burbs, including an internal burb and an external burb, wherein processes bound to one burb cannot communicate directly to processes and data objects bound to other burbs, and wherein the internal burb includes a first protocol stack and the external burb includes a second protocol stack separate from the first protocol stack;
a commerce server, wherein processes and data objects associated with the commerce server are bound to the external burb;
an administration server, wherein processes and data objects associated with the administration server are bound to the internal burb; and
means for restricting communication between the external burb and the administration server so that the administration server cannot be manipulated by a process bound to the external burb; wherein the means for restricting communication include;
means for examining a message received by the administration server; and
means for routing the message up through the first protocol stack to a process bound to the first burb, transferring the message to a process bound to the second burb and routing the message down through the second protocol stack to the second network interface.
2. The commerce server system according to claim 1 wherein the administration server includes means for reading and writing a configuration file used to configure the commerce server.
3. The commerce server system according to claim 1 wherein the administration server includes means for starting and stopping the commerce server.
4. The commerce server system according to claim 1 wherein the commerce server system further includes a CGI processor for executing CGI scripts, wherein the plurality of burbs further includes a cgix burb and wherein the CGI processor is bound to the cgix burb and all CGI scripts are restricted to operating within said cgix burb.
5. The commerce server system according to claim 1 wherein the means for restricting communication includes means for enforcing a type enforcement mechanism to restrict communication between burbs.
6. A method of conducting electronic commerce over a plurality of networks, including an external network and an internal network, wherein the internal network includes an administration server, the method comprising the steps of:
connecting a network interface to each of the plurality of networks, wherein the step of connecting includes the steps of connecting a first network interface to the external network and a second network interface to the internal network;
defining a plurality of burbs, wherein the plurality of burbs includes a first and a second burb, wherein the first burb includes a first protocol stack and the second burb includes a second protocol stack separate from the first protocol stack;
assigning each of the network interfaces to one of the plurality of burbs, wherein more than one network interface can be assigned to a particular burb, wherein the step of assigning includes the steps of assigning the first network interface to the first burb and the second network interface to the second burb;
binding processes to burbs;
receiving an electronic commerce request from the external network; and
transferring the electronic commerce request to the administration server, wherein the step of transferring includes the steps of:
routing the electronic commerce request up through the first protocol stack to a process bound to the first burb;
sending the electronic commerce request to a process bound to the second burb; and
routing the message down through the second protocol stack to the second network interface.
7. The method according to claim 6, wherein the step of binding processes to burbs includes the steps of:
preventing a process from accessing burbs other than the burb to which the process is bound;
limiting transfer of incoming packets such that incoming packets can only go to processes bound to the burb associated with the network interface the packet arrived on;
defining a proxy; and
ensuring that data passing from the first network interface to the second network interface must pass through the proxy before moving from the first burb to the second burb.
8. The method according to claim 6, wherein each burb has its own routing table and wherein the step of sending the electronic commerce request to a process bound to the second burb includes the step of examining an incoming packet to determine if its destination is an address in the first burb's routing table.
9. The method according to claim 6, wherein the step of binding processes to burbs includes the steps of:
defining a plurality of types;
assigning each data object to one of the plurality of types, wherein the step of assigning data objects includes defining type enforcement rules for accesses by processes to said data objects; and
applying a type enforcement check of accesses by processes to data objects.
US08/605,320 1996-02-09 1996-02-09 Secure server utilizing separate protocol stacks Expired - Lifetime US5913024A (en)

Priority Applications (3)

Application Number Priority Date Filing Date Title
US08/605,320 US5913024A (en) 1996-02-09 1996-02-09 Secure server utilizing separate protocol stacks
US09/255,111 US6332195B1 (en) 1996-02-09 1999-02-22 Secure server utilizing separate protocol stacks
US09/850,261 US20010047486A1 (en) 1996-02-09 2001-05-07 Secure commerce server

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
US08/605,320 US5913024A (en) 1996-02-09 1996-02-09 Secure server utilizing separate protocol stacks

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US09/255,111 Continuation US6332195B1 (en) 1996-02-09 1999-02-22 Secure server utilizing separate protocol stacks

Publications (1)

Publication Number Publication Date
US5913024A true US5913024A (en) 1999-06-15

Family

ID=24423174

Family Applications (3)

Application Number Title Priority Date Filing Date
US08/605,320 Expired - Lifetime US5913024A (en) 1996-02-09 1996-02-09 Secure server utilizing separate protocol stacks
US09/255,111 Expired - Lifetime US6332195B1 (en) 1996-02-09 1999-02-22 Secure server utilizing separate protocol stacks
US09/850,261 Abandoned US20010047486A1 (en) 1996-02-09 2001-05-07 Secure commerce server

Family Applications After (2)

Application Number Title Priority Date Filing Date
US09/255,111 Expired - Lifetime US6332195B1 (en) 1996-02-09 1999-02-22 Secure server utilizing separate protocol stacks
US09/850,261 Abandoned US20010047486A1 (en) 1996-02-09 2001-05-07 Secure commerce server

Country Status (1)

Country Link
US (3) US5913024A (en)

Cited By (75)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2001022325A1 (en) * 1999-09-20 2001-03-29 Hwang Ivan Chung Shung System and methods for implementing e-commerce services
US6226694B1 (en) * 1998-04-29 2001-05-01 Hewlett-Packard Company Achieving consistency and synchronization among multiple data stores that cooperate within a single system in the absence of transaction monitoring
WO2001061473A1 (en) * 2000-02-16 2001-08-23 Watchguard Technologies, Inc. Computer security using dual functional security contexts
US20020023037A1 (en) * 1997-08-22 2002-02-21 White Newton B. Exchange method and apparatus
US6357010B1 (en) * 1998-02-17 2002-03-12 Secure Computing Corporation System and method for controlling access to documents stored on an internal network
US6405367B1 (en) * 1998-06-05 2002-06-11 Hewlett-Packard Company Apparatus and method for increasing the performance of Java programs running on a server
US20020103414A1 (en) * 2000-12-05 2002-08-01 Harrison Michael J. Condom with male genital desensitizer lubricant
US20020111920A1 (en) * 2001-02-09 2002-08-15 International Business Machines Corporation System and method for maintaining customer privacy
US20020194493A1 (en) * 2000-11-28 2002-12-19 Hewlett-Packard Company Demonstrating integrity of a compartment of a compartmented operating system
WO2003001345A2 (en) * 2001-06-26 2003-01-03 Mirror Worlds Technologies, Inc. Stream-based enterprise and desktop information management systems
US6529985B1 (en) 2000-02-04 2003-03-04 Ensim Corporation Selective interception of system calls
US20030050036A1 (en) * 2001-09-07 2003-03-13 Hayduk Matthew A. Security services for wireless devices
US20030084318A1 (en) * 2001-10-31 2003-05-01 Schertz Richard L. System and method of graphically correlating data for an intrusion protection system
US20030084322A1 (en) * 2001-10-31 2003-05-01 Schertz Richard L. System and method of an OS-integrated intrusion detection and anti-virus system
US6560613B1 (en) 2000-02-08 2003-05-06 Ensim Corporation Disambiguating file descriptors
US20030115364A1 (en) * 2001-12-19 2003-06-19 Li Shu Camouflage of network traffic to resist attack
US20030120955A1 (en) * 1999-01-29 2003-06-26 Lucent Technologies Inc. Method and apparatus for managing a firewall
US20030126290A1 (en) * 2001-12-03 2003-07-03 Lakshmi Narayanan Ram Gopal Context filter in a mobile node
US20030135749A1 (en) * 2001-10-31 2003-07-17 Gales George S. System and method of defining the security vulnerabilities of a computer system
US6618736B1 (en) 2001-03-09 2003-09-09 Ensim Corporation Template-based creation and archival of file systems
US20030177383A1 (en) * 2002-03-16 2003-09-18 Yoram Ofek Management of trusted flow system
US6625147B1 (en) * 1998-09-08 2003-09-23 Fujitsu Limited Communications network control system
US20030179244A1 (en) * 2002-03-01 2003-09-25 Ulfar Erlingsson Method and system for assured denotation of application semantics
US20030233544A1 (en) * 2002-05-13 2003-12-18 Ulfar Erlingsson Methods and systems for providing a secure application environment using derived user accounts
US6687833B1 (en) * 1999-09-24 2004-02-03 Networks Associates, Inc. System and method for providing a network host decoy using a pseudo network protocol stack implementation
US6711607B1 (en) 2000-02-04 2004-03-23 Ensim Corporation Dynamic scheduling of task streams in a multiple-resource system to ensure task stream quality of service
US6718385B1 (en) 2000-05-19 2004-04-06 Galaxy Computer Services, Inc. System for controlling movement of information using an information diode between a source network and a destination network
US6732211B1 (en) 2000-09-18 2004-05-04 Ensim Corporation Intercepting I/O multiplexing operations involving cross-domain file descriptor sets
US6754716B1 (en) 2000-02-11 2004-06-22 Ensim Corporation Restricting communication between network devices on a common network
US6768999B2 (en) 1996-06-28 2004-07-27 Mirror Worlds Technologies, Inc. Enterprise, stream-based, information management system
US20040243520A1 (en) * 1999-08-31 2004-12-02 Bishop Fred Alan Methods and apparatus for conducting electronic transactions
US20040255146A1 (en) * 2003-04-30 2004-12-16 Asher Michael L. Program security through stack segregation
US20040268118A1 (en) * 2003-06-30 2004-12-30 Dario Bazan Bejarano System and method for automatic negotiation of a security protocol
US6907421B1 (en) 2000-05-16 2005-06-14 Ensim Corporation Regulating file access rates according to file type
US6909691B1 (en) 2000-08-07 2005-06-21 Ensim Corporation Fairly partitioning resources while limiting the maximum fair share
US20050169475A1 (en) * 2002-05-21 2005-08-04 France Telecom Method of controlling access to cryptographic resources
US6948003B1 (en) 2000-03-15 2005-09-20 Ensim Corporation Enabling a service provider to provide intranet services
US20050218940A1 (en) * 2004-03-31 2005-10-06 Mitsunobu Yoshida Waveform output device and drive device
US20050246545A1 (en) * 2002-09-13 2005-11-03 Richard Reiner Screening for illegitimate requests to a computer application
US6976258B1 (en) 1999-11-30 2005-12-13 Ensim Corporation Providing quality of service guarantees to virtual hosts
US6981155B1 (en) * 1999-07-14 2005-12-27 Symantec Corporation System and method for computer security
US6985937B1 (en) 2000-05-11 2006-01-10 Ensim Corporation Dynamically modifying the resources of a virtual server
US7143024B1 (en) 2000-07-07 2006-11-28 Ensim Corporation Associating identifiers with virtual processes
US20070061883A1 (en) * 1999-07-14 2007-03-15 Symantec Corporation System and method for generating fictitious content for a computer
US7219354B1 (en) 2000-12-22 2007-05-15 Ensim Corporation Virtualizing super-user privileges for multiple virtual processes
US20070157315A1 (en) * 1999-08-30 2007-07-05 Symantec Corporation System and method for using timestamps to detect attacks
US7343421B1 (en) 2000-02-14 2008-03-11 Digital Asset Enterprises Llc Restricting communication of selected processes to a set of specific network addresses
US7350078B1 (en) * 2001-04-26 2008-03-25 Gary Odom User selection of computer login
AU2004231226B2 (en) * 1999-08-31 2008-06-05 Lead Core Fund L.L.C Methods and apparatus for conducting electronic transactions
US20090064331A1 (en) * 1999-07-14 2009-03-05 Symantec Corporation System and method for preventing detection of a selected process running on a computer
US20100037220A1 (en) * 2008-08-05 2010-02-11 International Business Machines Corporation System and Method for Creating and Associating a Virtual Pseudo TTY with a Running Process
US20100050077A1 (en) * 2005-01-14 2010-02-25 Paul Ryman Methods and Systems for In-Session Playback on a Local Machine of Remotely-Stored and Real Time Presentation Layer Protocol Data
US20100049783A1 (en) * 2005-01-14 2010-02-25 Paul Ryman Methods and Systems for Joining a Real-Time Session of Presentation Layer Protocol Data
US7698713B2 (en) 2001-09-20 2010-04-13 Google Inc. Altered states of software component behavior
US20100250666A1 (en) * 1999-07-26 2010-09-30 Microsoft Corporation Apparatus and computer-readable media for processing http requests
US20110191249A1 (en) * 1999-08-31 2011-08-04 American Express Travel Related Services Company, Inc. Methods and Apparatus for Conducting Electronic Transactions
US8024541B2 (en) 2005-03-25 2011-09-20 Elliptic Technologies Inc. Packet memory processing system having memory buffers with different architectures and method therefor
US8261095B1 (en) 2001-11-01 2012-09-04 Google Inc. Methods and systems for using derived user accounts
US8635447B1 (en) * 2010-12-23 2014-01-21 Emc Corporation Managing certificates between software environments
US20140325326A1 (en) * 2003-02-13 2014-10-30 Bruce Zak System and Method for Managing Content on a Network Interface
US8958284B2 (en) 2011-06-16 2015-02-17 St-Ericsson Sa Port number reservation agent
US8984644B2 (en) 2003-07-01 2015-03-17 Securityprofiling, Llc Anti-vulnerability system, method, and computer program product
US9100431B2 (en) 2003-07-01 2015-08-04 Securityprofiling, Llc Computer program product and apparatus for multi-path remediation
US9118710B2 (en) 2003-07-01 2015-08-25 Securityprofiling, Llc System, method, and computer program product for reporting an occurrence in different manners
US9117069B2 (en) 2003-07-01 2015-08-25 Securityprofiling, Llc Real-time vulnerability monitoring
US9118711B2 (en) 2003-07-01 2015-08-25 Securityprofiling, Llc Anti-vulnerability system, method, and computer program product
US9118708B2 (en) 2003-07-01 2015-08-25 Securityprofiling, Llc Multi-path remediation
US9118709B2 (en) 2003-07-01 2015-08-25 Securityprofiling, Llc Anti-vulnerability system, method, and computer program product
US9350752B2 (en) 2003-07-01 2016-05-24 Securityprofiling, Llc Anti-vulnerability system, method, and computer program product
US9705752B2 (en) 2015-01-29 2017-07-11 Blackrock Financial Management, Inc. Reliably updating a messaging system
US9954873B2 (en) * 2015-09-30 2018-04-24 The Mitre Corporation Mobile device-based intrusion prevention system
US10218756B2 (en) * 2012-01-06 2019-02-26 Comcast Cable Communications, Llc Streamlined delivery of video content
US10348867B1 (en) * 2015-09-30 2019-07-09 EMC IP Holding Company LLC Enhanced protocol socket domain
US20210218750A1 (en) * 2020-01-09 2021-07-15 Cisco Technology, Inc. Providing multiple namespaces
US11140084B2 (en) * 2000-11-02 2021-10-05 Oracle America, Inc. TCP/UDP acceleration

Families Citing this family (35)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6185598B1 (en) 1998-02-10 2001-02-06 Digital Island, Inc. Optimized network resource location
US8060613B2 (en) 1998-02-10 2011-11-15 Level 3 Communications, Llc Resource invalidation in a content delivery network
US6108703A (en) 1998-07-14 2000-08-22 Massachusetts Institute Of Technology Global hosting system
IL127569A0 (en) 1998-09-16 1999-10-28 Comsense Technologies Ltd Interactive toys
US6607136B1 (en) 1998-09-16 2003-08-19 Beepcard Inc. Physical presence digital authentication system
US7334735B1 (en) 1998-10-02 2008-02-26 Beepcard Ltd. Card for interaction with a computer
US6658450B1 (en) * 1999-01-29 2003-12-02 Avaya Technology Corp. Method and system for memory resident transient storage of data associated with a plurality of collaborating computer processes
US6275470B1 (en) 1999-06-18 2001-08-14 Digital Island, Inc. On-demand overlay routing for computer-based communication networks
US8019609B2 (en) 1999-10-04 2011-09-13 Dialware Inc. Sonic/ultrasonic authentication method
US8543901B1 (en) 1999-11-01 2013-09-24 Level 3 Communications, Llc Verification of content stored in a network
US7765581B1 (en) 1999-12-10 2010-07-27 Oracle America, Inc. System and method for enabling scalable security in a virtual private network
US6941362B2 (en) * 2000-04-28 2005-09-06 Sheer Networks Inc. Root cause analysis in a distributed network management architecture
US8266677B2 (en) * 2000-12-20 2012-09-11 Intellisync Corporation UDP communication with a programmer interface over wireless networks
US7673133B2 (en) * 2000-12-20 2010-03-02 Intellisync Corporation Virtual private network between computing network and remote device
US9219708B2 (en) * 2001-03-22 2015-12-22 DialwareInc. Method and system for remotely authenticating identification devices
US20020154635A1 (en) * 2001-04-23 2002-10-24 Sun Microsystems, Inc. System and method for extending private networks onto public infrastructure using supernets
US7860964B2 (en) 2001-09-28 2010-12-28 Level 3 Communications, Llc Policy-based content delivery network selection
EP2290916B1 (en) 2001-09-28 2015-12-16 Level 3 CDN International, Inc. Configurable adaptive global traffic control and management
US7373644B2 (en) 2001-10-02 2008-05-13 Level 3 Communications, Llc Automated server replication
US20030079027A1 (en) 2001-10-18 2003-04-24 Michael Slocombe Content request routing and load balancing for content distribution networks
US7454750B2 (en) * 2001-10-19 2008-11-18 Amberpoint, Inc. Integrator adaptor and proxy based composite application provisioning method and apparatus
US7421736B2 (en) * 2002-07-02 2008-09-02 Lucent Technologies Inc. Method and apparatus for enabling peer-to-peer virtual private network (P2P-VPN) services in VPN-enabled network
US6826627B2 (en) * 2002-09-03 2004-11-30 Burnbag, Ltd. Data transformation architecture
US8136155B2 (en) * 2003-04-01 2012-03-13 Check Point Software Technologies, Inc. Security system with methodology for interprocess communication control
JP4448719B2 (en) * 2004-03-19 2010-04-14 株式会社日立製作所 Storage system
GB0408876D0 (en) * 2004-04-21 2004-05-26 Level 5 Networks Ltd User-level stack
US8788674B2 (en) * 2005-01-12 2014-07-22 Blue Coat Systems, Inc. Buffering proxy for telnet access
US7945676B2 (en) * 2005-03-10 2011-05-17 International Business Machines Corporation Processing requests transmitted using a first communication protocol directed to an application that uses a second communication protocol
US7819763B2 (en) * 2005-04-21 2010-10-26 Campbell Steven S Baseball batting trainer
US7634584B2 (en) 2005-04-27 2009-12-15 Solarflare Communications, Inc. Packet validation in virtual network interface architecture
US20070050681A1 (en) * 2005-08-25 2007-03-01 Derobertis Christopher V Global user services management for system cluster
CA2699514A1 (en) * 2007-09-14 2009-03-19 Softkvm, Llc Software method and system for controlling and observing computer networking devices
US9485218B2 (en) * 2010-03-23 2016-11-01 Adventium Enterprises, Llc Device for preventing, detecting and responding to security threats
CN109885309B (en) * 2019-01-14 2022-05-24 北京中科晶上科技股份有限公司 Method for generating configuration file for establishing protocol stack software
CN111931108A (en) * 2020-07-31 2020-11-13 福建深空信息技术有限公司 Safety net station updating method and system

Citations (56)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US3956615A (en) * 1974-06-25 1976-05-11 Ibm Corporation Transaction execution system with secure data storage and communications
US4104721A (en) * 1976-12-30 1978-08-01 International Business Machines Corporation Hierarchical security mechanism for dynamically assigning security levels to object programs
US4177510A (en) * 1973-11-30 1979-12-04 Compagnie Internationale pour l'Informatique, CII Honeywell Bull Protection of data in an information multiprocessing system by implementing a concept of rings to represent the different levels of privileges among processes
US4442484A (en) * 1980-10-14 1984-04-10 Intel Corporation Microprocessor memory management and protection mechanism
US4584639A (en) * 1983-12-23 1986-04-22 Key Logic, Inc. Computer security system
US4621321A (en) * 1984-02-16 1986-11-04 Honeywell Inc. Secure data processing system architecture
US4648031A (en) * 1982-06-21 1987-03-03 International Business Machines Corporation Method and apparatus for restarting a computing system
US4713753A (en) * 1985-02-21 1987-12-15 Honeywell Inc. Secure data processing system architecture with format control
US4870571A (en) * 1983-05-04 1989-09-26 The Johns Hopkins University Intercomputer communications based on message broadcasting with receiver selection
US4885789A (en) * 1988-02-01 1989-12-05 International Business Machines Corporation Remote trusted path mechanism for telnet
US5093914A (en) * 1989-12-15 1992-03-03 At&T Bell Laboratories Method of controlling the execution of object-oriented programs
US5124984A (en) * 1990-08-07 1992-06-23 Concord Communications, Inc. Access controller for local area network
US5153918A (en) * 1990-11-19 1992-10-06 Vorec Corporation Security system for data communications
US5204961A (en) * 1990-06-25 1993-04-20 Digital Equipment Corporation Computer network operating with multilevel hierarchical security with selectable common trust realms and corresponding security protocols
US5228083A (en) * 1991-06-28 1993-07-13 Digital Equipment Corporation Cryptographic processing in a communication network, using a single cryptographic engine
EP0554182A1 (en) * 1992-01-28 1993-08-04 Electricite De France Method, apparatus and device for message cyphering between interconnected networks
US5263147A (en) * 1991-03-01 1993-11-16 Hughes Training, Inc. System for providing high security for personal computers and workstations
US5272754A (en) * 1991-03-28 1993-12-21 Secure Computing Corporation Secure computer interface
US5276735A (en) * 1992-04-17 1994-01-04 Secure Computing Corporation Data enclave and trusted path system
US5303303A (en) * 1990-07-18 1994-04-12 Gpt Limited Data communication system using encrypted data packets
US5305385A (en) * 1991-10-15 1994-04-19 Ungermann-Bass, Inc. Network message security method and apparatus
US5311593A (en) * 1992-05-13 1994-05-10 Chipcom Corporation Security system for a network concentrator
US5329623A (en) * 1992-06-17 1994-07-12 The Trustees Of The University Of Pennsylvania Apparatus for providing cryptographic support in a network
US5355474A (en) * 1991-09-27 1994-10-11 Thuraisngham Bhavani M System for multilevel secure database management using a knowledge base with release-based and other security constraints for query, response and update modification
US5414833A (en) * 1993-10-27 1995-05-09 International Business Machines Corporation Network security system and method using a parallel finite state machine adaptive active monitor and responder
US5416842A (en) * 1994-06-10 1995-05-16 Sun Microsystems, Inc. Method and apparatus for key-management scheme for use with internet protocols at site firewalls
GB2287619A (en) * 1994-03-03 1995-09-20 Ibm Security device for data communications networks
US5485460A (en) * 1994-08-19 1996-01-16 Microsoft Corporation System and method for running multiple incompatible network protocol stacks
WO1996013113A1 (en) * 1994-10-12 1996-05-02 Secure Computing Corporation System and method for providing secure internetwork services
US5530758A (en) * 1994-06-03 1996-06-25 Motorola, Inc. Operational methods for a secure node in a computer network
US5548646A (en) * 1994-09-15 1996-08-20 Sun Microsystems, Inc. System for signatureless transmission and reception of data packets between computer networks
WO1996031035A1 (en) * 1995-03-29 1996-10-03 Cabletron Systems, Inc. Method and apparatus for policy-based alarm notification in a distributed network management environment
US5566170A (en) * 1994-12-29 1996-10-15 Storage Technology Corporation Method and apparatus for accelerated packet forwarding
EP0743777A2 (en) * 1995-05-18 1996-11-20 Sun Microsystems, Inc. System for packet filtering of data packets at a computer network interface
US5586260A (en) * 1993-02-12 1996-12-17 Digital Equipment Corporation Method and apparatus for authenticating a client to a server in computer systems which support different security mechanisms
US5606668A (en) * 1993-12-15 1997-02-25 Checkpoint Software Technologies Ltd. System for securing inbound and outbound data packet flow in a computer network
US5615340A (en) * 1994-07-21 1997-03-25 Allied Telesyn Int'l Corp. Network interfacing apparatus and method using repeater and cascade interface with scrambling
US5619648A (en) * 1994-11-30 1997-04-08 Lucent Technologies Inc. Message filtering techniques
WO1997013340A1 (en) * 1995-09-18 1997-04-10 Digital Secured Networks Technology, Inc. Network security device
US5623601A (en) * 1994-11-18 1997-04-22 Milkway Networks Corporation Apparatus and method for providing a secure gateway for communication and data exchanges between networks
WO1997016911A1 (en) * 1995-10-31 1997-05-09 International Business Machines Corporation Secured gateway interface
US5636371A (en) * 1995-06-07 1997-06-03 Bull Hn Information Systems Inc. Virtual network mechanism to access well known port application programs running on a single host system
US5644571A (en) * 1992-06-15 1997-07-01 Digital Equipment Corporation Apparatus for message filtering in a network using domain class
WO1997026735A1 (en) * 1996-01-16 1997-07-24 Raptor Systems, Inc. Key management for network communication
WO1997026734A1 (en) * 1996-01-16 1997-07-24 Raptor Systems, Inc. Transferring encrypted packets over a public network
WO1997026731A1 (en) * 1996-01-16 1997-07-24 Raptor Systems, Inc. Data encryption/decryption for network communication
WO1997029413A2 (en) * 1996-02-09 1997-08-14 Secure Computing Corporation System and method for achieving network separation
US5671279A (en) * 1995-11-13 1997-09-23 Netscape Communications Corporation Electronic commerce using a secure courier system
US5673322A (en) * 1996-03-22 1997-09-30 Bell Communications Research, Inc. System and method for providing protocol translation and filtering to access the world wide web from wireless or low-bandwidth networks
US5684951A (en) * 1996-03-20 1997-11-04 Synopsys, Inc. Method and system for user authorization over a multi-user computer system
US5689566A (en) * 1995-10-24 1997-11-18 Nguyen; Minhtam C. Network with secure communications sessions
US5699513A (en) * 1995-03-31 1997-12-16 Motorola, Inc. Method for secure network access via message intercept
US5706507A (en) * 1995-07-05 1998-01-06 International Business Machines Corporation System and method for controlling access to data located on a content server
US5708780A (en) * 1995-06-07 1998-01-13 Open Market, Inc. Internet server access control and monitoring systems
US5720035A (en) * 1994-11-21 1998-02-17 France Telecom System for control of access to computer machines which are connected in a private network
US5781550A (en) * 1996-02-02 1998-07-14 Digital Equipment Corporation Transparent and secure network gateway

Family Cites Families (26)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
FR2558321A1 (en) 1984-01-13 1985-07-19 Philips Ind Commerciale PROGRAMMABLE DEVICE FOR DETERMINISTIC FILTERING OF MESSAGES
US4914568A (en) 1986-10-24 1990-04-03 National Instruments, Inc. Graphical system for modelling a process and associated method
US4888801A (en) 1988-05-02 1989-12-19 Motorola, Inc. Hierarchical key management system
US4914590A (en) 1988-05-18 1990-04-03 Emhart Industries, Inc. Natural language understanding system
JP2737173B2 (en) 1988-10-25 1998-04-08 日本電気株式会社 Symbol string collating device and its control method
GB8918553D0 (en) 1989-08-15 1989-09-27 Digital Equipment Int Message control system
JPH03117940A (en) 1989-09-25 1991-05-20 Internatl Business Mach Corp <Ibm> Method of managing electronic mail
JP2782683B2 (en) 1989-10-19 1998-08-06 三菱電機株式会社 Communication method and node device in LAN
US5276789A (en) 1990-05-14 1994-01-04 Hewlett-Packard Co. Graphic display of network topology
US5251131A (en) 1991-07-31 1993-10-05 Thinking Machines Corporation Classification of data records by comparison of records to a training database using probability weights
US5555346A (en) 1991-10-04 1996-09-10 Beyond Corporated Event-driven rule-based messaging system
US5333266A (en) 1992-03-27 1994-07-26 International Business Machines Corporation Method and apparatus for message handling in computer systems
US5359659A (en) 1992-06-19 1994-10-25 Doren Rosenthal Method for securing software against corruption by computer viruses
IL102843A (en) 1992-08-17 1996-06-18 Zisapel Yehuda Carrier sensing multiple access/collision detection local area networks
GB9220404D0 (en) 1992-08-20 1992-11-11 Nat Security Agency Method of identifying,retrieving and sorting documents
US5548507A (en) 1994-03-14 1996-08-20 International Business Machines Corporation Language identification process using coded language words
US5511122A (en) 1994-06-03 1996-04-23 The United States Of America As Represented By The Secretary Of The Navy Intermediate network authentication
US5724425A (en) 1994-06-10 1998-03-03 Sun Microsystems, Inc. Method and apparatus for enhancing software security and distributing software
US5604490A (en) 1994-09-09 1997-02-18 International Business Machines Corporation Method and system for providing a user access to multiple secured subsystems
US5550984A (en) 1994-12-07 1996-08-27 Matsushita Electric Corporation Of America Security system for preventing unauthorized communications between networks by translating communications received in ip protocol to non-ip protocol to remove address and routing services information
US5717913A (en) 1995-01-03 1998-02-10 University Of Central Florida Method for detecting and extracting text data using database schemas
US5634084A (en) 1995-01-20 1997-05-27 Centigram Communications Corporation Abbreviation and acronym/initialism expansion procedures for a text to speech reader
US5715466A (en) 1995-02-14 1998-02-03 Compuserve Incorporated System for parallel foreign language communication over a computer network
GB2316588B (en) 1995-05-08 2000-05-31 Compuserve Inc Rules based electronic message management system
US5632011A (en) 1995-05-22 1997-05-20 Sterling Commerce, Inc. Electronic mail management system for operation on a host computer system
US5602918A (en) 1995-12-22 1997-02-11 Virtual Open Network Environment Corp. Application level security system and method

Patent Citations (57)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4177510A (en) * 1973-11-30 1979-12-04 Compagnie Internationale pour l'Informatique, CII Honeywell Bull Protection of data in an information multiprocessing system by implementing a concept of rings to represent the different levels of privileges among processes
US3956615A (en) * 1974-06-25 1976-05-11 Ibm Corporation Transaction execution system with secure data storage and communications
US4104721A (en) * 1976-12-30 1978-08-01 International Business Machines Corporation Hierarchical security mechanism for dynamically assigning security levels to object programs
US4442484A (en) * 1980-10-14 1984-04-10 Intel Corporation Microprocessor memory management and protection mechanism
US4648031A (en) * 1982-06-21 1987-03-03 International Business Machines Corporation Method and apparatus for restarting a computing system
US4870571A (en) * 1983-05-04 1989-09-26 The Johns Hopkins University Intercomputer communications based on message broadcasting with receiver selection
US4584639A (en) * 1983-12-23 1986-04-22 Key Logic, Inc. Computer security system
US4621321A (en) * 1984-02-16 1986-11-04 Honeywell Inc. Secure data processing system architecture
US4701840A (en) * 1984-02-16 1987-10-20 Honeywell Inc. Secure data processing system architecture
US4713753A (en) * 1985-02-21 1987-12-15 Honeywell Inc. Secure data processing system architecture with format control
US4885789A (en) * 1988-02-01 1989-12-05 International Business Machines Corporation Remote trusted path mechanism for telnet
US5093914A (en) * 1989-12-15 1992-03-03 At&T Bell Laboratories Method of controlling the execution of object-oriented programs
US5204961A (en) * 1990-06-25 1993-04-20 Digital Equipment Corporation Computer network operating with multilevel hierarchical security with selectable common trust realms and corresponding security protocols
US5303303A (en) * 1990-07-18 1994-04-12 Gpt Limited Data communication system using encrypted data packets
US5124984A (en) * 1990-08-07 1992-06-23 Concord Communications, Inc. Access controller for local area network
US5153918A (en) * 1990-11-19 1992-10-06 Vorec Corporation Security system for data communications
US5263147A (en) * 1991-03-01 1993-11-16 Hughes Training, Inc. System for providing high security for personal computers and workstations
US5272754A (en) * 1991-03-28 1993-12-21 Secure Computing Corporation Secure computer interface
US5228083A (en) * 1991-06-28 1993-07-13 Digital Equipment Corporation Cryptographic processing in a communication network, using a single cryptographic engine
US5355474A (en) * 1991-09-27 1994-10-11 Thuraisngham Bhavani M System for multilevel secure database management using a knowledge base with release-based and other security constraints for query, response and update modification
US5305385A (en) * 1991-10-15 1994-04-19 Ungermann-Bass, Inc. Network message security method and apparatus
EP0554182A1 (en) * 1992-01-28 1993-08-04 Electricite De France Method, apparatus and device for message cyphering between interconnected networks
US5276735A (en) * 1992-04-17 1994-01-04 Secure Computing Corporation Data enclave and trusted path system
US5311593A (en) * 1992-05-13 1994-05-10 Chipcom Corporation Security system for a network concentrator
US5644571A (en) * 1992-06-15 1997-07-01 Digital Equipment Corporation Apparatus for message filtering in a network using domain class
US5329623A (en) * 1992-06-17 1994-07-12 The Trustees Of The University Of Pennsylvania Apparatus for providing cryptographic support in a network
US5586260A (en) * 1993-02-12 1996-12-17 Digital Equipment Corporation Method and apparatus for authenticating a client to a server in computer systems which support different security mechanisms
US5414833A (en) * 1993-10-27 1995-05-09 International Business Machines Corporation Network security system and method using a parallel finite state machine adaptive active monitor and responder
US5606668A (en) * 1993-12-15 1997-02-25 Checkpoint Software Technologies Ltd. System for securing inbound and outbound data packet flow in a computer network
GB2287619A (en) * 1994-03-03 1995-09-20 Ibm Security device for data communications networks
US5530758A (en) * 1994-06-03 1996-06-25 Motorola, Inc. Operational methods for a secure node in a computer network
US5416842A (en) * 1994-06-10 1995-05-16 Sun Microsystems, Inc. Method and apparatus for key-management scheme for use with internet protocols at site firewalls
US5615340A (en) * 1994-07-21 1997-03-25 Allied Telesyn Int'l Corp. Network interfacing apparatus and method using repeater and cascade interface with scrambling
US5485460A (en) * 1994-08-19 1996-01-16 Microsoft Corporation System and method for running multiple incompatible network protocol stacks
US5548646A (en) * 1994-09-15 1996-08-20 Sun Microsystems, Inc. System for signatureless transmission and reception of data packets between computer networks
WO1996013113A1 (en) * 1994-10-12 1996-05-02 Secure Computing Corporation System and method for providing secure internetwork services
US5623601A (en) * 1994-11-18 1997-04-22 Milkway Networks Corporation Apparatus and method for providing a secure gateway for communication and data exchanges between networks
US5720035A (en) * 1994-11-21 1998-02-17 France Telecom System for control of access to computer machines which are connected in a private network
US5619648A (en) * 1994-11-30 1997-04-08 Lucent Technologies Inc. Message filtering techniques
US5566170A (en) * 1994-12-29 1996-10-15 Storage Technology Corporation Method and apparatus for accelerated packet forwarding
WO1996031035A1 (en) * 1995-03-29 1996-10-03 Cabletron Systems, Inc. Method and apparatus for policy-based alarm notification in a distributed network management environment
US5699513A (en) * 1995-03-31 1997-12-16 Motorola, Inc. Method for secure network access via message intercept
EP0743777A2 (en) * 1995-05-18 1996-11-20 Sun Microsystems, Inc. System for packet filtering of data packets at a computer network interface
US5636371A (en) * 1995-06-07 1997-06-03 Bull Hn Information Systems Inc. Virtual network mechanism to access well known port application programs running on a single host system
US5708780A (en) * 1995-06-07 1998-01-13 Open Market, Inc. Internet server access control and monitoring systems
US5706507A (en) * 1995-07-05 1998-01-06 International Business Machines Corporation System and method for controlling access to data located on a content server
WO1997013340A1 (en) * 1995-09-18 1997-04-10 Digital Secured Networks Technology, Inc. Network security device
US5689566A (en) * 1995-10-24 1997-11-18 Nguyen; Minhtam C. Network with secure communications sessions
WO1997016911A1 (en) * 1995-10-31 1997-05-09 International Business Machines Corporation Secured gateway interface
US5671279A (en) * 1995-11-13 1997-09-23 Netscape Communications Corporation Electronic commerce using a secure courier system
WO1997026735A1 (en) * 1996-01-16 1997-07-24 Raptor Systems, Inc. Key management for network communication
WO1997026731A1 (en) * 1996-01-16 1997-07-24 Raptor Systems, Inc. Data encryption/decryption for network communication
WO1997026734A1 (en) * 1996-01-16 1997-07-24 Raptor Systems, Inc. Transferring encrypted packets over a public network
US5781550A (en) * 1996-02-02 1998-07-14 Digital Equipment Corporation Transparent and secure network gateway
WO1997029413A2 (en) * 1996-02-09 1997-08-14 Secure Computing Corporation System and method for achieving network separation
US5684951A (en) * 1996-03-20 1997-11-04 Synopsys, Inc. Method and system for user authorization over a multi-user computer system
US5673322A (en) * 1996-03-22 1997-09-30 Bell Communications Research, Inc. System and method for providing protocol translation and filtering to access the world wide web from wireless or low-bandwidth networks

Non-Patent Citations (96)

* Cited by examiner, † Cited by third party
Title
"Answers to Frequently Asked Questions About Network Security", Secure Computing Corporation, pp. 1-41 & pp. 1-16, (Date unavailable).
"Copy of PCT Search Report", Application No. PCT/US95/12681, 8 pages, (Apr. 9, 1996).
"Sidewinder Internals", Product information, Secure Computing Corporation, 16 pp. 1-15 (Oct. 1994).
"Special Report: Secure Computing Corporation and Network Security", Computer Select, 13 p. (Dec. 1995).
Ancilotti, P., et al., "Language Features for Access Control", IEEE Transactions on Software Engineering, SE-9, 16-25 (Jan. 1983).
Ancilotti, P., et al., Language Features for Access Control , IEEE Transactions on Software Engineering, SE 9 , 16 25 (Jan. 1983). *
Answers to Frequently Asked Questions About Network Security , Secure Computing Corporation , pp. 1 41 & pp. 1 16, (Date unavailable). *
B. B. Dillaway, et al., "A Practical Design For A Multilevel Secure Database Management System", American Institute of Aeronautics and Astronautics, Inc., pp. 44-57, (Dec. 1986).
B. B. Dillaway, et al., A Practical Design For A Multilevel Secure Database Management System , American Institute of Aeronautics and Astronautics, Inc. , pp. 44 57, (Dec. 1986). *
Cobb, S., "Establishing Firewall Policy", IEEE, 198-205, (1996).
Cobb, S., Establishing Firewall Policy , IEEE , 198 205, (1996). *
Commun. of the ACM , vol. 35, p. 28, (Dec. 1992). *
Commun. of the ACM, vol. 35, p. 28, (Dec. 1992).
Copy of PCT Search Report , Application No. PCT/US95/12681 , 8 pages, (Apr. 9, 1996). *
D. Goldberg, et al., "Using collaborative filtering to weave an information tapestry", Commun. of the ACM, vol. 35, p. 61, (1992).
D. Goldberg, et al., Using collaborative filtering to weave an information tapestry , Commun. of the ACM , vol. 35, p. 61, (1992). *
Damashek, M., "Guaging Similarity with n-Grams: Language-Independent Categorization of Text", Science, 267, 843-848 (Feb. 10, 1995).
Damashek, M., Guaging Similarity with n Grams: Language Independent Categorization of Text , Science, 267 , 843 848 (Feb. 10, 1995). *
F. T. Grampp, "Unix Operating System Security", AT&T Bell Laboratories Technical Journal, vol. 63, No. 8, 1649-1672, (Oct. 1984).
F. T. Grampp, Unix Operating System Security , AT&T Bell Laboratories Technical Journal , vol. 63, No. 8, 1649 1672, (Oct. 1984). *
Gassman, B., "Internet Security, and Firewalls Protection on the Internets", IEEE, 93-107 (1996).
Gassman, B., Internet Security, and Firewalls Protection on the Internets , IEEE , 93 107 (1996). *
Greenwald, M., et al., "Designing an Academic Firewall: Policy, Practice, and Experience with SURF", IEEE, 79-92 (1996).
Greenwald, M., et al., Designing an Academic Firewall: Policy, Practice, and Experience with SURF , IEEE , 79 92 (1996). *
J. A. Adam, "Meta-matrices", IEEE Spectrum, p. 26, (Oct. 1992).
J. A. Adam, "Playing on the net", IEEE Spectrum, 29 (Oct. 1992).
J. A. Adam, Meta matrices , IEEE Spectrum , p. 26, (Oct. 1992). *
J. A. Adam, Playing on the net , IEEE Spectrum, 29 ( Oct. 1992 ). *
J. Bryan, "Firewalls For Sale", BYTE, 99-100, 102, 104-105, (Apr. 1995).
J. Bryan, Firewalls For Sale , BYTE , 99 100, 102, 104 105, (Apr. 1995). *
J. Thomas Haigh, et al., "Extending the Noninterference Version of MLS", IEEE Transactions on Software Engineering, vol. SE-13, No. 2, pp. 141-150, (Feb., 1987).
J. Thomas Haigh, et al., Extending the Noninterference Version of MLS , IEEE Transactions on Software Engineering , vol. SE 13, No. 2, pp. 141 150, (Feb., 1987). *
K. Lee, et al., "A framework for controlling cooperative agents", Computer, p. 8, (1993).
K. Lee, et al., A framework for controlling cooperative agents , Computer , p. 8, (1993). *
K. Obraczka, et al., "Internet resource discovery services", Computer, p. 8, (Sep., 1993).
K. Obraczka, et al., Internet resource discovery services , Computer , p. 8, (Sep., 1993). *
Karn, P., et al., "The ESP DES-CBC Transform", Network Working Group, Request for Comment No. 1829, http//ds.internic.net/rfc/rfc1829.txt, 9 pp. 1-9 (Aug. 1995).
Karn, P., et al., The ESP DES CBC Transform , Network Working Group, Request for Comment No. 1829, http//ds.internic.net/rfc/rfc1829.txt, 9 pp. 1 9 (Aug. 1995). *
L. Press, "The net: progress and opportunity", Commun. of the ACM, vol. 35, p. 21, (1992).
L. Press, The net: progress and opportunity , Commun. of the ACM , vol. 35, p. 21, (1992). *
Lampson, B.W., et al., "Dynamic Protection Structures", AFIPS Conference Proceedings, 35, 1969 Fall Joint Computer Conference, Las Vegas, NV, 27-38 (Nov. 18-20, 1969).
Lampson, B.W., et al., Dynamic Protection Structures , AFIPS Conference Proceedings, 35 , 1969 Fall Joint Computer Conference, Las Vegas, NV, 27 38 (Nov. 18 20, 1969). *
Lee Badger, et al., "Practical Domain and Type Enforcement for UNIX", 1995 IEEE Symposium on Security and Privacy, pp. 66-77, (May, 1995).
Lee Badger, et al., Practical Domain and Type Enforcement for UNIX , 1995 IEEE Symposium on Security and Privacy , pp. 66 77, (May, 1995). *
M. F. Schwartz, "Internet resource discovery at the University of Colorado", Computer, p. 25, (Sep. 1993).
M. F. Schwartz, Internet resource discovery at the University of Colorado , Computer , p. 25, (Sep. 1993). *
McCarthy, S.P., "Hey Hackers| Secure Computing Says You Can't Break into This Telnet Site", Computer Select, 2 p. (Dec. 1995).
McCarthy, S.P., Hey Hackers Secure Computing Says You Can t Break into This Telnet Site , Computer Select , 2 p. (Dec. 1995). *
Metzger, P., et al., "IP Authentication using Keyed MD5", Network Working Group, Request for Comments No. 1828, http//ds.internic.net/rfc/rfc 1828.txt, 5 p. (Aug. 1995).
Metzger, P., et al., IP Authentication using Keyed MD5 , Network Working Group, Request for Comments No. 1828, http//ds.internic.net/rfc/rfc 1828.txt, 5 p. (Aug. 1995). *
N. J. Belkin, et al., "Information filtering and information retrieval: Two sides of the same coin?", Commun. of the ACM, vol. 35, p. 29, (1992).
N. J. Belkin, et al., Information filtering and information retrieval: Two sides of the same coin , Commun. of the ACM , vol. 35, p. 29, (1992). *
New Release: "100% of Hackers Failed to Break Into One Internet Site Protected by Sidewinder™", Secure Computing Corporation (Feb. 16, 1995).
New Release: 100% of Hackers Failed to Break Into One Internet Site Protected by Sidewinder , Secure Computing Corporation (Feb. 16, 1995). *
News Release: "Internet Security System Given `Product of the Year` Award", Secure Computing Corporation (Mar. 28, 1995).
News Release: "SATAN No Threat to Sidewinder™", Secure Computing Corporation (Apr. 26, 1995).
News Release: Internet Security System Given Product of the Year Award , Secure Computing Corporation (Mar. 28, 1995). *
News Release: SATAN No Threat to Sidewinder , Secure Computing Corporation (Apr. 26, 1995). *
P. W. Foltz, et al., "Personalized information delivery: an analysis of information filtering methods", Commun. of the ACM, vol. 35, p. 51, (1992).
P. W. Foltz, et al., Personalized information delivery: an analysis of information filtering methods , Commun. of the ACM , vol. 35, p. 51, (1992). *
Peterson, L.L., et al., In: Computer Networks , Morgan Kaufman Publishers, Inc., San Francisco, CA, pp. 218 221, 284 286 (1996). *
Peterson, L.L., et al., In: Computer Networks, Morgan Kaufman Publishers, Inc., San Francisco, CA, pp. 218-221, 284-286 (1996).
Richard E. Smith, "Sidewinder: Defense in Depth Using Type Enforcement", International Journal of Network Management, pp. 219-229, (Jul.-Aug. 1995).
Richard E. Smith, Sidewinder: Defense in Depth Using Type Enforcement , International Journal of Network Management , pp. 219 229, (Jul. Aug. 1995). *
S. Loeb, "Architecting personalized delivery of multimedia information", Commun. of the ACM, 35, 39 (1992).
S. Loeb, Architecting personalized delivery of multimedia information , Commun. of the ACM, 35, 39 (1992). *
S. M. Bellovin, et al., "Network Firewalls", IEEE Communications Magazine, vol. 32, 9 pages, (Sep. 1994).
S. M. Bellovin, et al., Network Firewalls , IEEE Communications Magazine , vol. 32, 9 pages, (Sep. 1994). *
S. T. Kent, "Internet privacy enhanced mail", Commun. of the ACM, vol. 36, p. 48, (1993).
S. T. Kent, Internet privacy enhanced mail , Commun. of the ACM , vol. 36, p. 48, (1993). *
Schroeder, M.D., et al., "A Hardware Architecture for Implementing Protection Rings", Communications of the ACM, 15, 157-170 (Mar. 1972).
Schroeder, M.D., et al., A Hardware Architecture for Implementing Protection Rings , Communications of the ACM , 15, 157 170 (Mar. 1972). *
Sidewinder Internals , Product information, Secure Computing Corporation, 16 pp. 1 15 (Oct. 1994). *
Smith, R.E., "Constructing a High Assurance Mail Guard", Secure Computing Corporation (Appeared in the Proceedings of the National Computer Security Conference), 7 p. (1994).
Smith, R.E., Constructing a High Assurance Mail Guard , Secure Computing Corporation (Appeared in the Proceedings of the National Computer Security Conference), 7 p. (1994). *
Special Report: Secure Computing Corporation and Network Security , Computer Select , 13 p. (Dec. 1995). *
Stadnyk, I., et al., "Modeling User's Interests in Information Filters", Communications of the ACM, 35 39-50 (Dec. 1992).
Stadnyk, I., et al., Modeling User s Interests in Information Filters , Communications of the ACM , 35 39 50 (Dec. 1992). *
Stempel, S., "IpAccess--An Internet Service Access System for Firewall Installations", IEEE, 31-41 (1995).
Stempel, S., IpAccess An Internet Service Access System for Firewall Installations , IEEE , 31 41 (1995). *
Stevens, S., "Automating the Creation of Information Filters", Communications of the ACM, 35, 48 (Dec. 1992).
Stevens, S., Automating the Creation of Information Filters , Communications of the ACM , 35, 48 (Dec. 1992). *
T. F. Bowen, et al., "The datacycle architecture", Commun. of the ACM, 35, 71 (1992).
T. F. Bowen, et al., The datacycle architecture , Commun. of the ACM, 35, 71 ( 1992 ). *
Todd Fine, et al., "Asssuring Distributed Trusted Mach", IEEE Computer Society Symposium on Research in Security and Privacy, pp. 206-218, (1993).
Todd Fine, et al., Asssuring Distributed Trusted Mach , IEEE Computer Society Symposium on Research in Security and Privacy , pp. 206 218, (1993). *
Warrier, U.S., et al., "A Platform for Heterogenous Interconnection Network Management", IEEE Journal on Selected Areas in Communications, 8, 119-126 (Jan. 1990).
Warrier, U.S., et al., A Platform for Heterogenous Interconnection Network Management , IEEE Journal on Selected Areas in Communications , 8, 119 126 (Jan. 1990). *
White, L.J., et al., "A Firewall Concept for Both Control-Flow and Data-Flow in Regression Integration Testing", IEEE, 262-271 (1992).
White, L.J., et al., A Firewall Concept for Both Control Flow and Data Flow in Regression Integration Testing , IEEE , 262 271 (1992). *
William R. Bevier, et al., "Connection Policies and Controlled Interference", The Eighth IEEE Computer Security Foundations Workshop, IEEE Computer Society Technical Committee on Security and Privacy, pp. 167-176, (Jun., 1995).
William R. Bevier, et al., Connection Policies and Controlled Interference , The Eighth IEEE Computer Security Foundations Workshop , IEEE Computer Society Technical Committee on Security and Privacy, pp. 167 176, (Jun., 1995). *
Wolfe, A., "Honeywell Builds Hardware for Computer Security", Electronics, 14-15 (Sep. 2, 1985).
Wolfe, A., Honeywell Builds Hardware for Computer Security , Electronics , 14 15 (Sep. 2, 1985). *
Yuet C. Lee, et al., "Multimedia: Full-Service Impact on Business, Education, and the Home", SPIE--The International Society for Optical Engineering, vol. 2617, pp. 143-150, (Oct. 1995).
Yuet C. Lee, et al., Multimedia: Full Service Impact on Business, Education, and the Home , SPIE The International Society for Optical Engineering , vol. 2617, pp. 143 150, (Oct. 1995). *

Cited By (140)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6768999B2 (en) 1996-06-28 2004-07-27 Mirror Worlds Technologies, Inc. Enterprise, stream-based, information management system
US20020023037A1 (en) * 1997-08-22 2002-02-21 White Newton B. Exchange method and apparatus
US6357010B1 (en) * 1998-02-17 2002-03-12 Secure Computing Corporation System and method for controlling access to documents stored on an internal network
US20040003293A1 (en) * 1998-02-17 2004-01-01 Secure Computing Corporation System and method for controlling access to documents stored on an internal network
US7543329B2 (en) 1998-02-17 2009-06-02 Secure Computing Corporation System and method for controlling access to documents stored on an internal network
US6640307B2 (en) 1998-02-17 2003-10-28 Secure Computing Corporation System and method for controlling access to documents stored on an internal network
US6226694B1 (en) * 1998-04-29 2001-05-01 Hewlett-Packard Company Achieving consistency and synchronization among multiple data stores that cooperate within a single system in the absence of transaction monitoring
US6405367B1 (en) * 1998-06-05 2002-06-11 Hewlett-Packard Company Apparatus and method for increasing the performance of Java programs running on a server
US6625147B1 (en) * 1998-09-08 2003-09-23 Fujitsu Limited Communications network control system
US20030120955A1 (en) * 1999-01-29 2003-06-26 Lucent Technologies Inc. Method and apparatus for managing a firewall
US20060288409A1 (en) * 1999-01-29 2006-12-21 Yair Bartal Method and apparatus for managing a firewall
US7146639B2 (en) 1999-01-29 2006-12-05 Lucent Technologies Inc. Method and apparatus for managing a firewall
US6981155B1 (en) * 1999-07-14 2005-12-27 Symantec Corporation System and method for computer security
US8549640B2 (en) 1999-07-14 2013-10-01 Symantec Corporation System and method for computer security
US20090064331A1 (en) * 1999-07-14 2009-03-05 Symantec Corporation System and method for preventing detection of a selected process running on a computer
US20070061883A1 (en) * 1999-07-14 2007-03-15 Symantec Corporation System and method for generating fictitious content for a computer
US7854005B2 (en) 1999-07-14 2010-12-14 Symantec Corporation System and method for generating fictitious content for a computer
US20080141349A1 (en) * 1999-07-14 2008-06-12 Symantec Corporation System and method for computer security
US7827605B2 (en) 1999-07-14 2010-11-02 Symantec Corporation System and method for preventing detection of a selected process running on a computer
US8103720B2 (en) * 1999-07-26 2012-01-24 Microsoft Corporation Apparatus and computer-readable media for processing HTTP requests
US20100250666A1 (en) * 1999-07-26 2010-09-30 Microsoft Corporation Apparatus and computer-readable media for processing http requests
US8359391B2 (en) * 1999-07-26 2013-01-22 Microsoft Corporation Apparatus and computer-readable media for processing HTTP requests determine scoping mapping between a mapped resource name extension and a content type
US8578490B2 (en) 1999-08-30 2013-11-05 Symantec Corporation System and method for using timestamps to detect attacks
US20070157315A1 (en) * 1999-08-30 2007-07-05 Symantec Corporation System and method for using timestamps to detect attacks
US20110191248A1 (en) * 1999-08-31 2011-08-04 American Express Travel Related Services Company, Inc. Methods and Apparatus for Conducting Electronic Transactions
US20110191250A1 (en) * 1999-08-31 2011-08-04 American Express Travel Related Services Company, Inc. Methods and Apparatus for Conducting Electronic Transactions
US8924310B2 (en) 1999-08-31 2014-12-30 Lead Core Fund, L.L.C. Methods and apparatus for conducting electronic transactions
US8214299B2 (en) * 1999-08-31 2012-07-03 American Express Travel Related Services Company, Inc. Methods and apparatus for conducting electronic transactions
US7801827B2 (en) * 1999-08-31 2010-09-21 American Express Travel Related Services Company, Inc. Methods and apparatus for conducting electronic transactions
US9519894B2 (en) 1999-08-31 2016-12-13 Gula Consulting Limited Liability Company Methods and apparatus for conducting electronic transactions
US8938402B2 (en) 1999-08-31 2015-01-20 Lead Core Fund, L.L.C. Methods and apparatus for conducting electronic transactions
US8433658B2 (en) 1999-08-31 2013-04-30 American Express Travel Related Services Company, Inc. Methods and apparatus for conducting electronic transactions
US8489513B2 (en) 1999-08-31 2013-07-16 American Express Travel Related Services Company, Inc. Methods and apparatus for conducting electronic transactions
US20040243520A1 (en) * 1999-08-31 2004-12-02 Bishop Fred Alan Methods and apparatus for conducting electronic transactions
US20100312667A1 (en) * 1999-08-31 2010-12-09 American Express Travel Related Services Company, Inc. Methods and apparatus for conducting electronic transactions
AU2004231226B2 (en) * 1999-08-31 2008-06-05 Lead Core Fund L.L.C Methods and apparatus for conducting electronic transactions
US8423476B2 (en) 1999-08-31 2013-04-16 American Express Travel Related Services Company, Inc. Methods and apparatus for conducting electronic transactions
US20110191249A1 (en) * 1999-08-31 2011-08-04 American Express Travel Related Services Company, Inc. Methods and Apparatus for Conducting Electronic Transactions
WO2001022325A1 (en) * 1999-09-20 2001-03-29 Hwang Ivan Chung Shung System and methods for implementing e-commerce services
US6687833B1 (en) * 1999-09-24 2004-02-03 Networks Associates, Inc. System and method for providing a network host decoy using a pseudo network protocol stack implementation
US6976258B1 (en) 1999-11-30 2005-12-13 Ensim Corporation Providing quality of service guarantees to virtual hosts
USRE42214E1 (en) 1999-11-30 2011-03-08 Pawan Goyal Providing quality of service guarantees to virtual hosts
US6711607B1 (en) 2000-02-04 2004-03-23 Ensim Corporation Dynamic scheduling of task streams in a multiple-resource system to ensure task stream quality of service
US6529985B1 (en) 2000-02-04 2003-03-04 Ensim Corporation Selective interception of system calls
US6560613B1 (en) 2000-02-08 2003-05-06 Ensim Corporation Disambiguating file descriptors
US6754716B1 (en) 2000-02-11 2004-06-22 Ensim Corporation Restricting communication between network devices on a common network
US7343421B1 (en) 2000-02-14 2008-03-11 Digital Asset Enterprises Llc Restricting communication of selected processes to a set of specific network addresses
US7739401B2 (en) 2000-02-14 2010-06-15 Pawan Goyal Restricting communication of selected processes to a set of specific network addresses
US20080162730A1 (en) * 2000-02-14 2008-07-03 Digital Asset Enterprises, L.L.C. Restricting communication of selected processes to a set of specific network addresses
US20110238832A1 (en) * 2000-02-14 2011-09-29 Pawan Goyal Restricting communication of selected processes to a set of specific network addresses
US8489764B2 (en) 2000-02-14 2013-07-16 Digital Asset Enterprises, L.L.C. Restricting communication of selected processes to a set of specific network addresses
WO2001061473A1 (en) * 2000-02-16 2001-08-23 Watchguard Technologies, Inc. Computer security using dual functional security contexts
US6948003B1 (en) 2000-03-15 2005-09-20 Ensim Corporation Enabling a service provider to provide intranet services
USRE43051E1 (en) 2000-03-15 2011-12-27 Digital Asset Enterprises, L.L.C. Enabling a service provider to provide intranet services
USRE42726E1 (en) 2000-05-11 2011-09-20 Digital Asset Enterprises, L.L.C. Dynamically modifying the resources of a virtual server
USRE44686E1 (en) 2000-05-11 2013-12-31 Digital Asset Enterprises, L.L.C. Dynamically modifying the resources of a virtual server
US6985937B1 (en) 2000-05-11 2006-01-10 Ensim Corporation Dynamically modifying the resources of a virtual server
US6907421B1 (en) 2000-05-16 2005-06-14 Ensim Corporation Regulating file access rates according to file type
USRE44723E1 (en) 2000-05-16 2014-01-21 Digital Asset Enterprises, L.L.C. Regulating file access rates according to file type
US6718385B1 (en) 2000-05-19 2004-04-06 Galaxy Computer Services, Inc. System for controlling movement of information using an information diode between a source network and a destination network
US7143024B1 (en) 2000-07-07 2006-11-28 Ensim Corporation Associating identifiers with virtual processes
US6909691B1 (en) 2000-08-07 2005-06-21 Ensim Corporation Fairly partitioning resources while limiting the maximum fair share
US6732211B1 (en) 2000-09-18 2004-05-04 Ensim Corporation Intercepting I/O multiplexing operations involving cross-domain file descriptor sets
US11140084B2 (en) * 2000-11-02 2021-10-05 Oracle America, Inc. TCP/UDP acceleration
US20020194493A1 (en) * 2000-11-28 2002-12-19 Hewlett-Packard Company Demonstrating integrity of a compartment of a compartmented operating system
US9633206B2 (en) * 2000-11-28 2017-04-25 Hewlett-Packard Development Company, L.P. Demonstrating integrity of a compartment of a compartmented operating system
US20020103414A1 (en) * 2000-12-05 2002-08-01 Harrison Michael J. Condom with male genital desensitizer lubricant
USRE44210E1 (en) 2000-12-22 2013-05-07 Digital Asset Enterprises, L.L.C. Virtualizing super-user privileges for multiple virtual processes
US7219354B1 (en) 2000-12-22 2007-05-15 Ensim Corporation Virtualizing super-user privileges for multiple virtual processes
US20060004674A1 (en) * 2001-02-09 2006-01-05 International Business Machines Corporation System and method for maintaining customer privacy
US20020111920A1 (en) * 2001-02-09 2002-08-15 International Business Machines Corporation System and method for maintaining customer privacy
US7051006B2 (en) 2001-02-09 2006-05-23 International Business Machines Corporation System and method for maintaining customer privacy
US7222100B2 (en) 2001-02-09 2007-05-22 International Business Machines Corporation System and method for maintaining customer privacy
US6618736B1 (en) 2001-03-09 2003-09-09 Ensim Corporation Template-based creation and archival of file systems
US7350078B1 (en) * 2001-04-26 2008-03-25 Gary Odom User selection of computer login
US8429415B1 (en) 2001-04-26 2013-04-23 Tierra Intelectual Borinquen User-selectable signatures
WO2003001345A3 (en) * 2001-06-26 2003-11-06 Mirror Worlds Technologies Inc Stream-based enterprise and desktop information management systems
WO2003001345A2 (en) * 2001-06-26 2003-01-03 Mirror Worlds Technologies, Inc. Stream-based enterprise and desktop information management systems
US20030050036A1 (en) * 2001-09-07 2003-03-13 Hayduk Matthew A. Security services for wireless devices
US7698713B2 (en) 2001-09-20 2010-04-13 Google Inc. Altered states of software component behavior
US20030084318A1 (en) * 2001-10-31 2003-05-01 Schertz Richard L. System and method of graphically correlating data for an intrusion protection system
US20030084322A1 (en) * 2001-10-31 2003-05-01 Schertz Richard L. System and method of an OS-integrated intrusion detection and anti-virus system
US20030135749A1 (en) * 2001-10-31 2003-07-17 Gales George S. System and method of defining the security vulnerabilities of a computer system
US8261095B1 (en) 2001-11-01 2012-09-04 Google Inc. Methods and systems for using derived user accounts
US8875281B2 (en) 2001-11-01 2014-10-28 Google Inc Methods and systems for using derived user accounts
US9516032B2 (en) 2001-11-01 2016-12-06 Google Inc. Methods and systems for using derived user accounts
US8683578B2 (en) 2001-11-01 2014-03-25 Google Inc. Methods and systems for using derived user accounts
US20030126290A1 (en) * 2001-12-03 2003-07-03 Lakshmi Narayanan Ram Gopal Context filter in a mobile node
US20030115364A1 (en) * 2001-12-19 2003-06-19 Li Shu Camouflage of network traffic to resist attack
US7171493B2 (en) 2001-12-19 2007-01-30 The Charles Stark Draper Laboratory Camouflage of network traffic to resist attack
US20030179244A1 (en) * 2002-03-01 2003-09-25 Ulfar Erlingsson Method and system for assured denotation of application semantics
US7406542B2 (en) 2002-03-01 2008-07-29 Google Inc. Method and system for assured denotation of application semantics
US20030177383A1 (en) * 2002-03-16 2003-09-18 Yoram Ofek Management of trusted flow system
US7305704B2 (en) * 2002-03-16 2007-12-04 Trustedflow Systems, Inc. Management of trusted flow system
US20030233544A1 (en) * 2002-05-13 2003-12-18 Ulfar Erlingsson Methods and systems for providing a secure application environment using derived user accounts
US7191469B2 (en) 2002-05-13 2007-03-13 Green Border Technologies Methods and systems for providing a secure application environment using derived user accounts
US20050169475A1 (en) * 2002-05-21 2005-08-04 France Telecom Method of controlling access to cryptographic resources
US7496199B2 (en) * 2002-05-21 2009-02-24 France Telecom Method of controlling access to cryptographic resources
US20050246545A1 (en) * 2002-09-13 2005-11-03 Richard Reiner Screening for illegitimate requests to a computer application
US10606930B2 (en) 2003-02-13 2020-03-31 Bruce Zak System and method for managing content on a network interface
US20140325326A1 (en) * 2003-02-13 2014-10-30 Bruce Zak System and Method for Managing Content on a Network Interface
US9141720B2 (en) * 2003-02-13 2015-09-22 Bruce Zak System and method for managing content on a network interface
US20040255146A1 (en) * 2003-04-30 2004-12-16 Asher Michael L. Program security through stack segregation
US7660985B2 (en) 2003-04-30 2010-02-09 At&T Corp. Program security through stack segregation
US20040268118A1 (en) * 2003-06-30 2004-12-30 Dario Bazan Bejarano System and method for automatic negotiation of a security protocol
US7526640B2 (en) * 2003-06-30 2009-04-28 Microsoft Corporation System and method for automatic negotiation of a security protocol
US9118710B2 (en) 2003-07-01 2015-08-25 Securityprofiling, Llc System, method, and computer program product for reporting an occurrence in different manners
US9118709B2 (en) 2003-07-01 2015-08-25 Securityprofiling, Llc Anti-vulnerability system, method, and computer program product
US10154055B2 (en) 2003-07-01 2018-12-11 Securityprofiling, Llc Real-time vulnerability monitoring
US10104110B2 (en) 2003-07-01 2018-10-16 Securityprofiling, Llc Anti-vulnerability system, method, and computer program product
US10050988B2 (en) 2003-07-01 2018-08-14 Securityprofiling, Llc Computer program product and apparatus for multi-path remediation
US9100431B2 (en) 2003-07-01 2015-08-04 Securityprofiling, Llc Computer program product and apparatus for multi-path remediation
US10021124B2 (en) 2003-07-01 2018-07-10 Securityprofiling, Llc Computer program product and apparatus for multi-path remediation
US9350752B2 (en) 2003-07-01 2016-05-24 Securityprofiling, Llc Anti-vulnerability system, method, and computer program product
US9118711B2 (en) 2003-07-01 2015-08-25 Securityprofiling, Llc Anti-vulnerability system, method, and computer program product
US9118708B2 (en) 2003-07-01 2015-08-25 Securityprofiling, Llc Multi-path remediation
US8984644B2 (en) 2003-07-01 2015-03-17 Securityprofiling, Llc Anti-vulnerability system, method, and computer program product
US9117069B2 (en) 2003-07-01 2015-08-25 Securityprofiling, Llc Real-time vulnerability monitoring
US9225686B2 (en) 2003-07-01 2015-12-29 Securityprofiling, Llc Anti-vulnerability system, method, and computer program product
US20050218940A1 (en) * 2004-03-31 2005-10-06 Mitsunobu Yoshida Waveform output device and drive device
US8296441B2 (en) * 2005-01-14 2012-10-23 Citrix Systems, Inc. Methods and systems for joining a real-time session of presentation layer protocol data
US20100050077A1 (en) * 2005-01-14 2010-02-25 Paul Ryman Methods and Systems for In-Session Playback on a Local Machine of Remotely-Stored and Real Time Presentation Layer Protocol Data
US8935316B2 (en) 2005-01-14 2015-01-13 Citrix Systems, Inc. Methods and systems for in-session playback on a local machine of remotely-stored and real time presentation layer protocol data
US20100049783A1 (en) * 2005-01-14 2010-02-25 Paul Ryman Methods and Systems for Joining a Real-Time Session of Presentation Layer Protocol Data
US8024541B2 (en) 2005-03-25 2011-09-20 Elliptic Technologies Inc. Packet memory processing system having memory buffers with different architectures and method therefor
US20100037220A1 (en) * 2008-08-05 2010-02-11 International Business Machines Corporation System and Method for Creating and Associating a Virtual Pseudo TTY with a Running Process
US8201175B2 (en) 2008-08-05 2012-06-12 International Business Machines Corporation Creating and associating a virtual pseudo TTY with a running process
US8635447B1 (en) * 2010-12-23 2014-01-21 Emc Corporation Managing certificates between software environments
US8958284B2 (en) 2011-06-16 2015-02-17 St-Ericsson Sa Port number reservation agent
US11356491B2 (en) 2012-01-06 2022-06-07 Comcast Cable Communications, Llc Streamlined delivery of video content
US10218756B2 (en) * 2012-01-06 2019-02-26 Comcast Cable Communications, Llc Streamlined delivery of video content
US9712398B2 (en) 2015-01-29 2017-07-18 Blackrock Financial Management, Inc. Authenticating connections and program identity in a messaging system
US10341196B2 (en) 2015-01-29 2019-07-02 Blackrock Financial Management, Inc. Reliably updating a messaging system
US10263855B2 (en) 2015-01-29 2019-04-16 Blackrock Financial Management, Inc. Authenticating connections and program identity in a messaging system
US10623272B2 (en) 2015-01-29 2020-04-14 Blackrock Financial Management, Inc. Authenticating connections and program identity in a messaging system
US9705752B2 (en) 2015-01-29 2017-07-11 Blackrock Financial Management, Inc. Reliably updating a messaging system
US10348867B1 (en) * 2015-09-30 2019-07-09 EMC IP Holding Company LLC Enhanced protocol socket domain
US9954873B2 (en) * 2015-09-30 2018-04-24 The Mitre Corporation Mobile device-based intrusion prevention system
US20210218750A1 (en) * 2020-01-09 2021-07-15 Cisco Technology, Inc. Providing multiple namespaces
US11843610B2 (en) * 2020-01-09 2023-12-12 Cisco Technology, Inc. Providing multiple namespaces

Also Published As

Publication number Publication date
US20010047486A1 (en) 2001-11-29
US6332195B1 (en) 2001-12-18

Similar Documents

Publication Publication Date Title
US5913024A (en) Secure server utilizing separate protocol stacks
US5918018A (en) System and method for achieving network separation
US5867647A (en) System and method for securing compiled program code
US10922403B1 (en) Methods and systems for implementing a secure application execution environment using derived user accounts for internet content
US7263718B2 (en) Security framework for supporting kernel-based hypervisors within a computing system
US5950195A (en) Generalized security policy management system and method
US6684329B1 (en) System and method for increasing the resiliency of firewall systems
US6584508B1 (en) Advanced data guard having independently wrapped components
US5497463A (en) Ally mechanism for interconnecting non-distributed computing environment (DCE) and DCE systems to operate in a network system
US7191469B2 (en) Methods and systems for providing a secure application environment using derived user accounts
US6981143B2 (en) System and method for providing connection orientation based access authentication
US20030014466A1 (en) System and method for management of compartments in a trusted operating system
GB2317539A (en) Firewall for interent access
WO2002078293A1 (en) Method and system for securely permitting mobile code to access network resources
US20080244711A1 (en) System and Method for Specifying Access to Resources in a Mobile Code System
Edwards et al. High security Web servers and gateways
Stein SBOX: Put CGI Scripts in a Box.
Stempel IpAccess-an internet service access system for firewall installations
Dalton et al. Design of secure UNIX
LeFebvre Restricting network access to system daemons under SunOS
Reid Open systems security: Traps and pitfalls
Powell et al. LPRng-An Enhanced Printer Spooler System.
Kahn Safe Use of X Window System Protocol Across a Firewall.
Kolano Mesh: secure, lightweight grid middleware using existing SSH infrastructure
McKusick The jail facility in FreeBSD 5.2

Legal Events

Date Code Title Description
AS Assignment

Owner name: SECURE COMPUTING CORPORATION, MINNESOTA

Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:GREEN, MICHAEL W.;JENSEN, ANDREW W.;REEL/FRAME:007976/0954

Effective date: 19960509

STCF Information on status: patent grant

Free format text: PATENTED CASE

CC Certificate of correction
FPAY Fee payment

Year of fee payment: 4

AS Assignment

Owner name: CITICORP USA, INC. AS ADMINISTRATIVE AGENT,NEW YOR

Free format text: SECURITY AGREEMENT;ASSIGNORS:SECURE COMPUTING CORPORATION;CIPHERTRUST, INC.;REEL/FRAME:018247/0359

Effective date: 20060831

Owner name: CITICORP USA, INC. AS ADMINISTRATIVE AGENT, NEW YO

Free format text: SECURITY AGREEMENT;ASSIGNORS:SECURE COMPUTING CORPORATION;CIPHERTRUST, INC.;REEL/FRAME:018247/0359

Effective date: 20060831

FPAY Fee payment

Year of fee payment: 8

AS Assignment

Owner name: SECURE COMPUTING CORPORATION, CALIFORNIA

Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:CITICORP USA, INC.;REEL/FRAME:021523/0713

Effective date: 20080904

FEPP Fee payment procedure

Free format text: PAT HOLDER NO LONGER CLAIMS SMALL ENTITY STATUS, ENTITY STATUS SET TO UNDISCOUNTED (ORIGINAL EVENT CODE: STOL); ENTITY STATUS OF PATENT OWNER: LARGE ENTITY

AS Assignment

Owner name: SECURE COMPUTING, LLC,CALIFORNIA

Free format text: CHANGE OF NAME;ASSIGNOR:SECURE COMPUTING CORPORATION;REEL/FRAME:024128/0806

Effective date: 20081120

Owner name: SECURE COMPUTING, LLC, CALIFORNIA

Free format text: CHANGE OF NAME;ASSIGNOR:SECURE COMPUTING CORPORATION;REEL/FRAME:024128/0806

Effective date: 20081120

AS Assignment

Owner name: MCAFEE, INC.,CALIFORNIA

Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:SECURE COMPUTING, LLC;REEL/FRAME:024456/0724

Effective date: 20100524

Owner name: MCAFEE, INC., CALIFORNIA

Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:SECURE COMPUTING, LLC;REEL/FRAME:024456/0724

Effective date: 20100524

FPAY Fee payment

Year of fee payment: 12

FEPP Fee payment procedure

Free format text: PAYOR NUMBER ASSIGNED (ORIGINAL EVENT CODE: ASPN); ENTITY STATUS OF PATENT OWNER: LARGE ENTITY

AS Assignment

Owner name: MCAFEE, LLC, CALIFORNIA

Free format text: CHANGE OF NAME;ASSIGNOR:MCAFEE, INC.;REEL/FRAME:045029/0406

Effective date: 20161220

AS Assignment

Owner name: SECURE COMPUTING CORPORATION, CALIFORNIA

Free format text: CORRECTIVE ASSIGNMENT TO CORRECT THE PROPERTY NUMBERS PREVIOUSLY RECORDED AT REEL: 021523 FRAME: 0713. ASSIGNOR(S) HEREBY CONFIRMS THE RELEASE OF PATENT SECURITY AGREEMENT;ASSIGNOR:CITICORP USA, INC.;REEL/FRAME:059690/0187

Effective date: 20080904