Date: Fri, 02 Jun 2006 12:24:40 -0700 From: Jeff <dt@defcon.org> To: freebsd-security@freebsd.org Subject: Re: mac_bsdextended log information Message-ID: <7.0.1.0.2.20060602104259.21f07b40@blackhat.com> In-Reply-To: <1149238669.657.6.camel@dell1.kvg.hu> References: <7.0.1.0.2.20060601142921.2284c5b0@wheresmymailserver.com> <1149238669.657.6.camel@dell1.kvg.hu>
next in thread | previous in thread | raw e-mail | index | archive | help
At 01:57 AM 6/2/2006, you wrote:
>On Thu, 2006-06-01 at 14:40 -0700, Jeff wrote:
>> Hey everyone,
>>
>> I'm hoping someone can point me in the right direction. I'm running a 6.1 box with mac_bsdextended compiled. I've created my ugidfw rules, and all seems well in the universe.
>>
>> I've got rules set up so the web process uid 80 and gid 80 can only read uid 1010 and gid 1010 owned files. When the web server tries to do something else, it throws an error such as:
>>
>> <authpriv.emerg> www kernel: mac_bsdextended: 80:80 request 256 on 0:0 failed.
>>
>> So the question is, what file did the www process try to muck with? It is a root owned file, and it is important that it want to act on it. Security problem, or benign problem? Who knows without being able to know what the file is. A look at the source code implies that the "request 256" means that the web process tried to read the vnode numbered 256. Is that accurate?
>> If it is, how do I go about associating vnode numbers to files, so I have a hope of troubleshooting these errors.
>>
>
>There are many legitimate reasons for a webserver to open root owned
>files. Looking up users in the password database would be my first
>guess. Maybe you shoud consider changing your rules to some more fine
>grained ones?
Well considering that there are no user accounts, and the web server is not dynamic there is no reason for it to read root owned files. That was the point of the whole excercise and I am so close.
>> Searching seems to turn up no tool or easy way to get this vnode -> file information. Help!
>
>Try:
>
>$ find -inum 256 /
I'll try that.. nope didn't work.
When I looked at the source for bsdextended I find:
/*
* Is the access permitted?
*/
if ((rule->mbr_mode & acc_mode) != acc_mode) {
if (mac_bsdextended_logging)
log(LOG_AUTHPRIV, "mac_bsdextended: %d:%d request %d"
" on %d:%d failed. \n", cred->cr_ruid,
cred->cr_rgid, acc_mode, object_uid, object_gid);
return (EACCES); /* Matching rule denies access */
}
So in my example the "request 256" is being generated by "acc_mode" in the code above.
From http://fxr.watson.org/fxr/ident?v=RELENG61;i=acc_mode
acc_mode reveals:
Defined as a variable in:
* <http://fxr.watson.org/fxr/source/kern/vfs_subr.c?v=RELENG61#L3181>kern/vfs_subr.c, line 3181
Which shows
/*
3169 * Common filesystem object access control check routine. Accepts a
3170 * vnode's type, "mode", uid and gid, requested access mode, credentials,
3171 * and optional call-by-reference privused argument allowing vaccess()
3172 * to indicate to the caller whether privilege was used to satisfy the
3173 * request (obsoleted). Returns 0 on success, or an errno on failure.
3174 */
So it looks like it is returning an errno, and in this case it is errno 256. I have also seen errno 8192.
The question then becomes, what the heck does error number 256 or 8192 mean?
Thanks for any help!
Jeff
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?7.0.1.0.2.20060602104259.21f07b40>