[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: More PATH fallout. Who decided this was a good idea?



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


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]