[BBLISA] Re: SELinux

[John Stoffel]

>>>>> "Scott" == Scott Ehrlich <scott at MIT.EDU> writes:

Scott> On Thu, 24 Jan 2008, Daniel Hagerty wrote:
>> Scott Ehrlich <scott at MIT.EDU> writes:
>> 
>>> Considering the balance of changing crontab's source code vs noexec,
>>> noexec seems the more reasonable approach of the two.  Not the best
>>> solution, but weighing the two options, possibly the most practical at
>>> this point.
>> 
>> Except I've reached the point where I have little faith it will
>> help with your unspecified problem.
>> 
>> noexec will hose you if an otherwise legitimate job is on that
>> filesystem, because it won't exec.  On the flip side, noexec does
>> nothing to prevent a priviledge escalation problem if a user puts
>> ". /foo/bar/script.sh" as a command for cron (oh look, another way
>> where user A doing something foolish can lead to user B impersonating
>> him, and therefore forget what I said about fixing exec*() probably
>> being enough).
>> 

Scott> Is it possible to permanently change /tmp and /var/tmp to chmod
Scott> o-wx, and then prevent anything from ever creating world
Scott> writable and executable in those folders?

As other have said, no.  


Again, what the heck are you trying to accomplish here?  You're at MIT
for gods sake, the inventors of Kerberos, do you think Security isn't
understood there, and what the limits are?  

Scott> Then, is it possible to carry those changes to individual user
Scott> home directories?

If you don't want user's to be able to execute *any* binaries except
the ones you provide them, then you will need to remove any and all
shell access to this system and only allow them to run the programs
you select for them.  People have done this, but in general it's not
considered worth the effort today.

Scott> I could do the chmod myself then modify the permissions of
Scott> chmod to 700.

And if the user owns the directory, they can just chmod them right
back. 

Scott> But that doesn't answer how applications will behave if they
Scott> need to create directories... would umask help?

If you lock down /tmp, then a bunch of random applications will fail,
such as text editors who depend on creating files in /tmp, etc.  

>> Are we getting the idea yet?  This all would just be so much more
>> productive if you'd just tell us what thought it was that precipitated
>> "how do I limit cron's capabilities?".
>> 
>> I just can't help but get the feeling that our partial picture
>> will lead you to doing something that produces an undeserved sense of
>> security.

Scott> It's just one of those things where I'm simply following directions.

Then your boss is a fool and you should be pushing back on them for a
better understanding of what the boss is asking you to do here.  

Again, you are trying to blindly follow instructions to do something
which makes no sense.  And you obviously don't understand what you've
been asked to so or why, so you need to push back and get more
understanding.

Yes, you may consider this case closed, but I know myself and a bunch
of the rest of us here are just scratching our heads wondering WTF is
going on here.  

You (and your boss of course) need to go back to the level of:

	What are we trying to do here and why?

And in alot of cases, you need to setup a policy for your users, so
that if they do abuse it, you have something with which to lower the
boom on their heads.

I used to SysAdmin at WPI out in Worcester, and I was a student there,
so I know all about Academic institutions and they (in general) work
in regards to system access and security.  And how hard it is to make
it truly secure due to the demands of Faculty and Staff, which are at
odds with alot of this.

And of course Students will just poke and prod and do all kinds of
wierd things because they have *way* too much time on their hands and
a desire to break things and look smart.  

Sorry for the rant Scott, it's not directed so much at you as it is
your boss and the general non-SysAdmin perceptions of security.  

John