|Subject:||some questions about audit|
|Date:||Oct 17, 2005 2:57:53 am|
On Sat, 15 Oct 2005 15:48:12 -0400 Wayne Salamon <wsal...@computer.org> wrote:
On Oct 15, 2005, at 2:21 AM, xuej...@ios.cn wrote:
The following is what my mentor and I would do in the next few months: (1) Add object¡¯s security level to the audit trail
Can you describe where this security level is maintained? Is there a program running that will submit the label to the kernel for inclusion in the audit trail?
At present the BSM is up to the C2 in the TCSEC( Trusted Computer System
Evaluation Criteria), and we want to add some other security features defined in
B1, such as the multilevel security. The mulit-level object is used to provide
the usability of the MLS system. It is just a novel approach to prevent the
object previously labeled EQUAL to leak important information, the level should
be maintained in the kernel (for example, in a global array ).
(2) Add the event of overriding of human readable output markings
I'm not sure what you mean here.
According to the requirements in the B1 criteria, the system should audit the
new event of "any override of human readable output markings on paged, hard-copy
output devices" ("A Guide to Understanding Audit in Trusted Systems").
(4) We want to add a command to dynamically adjust the state of auditing while a user's process are active, as audit_config does on solaris with the -setpmask options.
A command similar to the Solaris auditconfig command would be nice to
have. The system call is in place (auditon()) to change a process'
audit masks, as well as many other audit settings.
Yes, the A_SETKMASK and A_SETPMASK command of auditon can do it. auditon is
(d) The ai_mask of child process is copied from parent without any modification. So, if a user login while auditing is disabled, then none of his action would be recorded, even after auditing is enabled. I think it¡¯s necessary to do some checking in function audit_proc_fork(). If the auditing condition has been changed, then the children¡¯s mask will be recomputed.
The login command sets the audit masks of the user that logs in. By "auditing is disabled" do you mean "disabled because the masks for the process are cleared" or "disabled because the auditing state is OFF"? In the second case, having login set the audit masks should allow for the auditing of a user's process commence once auditing is turned ON.
Currently login doesn't set the audit masks if the auditing state if off, so
all the child process will not, even if it is created when the auditing is
turned on. And if you modify the login program only, could there be other
problems? For example, if the audit_control file is not in the default
directory, then the problem remains.
panxj To Unsubscribe: send mail to majo...@trustedbsd.org with "unsubscribe trustedbsd-audit" in the body of the message