|>------------------------------------------------------ || J. MELVIN JONES jmjonesat_private |>------------------------------------------------------ || Microcomputer Systems Consultant || Software Developer || Web Site Design, Hosting, and Administration || Network and Systems Administration |>------------------------------------------------------ || http://www.jmjones.com/ |>------------------------------------------------------ On Thu, 24 Jan 2002, Chris Wright wrote: > * jmjonesat_private (jmjonesat_private) wrote: > > > > > > Thanks. This is a good answer to my concerns. The only remaining > > issue I have is how archeological or ported-from-other-operating systems > > products may achieve "unmoderated" or "moderated-appropriately" status > > under a restrictive module. > > Because policy is specific to the module you'd have to take whatever > administrative action required to give the program unconstrained > privelges. This may mean making is setuid, having it entered into some > clean list, having it cryptographically signed, whatever it is that the > module requires to grant full priveleges. > > > Is there a standard way or must application designers write code to > > multiple situations? > > Being able to gracefully handle error conditions is a good start, as the > module may not return success in all the same places. The main gotcha > would be relying on module specific system calls. > > thanks, > -chris > _______________________________________________ linux-security-module mailing list linux-security-moduleat_private http://mail.wirex.com/mailman/listinfo/linux-security-module
This archive was generated by hypermail 2b30 : Thu Jan 24 2002 - 13:18:31 PST