1 |
2013/4/29 Joerg Schilling <Joerg.Schilling@××××××××××××××××.de> |
2 |
|
3 |
> Nikos Chantziaras <realnc@×××××.com> wrote: |
4 |
> |
5 |
> > > This may be an option for things that really are optional. |
6 |
> > > |
7 |
> > > Libcap however is not something optional but needed to support a basic |
8 |
> security |
9 |
> > > feature. |
10 |
> > |
11 |
> > I thought it is optional, since it was mentioned that cdrtools can be |
12 |
> > built and ran without it? |
13 |
> |
14 |
> If you call something that is needed in order to prevent security holes |
15 |
> "optional", you may call it optional. |
16 |
> |
17 |
> |
18 |
> > Unless you mean "recommended" instead of "required." "Recommended" |
19 |
> > means it's still optional. |
20 |
> |
21 |
> Is something to grant security optional or required? |
22 |
> |
23 |
> |
24 |
> > > As mentioned above, we are talking about a library to support basic |
25 |
> security |
26 |
> > > features, so the code from that library would really belong into libc. |
27 |
> Since |
28 |
> > > Linux now by default supports fcaps in the filesystems, cdrecord would |
29 |
> open |
30 |
> > > a security hole if the library was not used - without that library, |
31 |
> cdrecord |
32 |
> > > cannot even see that is has been called with additional privileges |
33 |
> that need |
34 |
> > > to be removed before the main code is executed. |
35 |
> > > |
36 |
> > > Do you really like to go into a security risk with your eyes open? |
37 |
> > |
38 |
> > You don't know what my intentions are. I might be doing testing, |
39 |
> > debugging, who knows what. It's the "trying to be smarter than the |
40 |
> > user" thing. The defaults of course would be to built the software in a |
41 |
> > sane, secure way. Only users who know what they're doing would disable |
42 |
> > that, and they'd have their reasons. |
43 |
> |
44 |
> Would you call someone who shoots himself into the foot "smart"? |
45 |
> |
46 |
> Recent Linux kernels support fcaps in the filesystems and "somebody" evil, |
47 |
> who |
48 |
> knows what he does may even set up fcaps on executable files when the |
49 |
> related |
50 |
> support-software is not installed, just because the unstable kernel |
51 |
> interfaces |
52 |
> are accessible from libc. |
53 |
> |
54 |
> Do you like people to be able to open security holes? |
55 |
> |
56 |
> |
57 |
> |
58 |
> |
59 |
> |
60 |
|
61 |
|
62 |
Adding an option to enable/disable linkage to libcap does not hurt anybody |
63 |
it just eases maintaining the package. You can enable it by default if you |
64 |
wish. |
65 |
|
66 |
As long as it is possible to remove libcap from the system the security |
67 |
hole you are talking about is still there. The option does not change |
68 |
anything. Currently one could still compile cdrtools without libcap and |
69 |
afterwards install libcap and use setcap on cdrecord et al. which leads to |
70 |
the same problem. |
71 |
|
72 |
-- |
73 |
Regards |
74 |
Daniel Pielmeier |