More PATH fallout. Who decided this was a good idea?
Steve Grubb
sgrubb at redhat.com
Sun Dec 7 14:54:31 UTC 2008
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
More information about the devel
mailing list