On Mon, 23 Apr 2001, Greg KH wrote: > And most important of all, who is going to write code to actually use > such a thing? I don't see the current Linux security projects offering > up secure userspace tools to match their kernel patches (SELinux being > an exception here, from what I have heard, but I might be wrong here.) > Unless you do it yourself, none of the individual groups are going to > start coding to a new kernel interface any day soon. Hey, they have > enough problem getting convinced that their code has security problems > in it in the first place! (personal experience here, trust me, not a > pretty thing...) SELinux doesn't define any extended error codes. Access failures return one of the normal Linux error codes (EACCES or EPERM in most cases, ECONNREFUSED or ECONNRESET in the cases of some network access failures). In most cases, the potential for the same error conditions already existed with the ordinary Linux kernel, so most applications should handle these errors. Only a few controls, such as the controls on individual read and write calls, can cause access failures where an access failure would not normally be possible. Most of the SELinux userspace patches are for extending utilities to allow users to display or set the security contexts of subjects and objects (e.g. fileutils findutils, procps, psmisc, sh-utils, stat). Logrotate was patched to preserve the security context on log files when they are rotated. Tar was patched to allow files security contexts to be preserved and restored when archives are created/expanded. Login and Crond were patched to set the security contexts appropriately for user login sessions and user cron jobs. -- Stephen D. Smalley, NAI Labs ssmalleyat_private _______________________________________________ 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 : Tue Apr 24 2001 - 06:18:56 PDT