On Wed, 25 May 2005 18:40:40 EDT, Colin Walters said:
> Errr...if your "auditor" specifies that you need "chroot" without
> understanding the issues, then just use SELinux, and tell them you're
> using "chroot". Moreover, why would you even let your organization be
> audited by someone so clueless in the first place?
When you're a state agency, you get audited by whoever shows up from the state
capitol. We don't get the luxury of choosing who. And when you're a 3 hour
drive from the capitol, you *know* that the auditor who shows up either (a)
likes being in the mountains a *lot*, or (b) is the junior staffer and got last
choice. (To be fair, we probably get the second to last choice. Somebody has
to get stuck with doing audits in Grundy(*), or in Floyd County (motto: "still
waiting for the county's second traffic light")
(And you there smirking in the corner - being a .com doesn't let you off the
hook. You know *damned* well that there's plenty of publicly traded corporations
that have signed auditing contracts with a Big 5^H4, and had a clueless bozo
show up...)
> > order to actually do it, you'd basically have to use the 'strict' policy,
> > give each user their own $USER_u - and then you could add the 5-6 lines of
> > policy that did the same as a 15-line LSM exit. Except the SELinux one
> > will have chewed up some 20M worth of avc_node slab entries (which makes a
> > noticeable difference if you're trying to secure an older box that only has
> > 128M or 256M installed).
>
> What you are forgetting is that I provided a solution for the policy
> size: use the constraints. Thomas Bleher even tested it and found it
> worked, IIRC.
Hmm.. I *must* have blinked. Where did he get it to where the memory usage was
the same as my 10 lines of C?
int vtkit_follow_link (struct dentry *dentry, struct nameidata *nd)
{
struct inode *i_target = dentry->d_inode;
struct inode *i_parent = dentry->d_parent->d_inode;
if ((i_parent->i_mode & S_ISVTX) && (i_parent->i_mode & S_IWOTH) &&
(i_parent->i_uid != i_target->i_uid) &&
(current->fsuid != i_target->i_uid)) {
return -EPERM;
}
return 0;
}
I'd *love* to see you get an SELinux-based solution that can get anywhere
near that for speed, slab usage, or stack usage. ;)
> Nope - we showed in that case SELinux did work, and quite elegantly too.
Yes, the constraints solution was indeed elegant, and very nice *if you were
using SELinux already*. But it's far from the most efficient way.
> > The point is that there *DO* exist *real world* security issues
> > that the SELinux model is not all that well suited for.
>
> Since we've discounted chroot, I'm awaiting more "*real world*"
> examples...
I have become firmly convinced that *some* people have spent *so* much time
designing ultra-secure systems suitable for protecting data worth multiple
millions of dollars that they have *totally* forgotten that *some* of us don't
have multi-million dollar secrets to protect from world-class attackers hired
by The Other Side.
I have to protect one undergrad from another, on an older Dell system that has
a 700mz processor and 128M of memory. And at 128M, the fact that you *could*
trim SELinux from 17M of slab space down to 8M still doesn't compare well with
another "good enough" solution that gets the job done in under 1K. The less
that 'Disk Active' LED goes on, the happier we all are... ;) I don't need
perfect security - I only need it to be hard enough so that instead of trying
to steal a homework solution, they decide to bribe somebody down the dormitory
hall to do it for them. I only need it to be hard enough so that instead of
trying to mess up another student's project, they decide to find some easier
way to make their victim's life difficult - if the attacker decides to penny
the victim into their dorm room instead (the cost of *that* attack being all of
3-5 cents plus a blunt object suitable for pounding), my security has suceeded.
I don't need to deploy $100,000,000 security.
I need to deploy $100 security.
And anybody who has trouble with that concept should carve out a large chunk of
time this weekend and (re-)read Schneier's "Secrets and Lies".....
(*) Grundy: http://maps.google.com/maps?q=grundy+virginia&spn=0.106445,0.128299&hl=en
Keep zooming out. You'll find civilization on there... eventually. By the time
you've zoomed out enough to find a city the size of Columbus, Ohio on the map, you
have portions of 11 states showing. Yes, there's places that remote east of the
Mississippi ;)
This archive was generated by hypermail 2.1.3 : Wed May 25 2005 - 22:29:21 PDT