On Saturday 06 December 2008 13:57:13 Jeff Spaleta wrote: > > I think you aren't looking at all the pieces to see how it fits together. > > Okay... what are all the pieces and how do they fit together? You would need to read the CAPP guidelines and look at a couple audit patches and rule sets. > Has this ever been explained to the Fedora base? Probably not. Since you are asking nicely, I'll explain it. For this discussion lets look at: http://www.niap-ccevs.org/cc-scheme/pp/pp_os_ca_v1.d.pdf Lets start with the assumptions, Section 3.3.2 A.NO_EVIL_ADM The system administrative personnel are not careless, willfully negligent, or hostile, and will follow and abide by the instructions provided by the administrator documentation. Section 3.3.3 A.PEER Any other systems with which the TOE communicates are assumed to be under the same management control and operate under the same security policy constraints. Now for the Objectives related to our discussion, Section 4.1 O.AUTHORIZATION The TSF must ensure that only authorized users gain access to the TOE and its resources. O.AUDITING The TSF must record the security relevant actions of users of the TOE. The TSF must present this information to authorized administrators. And the relevant Functional Requirements 5.1.1.1 The TSF shall be able to generate an audit record of the auditable events listed in column “Event” of Table 1 (Auditable Events). This includes all auditable events for the basic level of audit, except FIA_UID.1’s user identity during failures. FAU_GEN.1.1 / NOTE 4 FMT_REV.1 All modifications to the values of TSF data. 5.3.6.1 The TSF shall associate the following user security attributes with subjects acting on the behalf of that user: FIA_USB.1.1 / NOTE 2 a) The user identity which is associated with auditable events; b) The user identity or identities which are used to enforce the Discretionary Access Control Policy; c) The group membership or memberships used to enforce the Discretionary Access What this means, is that 1) admins are not hostile and follow proceedures. 2) In order for DAC to work there must be accounts established that Identify Users. 3) We must audit changes that affect the user-subject binding since that is the foundation of all DAC security controls. 4) We specifically need to know in the case of someone acting upon a user's behalf, who did it, and what was modified. 5) We must audit changes to trusted databases To accomplish this, we instrument the shadow-utils code. This lets us see who modified any account and which account and how it was modified. You can find these in your audit logs ny looking for ausearch --start this-month -m ADD_USER ---- time->Wed Dec 3 06:27:22 2008 node=127.0.0.1 type=ADD_USER msg=audit(1228303642.238:3290): user pid=3919 uid=0 auid=4325 ses=1 subj=unconfined_u:system_r:useradd_t:s0-s0:c0.c1023 msg='op=adding user acct="rpc" exe="/usr/sbin/useradd" (hostname=?, addr=?, terminal=? res=success)' and ausearch --start this-month -m ADD_GROUP ---- time->Wed Dec 3 06:27:22 2008 node=127.0.0.1 type=ADD_GROUP msg=audit(1228303642.155:2796): user pid=3915 uid=0 auid=4325 ses=1 subj=unconfined_u:system_r:groupadd_t:s0-s0:c0.c1023 msg='op=adding group acct="rpc" exe="/usr/sbin/groupadd" (hostname=?, addr=?, terminal=? res=success)' This takes care of 1-4. To accomplish 5, we add an audit rule https://fedorahosted.org/audit/browser/trunk/contrib/capp.rules#L195 This results in events like this: time->Wed Dec 3 06:27:22 2008 node=127.0.0.1 type=PATH msg=audit(1228303642.237:3286): item=0 name="/etc/shadow" inode=20776439 dev=08:08 mode=0100400 ouid=0 ogid=0 rdev=00:00 obj=system_u:object_r:shadow_t:s0 node=127.0.0.1 type=CWD msg=audit(1228303642.237:3286): cwd="/" node=127.0.0.1 type=SYSCALL msg=audit(1228303642.237:3286): arch=c000003e syscall=2 success=yes exit=6 a0=612bc0 a1=2 a2=1b6 a3=7f118a6f6780 items=1 ppid=3907 pid=3919 auid=4325 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0 ses=1 comm="useradd" exe="/usr/sbin/useradd" subj=unconfined_u:system_r:useradd_t:s0-s0:c0.c1023 key=61757468016964732D66696C652D6869 Which as you can see has the same time stamp as the audit event for ADD_USER. So we now meet #5. But what about audit of any attempt to change an account and its outcome? The shadow file cannot be accessed unless you are root. The utilities that would allow you to modify it cannot be accessed unless you are root. The assumptions state that any system you have access to is also managed with the same policies, therefore users cannot download their own copy. All requirements are covered. This allows us to make some reports about system activity. To see a summary of these actions, you can run aureport --start this-month --mods -i For the direct access as well as through approved utilities, you can see it like this ausearch --start this-month -f /etc/shadow --raw | aureport -x -i Now, if anyone wants to discuss this any further, I am willing as long as we drop all the hostility. I'm tired of it. Attacking the security target is not something I want to debate as its out of my control. I just want to meet it. Hope you find this informtion useful. -Steve -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
