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

Re: SE Linux play machine

On Tue, 18 Jun 2002 15:02, Nick Phillips wrote:
> "Play machine" and "can't do any damage as root" as in "rjc will not mind
> if you accidentally screw it completely whilst playing, as he obviously
> didn't have it configured right"?
> Just curious ;)

Sure.  You can do whatever is necessary to determine that there is a security 
hole as long as you then tell me what you did!

If you can trash /boot and cause a reboot, use dd to write to a raw device, 
etc then go for it, just tell me what you did afterwards.

I'd prefer that security problems be demonstrated in a non-destructive way if 
possible, it takes about an hour to restore from backup...

On Tue, 18 Jun 2002 15:29, Tollef Fog Heen wrote:
> statting the log files in /var/log isn't even allowed.  What is the
> utility for listing out capabilities?

stat -s file

To see all active SIDs:

To see process contexts:
ps ax --context

To see your own context:

On Tue, 18 Jun 2002 18:39, Michael R. Schwarzbach wrote:
> it's quite impressing. I've played a little with SE Linux, but I didn't
> have the time, to work out a really working policy yet. I heard, that
> you already held several lectures about SE Linux. I searched your site
> and the internet for manuscripts or documenations (from you)(espacially
> about integrating SE Linux in debian), but haven't found very much. Are
>   there any documantations or howtos about installing and configuring SE
> Linux on debian?

http://www.coker.com.au/selinux/ has some very brief documents and all the 
code that's needed (in addition to what's in unstable).

Documentation is lacking at the moment because I think that good code and bad 
documentation is better than bad code and good documentation.

On Tue, 18 Jun 2002 18:55, John H. Robinson, IV wrote:
> what would be ``proof'' of damage as root?
> touching boo in $HOME is probably not very much proof of ``damage''

Tell me what my password is.  Create a file in the root directory.  Get read 
or write access to a block device for the hard drive.  Reboot the machine 
(through any cause other than an OOM condition).  Cause a kernel Oops.  
Change the security policy.  Put the machine in permissive mode via 

If you do something that has potential for destruction such as avc_toggle 
then please put it back ASAP to avoid having someone else destroy the 
machine.  avc_toggle toggles between permissive and enforcing mode.

On Wed, 19 Jun 2002 00:30, Nick Phillips wrote:
> Oh... first thing I looked at though... you may want to change your
> password, if you haven't already ;)
> john hasn't got it yet...

I'm changing my personal password on that machine (which is always different 
to any password I've ever used on a machine that matters) a few times.  
Whenever I accidentally allow read access to /etc/shadow I have to change it.

As for the root password, I've changed it back, but this is a continual 
problem.  You can change your password as root, I may change the policy to 
prevent that.

I do not get viruses because I do not use MS software.
If you use Outlook then please do not put my email address in your
address-book so that WHEN you get a virus it won't use my address in the
>From field.

To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Reply to: