Re: A Comment from User Space

sarnoldat_private

[No need to CC me, I read the list. Thanks.]

* Valdis.Kletnieksat_private <Valdis.Kletnieksat_private> [010423 22:20]:
> from http://www.nsa.gov/selinux/doc/slinux-200104121417/node13.html
[...]
> We may need another few hooks here and there - their logic is correct.
> An LSM might get called on a hook for a socket()/connect() call to an
> external host, give an OK - but the connect() fails for *other* reasons
> (host unreachable, etc).

Then the library/program should pay attention to the error stored in
errno. If the connect() etc fails from lack of permission, the EPERM
stored in errno ought to let it know that it didn't have permission. If
the connect() etc fails from lack of other endpoint, the ENOROUTE (yes,
laugh at me for not knowing the errno returned :) ought to let the
process/LSM know that it didn't have an endpoint.

We don't need the functionality (well, no one has convinced me :) of
saying "this process could make the connect() if it were running by root
on the third tuesday of the month except for leap years". "Go away" is
sufficient in my book. :)

> The LSM may want to know that, as additional information - if the
> process then does another connect() to another host, after a failure
> on the first, that indicates a process working its way down multiple A
> records for a host.  If the first connect() *worked*, and the process
> is opening another connection *anyhow*, that might be a scanner or
> other bad things in progress..

Hmm. This makes a bit more sense. However, I have several arguments
(most of which fall into the 'policy' category). First, trying to
prevent outgoing scanning is silly -- preventing scanning is mostly a
security through obscurity trick. Second, a module is entirely free to
have a function hook in connect() similar to this:

static int connect_try = 0;
int mediate_connect_hook(<args go here>)
{
	if (++connect_try > 10)
		return ENOPERM;
	return 0;
}

int mediate_close_hook(<args go here>)
{
	if (--connect_try < 0)
		return ESMARTASS;
	return 0;
}

Of course, a real module would go to the trouble of allowing close()
only once on open()ed sockets. Some sort of table of nonces would make a
great deal of sense here.

Third, I don't see how the error status of "host up/down" versus
"permitted to make this connection" helps locate scanning attempts or
other bad things.

I don't see why a customized error message is required for this case.

> An open() might be authorized but then fail because a file system is
> out of inodes - the LSM may want to know that, because it may indicate
> a DOS attack in progress..  And so on...

a) Use quotas. b) If the filesystem is already full, the DOS attack has
already won. :) c) a module could hook VFS_OPEN() (again with the
laughing :) :

int mediate_vfs_open(<args here>) {
	if (can_use_all_inodes(current->security_blob))
		return 0;
	if (arg->mount_point->free_inodes > POLICY_VARIABLE)
		return 0;
	return ENOPERM;
}

No customized error message will help this situation. (i.e., what does
it matter that this process can't create new files because the drive is
full versus the policy says the drive is full versus not having
traditional unix permission to create the inode where asked?)

Does anyone think that a module programming would want to re-implement
quotas? (I could imagine some checks in the VFS layer to leave X% of the
drive available for processes in a special class, say euid==0, or
something similar, but full-blown quota support may be going overboard.
Or would it? :)

I realize that lack of easy examples is not proof that the functionality
of a second specialized error return value isn't needed. But, remember
LSM's charter is to be fast, lightweight, and not screw with things too
badly. Forcing two error returns for all syscalls seems to fall under
the "screws with things" category, at least from my vantage point.

[I apologize for the size of this email. I lack the time to make it short.]

-- 
Earthlink: The #1 provider of unsolicited bulk email to the Internet.

_______________________________________________
linux-security-module mailing list
linux-security-moduleat_private
http://mail.wirex.com/mailman/listinfo/linux-security-module