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:
list_sids
To see process contexts:
ps ax --context
To see your own context:
id
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
"avc_toggle".
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: