* Casey Schaufler said:
> Marek Habersack wrote:
>
>
> > ... I thought it would be good to have a capability,
> > say CAP_SYS_INFO, that would allow access to some system
> >information (right now only quotas and resource limits come to my mind) > for non UID0 processes.
> > I think adding such thing to the kernel wouldn't be too hard, only a
> > question remains whether it makes sense or not?
>
> Capability granularity is a touchy issue. What you're proposing is
> having seperate capabilities for READ and WRITE access to a set
> of information. The first question to ask is why reading the
> information requires privilege in the first place. It could just be
> that the original implementer was lazy (happens in Unix all the time)
> and couldn't see any reason for unprivileged users to look at it.
> If that's the case, the Right Thing(tm) to do is allow reasonable
> access (e.g. maybe just the user's own information) to everyone.
> If there's some reason why the information shouldn't be available
> and there are reasonable cases where you'd want to look but not
> touch a seperate capability might be in order.
Some information available from the system is quite valuable for attacker
with local access to the system - e.g. the CPU in the machine (think of the
ancient F00F bug for example and possibility to exploit it), memory size
(now everyone can type 'free' or just browse through /proc to find all there
is about memory size and usage), partition sizes of the attached block
devices, interrupts, IO ports and many more. That information is not always
security hazard when given away, but nevertheless it (IMHO) shouldn't be
available for the common user but just for the privileged processes which,
in turn, wouldn't have to be ran as UID0 if there were appropriate
capabilities. My particular case was that I'm developing a WWW-based system
for the users that have no shell access to the server and therefore cannot
check what is their quota, disk usage etc. Now, to check that info the quota
utility has to be ran either as root or as the user being checked. In my
case, the process to examine the quotas is a CGI script written (for
example) in C and I WON'T allow CGI execution as UID0 and change of UID to
the target user's is out of the question since the httpd runs as its own
user permamently and has no way to change its personality. Now, if I had a
possibility to equip my CGI with capabilities to READ quotas of any user,
then everything would work just fine. As it is now, I won't equip the
process with any capabilities that woyuld allow it to read quotas, since
these same caps allow the process to change quotas and CGI code is never
safe when allowed to do too much... For now I have just written a daemon
process that runs chrooted as root and the CGI script connects to it
(running as specific user), passess its credentials and if they match a
compile-time defaults, the quota information is returned and shown to the
user. Well... it works, but is far from elegant and much more complicated
than it would be if I had the capabilities we're discussing now.
marek
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Mon Feb 07 2000 - 21:00:07 EST