Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20110327201546.GA28924@albatros>
Date: Mon, 28 Mar 2011 00:15:46 +0400
From: Vasiliy Kulikov <segoon@...nwall.com>
To: owl-dev@...ts.openwall.com
Subject: Re: sysfs facility

Solar, all -

On Sun, Mar 27, 2011 at 23:45 +0400, Solar Designer wrote:
> Although we had discussed this approach, I never liked it much.  I did
> not seriously consider it for Owl.  I think it is better for us to get
> support for different sysfs and procfs permission settings into the
> kernel.

It is really better, but I'd say that at least introducing such (even
strictly hardening) procfs features into the upstream would occur only
after bloody disputes.  Each procfs changing is nervous because
currently procfs is a mess.

> mount sysfs /sys -t sysfs -omode=700
> mount proc /proc -t proc -ogid=110,umask=007
> 
> The procfs umask would apply to user-related
> entries in /proc only (most importantly, the /proc/<pid> directories),
> whereas system-wide things like /proc/cpuinfo would stay world-readable.
...
> So maybe a differently named mount option or a sysctl will be better.

Maybe umask, pid-umask, net-umask, XXX-umask, etc.?  The same with group
(if it makes sense).

> So if you asked me whether to create such a control facility or not,
> I would reply "no".

Actually, I'm also slowly porting owl-control to my ubuntu system to
harden it a bit.  There are too many setuid root binaries in the default
system :(  If sysfs facility is not a part of Owl, then I'll merely use
it on my desktop ;-)

Thanks,

-- 
Vasiliy

Powered by blists - more mailing lists

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.