Re: [gentoo-dev] RFC: More versatile return codes for emerge

[Thomas Kahle]

On 21:04 Wed 25 Jan 2012, "Paweł Hajdan, Jr." wrote:
> On 1/25/12 10:23 AM, Thomas Kahle wrote:
> > I suggest that emerge could signal its various failures via return
> > codes.  That would be useful in automated archtesting:
> > 
> > https://bugs.gentoo.org/show_bug.cgi?id=400705
> 
> My opinion is very similar to what Brian Harring said on that bug: some
> Python API would be much better than still pretty vague return code
> (what would you do with it?).

My test setup (as you probably know) uses bash scripts (autogenerated by
app-portage/tatt) that call emerge with various USE-flag combinations
and then protocol failures to be looked at individually.  Those scripts
can easily react to return codes.  Sure thing, once the portage API
access is available, the entire test setup can be rewritten using it.  I
just don't see this happening anytime soon.  Making the return codes
more versatile should be quick and easy to implement.  It's very KISS.

> Some ideas:
> 
> - I emerge a list of packages, some unstable dependencies are required;
> allow me to get a list of those package atoms
> 
> - same as above, but return list of USE flags adjustments required
> 
> - package blocks
> 
> - unsatisfied USE flag constraints
> 
> ... and so on. I think it can start very simple and small, and be
> extended as needed.

I think those ideas are great and natural, but I'd still prefer to have
something that is usable very soon instead of waiting for the portage
API to be available (and documented).  

Cheers,
Thomas



-- 
Thomas Kahle
http://dev.gentoo.org/~tomka/


signature.asc
Description: Digital signature

Re: [gentoo-dev] How help in arch testing work

[Thomas Kahle]

On 15:23 Wed 18 Jan 2012, Agostino Sarubbo wrote:
[...] 

> 5) If is a library, obviously, we can try to rebuild stable RDEPENDS in tree 
> and an easy way to check the list of rdepend is asking our bot: 
> !rdep ${package}
> Unfortunately it prints a complete list of RDEPEND(stable+testing), and is a 
> lack of time checking manually what is the list of stable packages.

Can be done easily with some eix scripting.  app-portage/tatt has this
implemented too.

Cheers,
Thomas


-- 
Thomas Kahle
http://dev.gentoo.org/~tomka/


signature.asc
Description: Digital signature

Re: [gentoo-dev] How help in arch testing work

[Paweł Hajdan, Jr.]

On 1/27/12 10:41 AM, Thomas Kahle wrote:
> On 15:23 Wed 18 Jan 2012, Agostino Sarubbo wrote:
> [...] 
> 
>> 5) If is a library, obviously, we can try to rebuild stable RDEPENDS in tree 
>> and an easy way to check the list of rdepend is asking our bot: 
>> !rdep ${package}
>> Unfortunately it prints a complete list of RDEPEND(stable+testing), and is a 
>> lack of time checking manually what is the list of stable packages.
> 
> Can be done easily with some eix scripting.  app-portage/tatt has this
> implemented too.

And my arch-tools also has a script for that (reverse-dependencies.py).



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] RFC: More versatile return codes for emerge

[Alec Warner]

On Fri, Jan 27, 2012 at 1:33 AM, Thomas Kahle  wrote:
> On 21:04 Wed 25 Jan 2012, "Paweł Hajdan, Jr." wrote:
>> On 1/25/12 10:23 AM, Thomas Kahle wrote:
>> > I suggest that emerge could signal its various failures via return
>> > codes.  That would be useful in automated archtesting:
>> >
>> > https://bugs.gentoo.org/show_bug.cgi?id=400705
>>
>> My opinion is very similar to what Brian Harring said on that bug: some
>> Python API would be much better than still pretty vague return code
>> (what would you do with it?).
>
> My test setup (as you probably know) uses bash scripts (autogenerated by
> app-portage/tatt) that call emerge with various USE-flag combinations
> and then protocol failures to be looked at individually.  Those scripts
> can easily react to return codes.  Sure thing, once the portage API
> access is available, the entire test setup can be rewritten using it.  I
> just don't see this happening anytime soon.  Making the return codes
> more versatile should be quick and easy to implement.  It's very KISS.

I agree, but we have gentoo-portage-...@gentoo.org for this sort of thing?

-A

>
>> Some ideas:
>>
>> - I emerge a list of packages, some unstable dependencies are required;
>> allow me to get a list of those package atoms
>>
>> - same as above, but return list of USE flags adjustments required
>>
>> - package blocks
>>
>> - unsatisfied USE flag constraints
>>
>> ... and so on. I think it can start very simple and small, and be
>> extended as needed.
>
> I think those ideas are great and natural, but I'd still prefer to have
> something that is usable very soon instead of waiting for the portage
> API to be available (and documented).
>
> Cheers,
> Thomas
>
>
>
> --
> Thomas Kahle
> http://dev.gentoo.org/~tomka/

Re: [gentoo-dev] Can we get PIE on all SUID binaries by default, por favor?

[Jason A. Donenfeld]

I've just been informed that RHEL does not allow non-PIE executables. We
really should follow suit here.

Re: [gentoo-dev] Can we get PIE on all SUID binaries by default, por favor?

[Paweł Hajdan, Jr.]

On 1/27/12 8:02 PM, Jason A. Donenfeld wrote:
> I've just been informed that RHEL does not allow non-PIE executables. We
> really should follow suit here.

I'm generally in favor of enabling more hardening features by default
(i.e. reversing the default, so that people who want to disable PIE can
still do it). Note that the hardened profile uses PIE by default iirc.

The most common argument against it is performance loss I think, and
there are probably less than 10 packages that have some compilation
issues with PIE. In my opinion we can deal with that, and security
benefits are much more important.

If the discussion on this doesn't get conclusive, how about adding the
question to the Council's agenda?



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Can we get PIE on all SUID binaries by default, por favor?

[Mike Frysinger]

On Friday 27 January 2012 14:02:33 Jason A. Donenfeld wrote:
> I've just been informed that RHEL does not allow non-PIE executables. We
> really should follow suit here.

i can't emphasize how little i care what RHEL/Fedora do.  so the logic of 
"they do XXX therefore we should XXX" holds little sway for me.
-mike


signature.asc
Description: This is a digitally signed message part.

Re: [gentoo-dev] Can we get PIE on all SUID binaries by default, por favor?

[Mike Frysinger]

On Thursday 26 January 2012 11:55:54 Jason A. Donenfeld wrote:
> On Tue, Jan 24, 2012 at 06:58, Mike Frysinger  wrote:
> > pedantically, PIE+ASLR makes it significantly harder to exploit, not
> > impossible
> > 
> > if we could get some general performance numbers that show non-PIE vs
> > PIE, that'd help make the case for turning PIE on by default regardless
> > of set*id.
> 
> For starters, though, what about just pooping a Q&A warning for non-PIE
> SUID? That way those packages could be fixed, and we'd have a little trial
> to see how PIE behaves across different platforms. If that all goes well,
> we bump up to default, but that's a far off discussion.

a QA warning doesn't help anyone if we don't have documentation in place 
explaining to people how to do this cleanly
-mike


signature.asc
Description: This is a digitally signed message part.

Re: [gentoo-dev] Can we get PIE on all SUID binaries by default, por favor?

[Fabian Groffen]

On 27-01-2012 20:39:24 +0100, "Paweł Hajdan, Jr." wrote:
> If the discussion on this doesn't get conclusive, how about adding the
> question to the Council's agenda?

Negative from my point of view, this is an issue that the dev-community
can solve themselves without needing a "force" from the Council.

Just implement it in a way that people can opt-in/opt-out on it.


-- 
Fabian Groffen
Gentoo on a different level


signature.asc
Description: Digital signature

Re: [gentoo-dev] Can we get PIE on all SUID binaries by default, por favor?

[Mike Frysinger]

On Friday 27 January 2012 14:39:24 Paweł Hajdan, Jr. wrote:
> If the discussion on this doesn't get conclusive, how about adding the
> question to the Council's agenda?

getting the Council to vote on something without real data is premature
-mike


signature.asc
Description: This is a digitally signed message part.

Re: [gentoo-dev] Can we get PIE on all SUID binaries by default, por favor?

[Paweł Hajdan, Jr.]

On 1/27/12 8:45 PM, Fabian Groffen wrote:
> On 27-01-2012 20:39:24 +0100, "Paweł Hajdan, Jr." wrote:
>> If the discussion on this doesn't get conclusive, how about adding the
>> question to the Council's agenda?
> 
> Negative from my point of view, this is an issue that the dev-community
> can solve themselves without needing a "force" from the Council.

That's why I said "if the discussion on this doesn't get conclusive". Of
course it's much better to have a consensus about that, but in some
important cases a tie-breaker can be useful.

> Just implement it in a way that people can opt-in/opt-out on it.

We already have an opt-in (hardened profile), and of course it can be
implemented in a way which allows opt-out (I even mentioned that).

The main point is changing the default.

Another note: "quiet build" default was a part of Council meeting agenda
(),
so it shouldn't be too surprising that a default important for security
is also suggested.

Again - only if we don't get a consensus here.



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Can we get PIE on all SUID binaries by default, por favor?

[Rich Freeman]

On Fri, Jan 27, 2012 at 3:13 PM, "Paweł Hajdan, Jr."
 wrote:
> On 1/27/12 8:45 PM, Fabian Groffen wrote:
>> Just implement it in a way that people can opt-in/opt-out on it.
>
> We already have an opt-in (hardened profile), and of course it can be
> implemented in a way which allows opt-out (I even mentioned that).
>
> The main point is changing the default.

Well, probably wouldn't hurt to split this out of hardened into
something intermediate first.  You won't get much testing in hardened
on many packages.

I agree that changing the default is the long-term solution.  Default
off to start but have it available on mainstream profiles.  Encourage
people to use it.  Then make it the default but let people opt-out.
Then maybe in the long-term future de-support the opt-out if it seems
prudent.  However, the hardened experience will no doubt help us.

Rich

Re: [gentoo-dev] {bi,multi}arch support for all x86/amd64/ppc/sparc systems

[Mike Frysinger]

On Wednesday 07 December 2011 17:15:47 Mike Frysinger wrote:
> the advantage is that it should obsolete the separate kgcc64 package for
> most people.  and i think it might help out with the multilib bootstrap
> issue: you can't build multilib gcc without a multilib glibc, and can't
> build a multilib glibc without a multilib gcc, but i think you should be
> able to build a multilib glibc with a multiarch gcc, and then a multilib
> gcc after that.

a followup: have glibc always install headers for all possible ABIs.  this 
might sound like a lot, but in practice, it amounts to only a handful as glibc 
by default includes support for all ABIs in common headers.

the most common example:
 - amd64 ABI has one unshared header: gnu/stubs-64.h
 - x86 ABI has three unshared headers: gnu/stubs-32.h sys/elf.h sys/vm86.h

so the overhead we're talking about here is that nomultilib amd64 systems will 
have 3 additional headers installed, and nomultilib x86 systems will have one 
extra header.  i suspect the overhead will be very similar for all arches.

the reason for doing this is to try and make multilib migration simpler.  with 
this change in place, you should be able to "upgrade" from a nomultilib amd64 
profile to a multilib amd64 profile with:
USE='-*' emerge sys-devel/gcc
emerge sys-libs/glibc
emerge sys-devel/gcc

still not as automatic as i'd like, but getting closer ...
-mike


signature.asc
Description: This is a digitally signed message part.

Re: [gentoo-dev] Can we get PIE on all SUID binaries by default, por favor?

[Jason A. Donenfeld]

On Fri, Jan 27, 2012 at 20:39, "Paweł Hajdan, Jr." wrote:
>
> The most common argument against it is performance loss I think, and
> there are probably less than 10 packages that have some compilation
> issues with PIE. In my opinion we can deal with that, and security
> benefits are much more important.


I'm *not* suggesting PIE is enabled by default for all packages. This is a
big job with performance losses, etc. I *am* suggesting that PIE is enabled
for all SUID binaries.

Re: [gentoo-dev] Can we get PIE on all SUID binaries by default, por favor?

[Jason A. Donenfeld]

On Fri, Jan 27, 2012 at 20:43, Mike Frysinger  wrote:
>
> a QA warning doesn't help anyone if we don't have documentation in place
> explaining to people how to do this cleanly


This is very true.


@Flameeyes: Could you advise on the best, cleanest way to do this? What
should the general instruction be?

Re: [gentoo-dev] Can we get PIE on all SUID binaries by default, por favor?

[Jason A. Donenfeld]

On Fri, Jan 27, 2012 at 21:13, "Paweł Hajdan, Jr." wrote:
>
> Again - only if we don't get a consensus here.
>
>
Wait... Is anybody here *actually opposed* to not enabling PIE on *SUID
binaries*?

[gentoo-dev] Last rites: app-text/xpdf

[Andreas K. Huettel]

# Andreas K. Hüttel  (27 Jan 2012)
# Has developed into an unmaintainable mess, and everyone who
# knows about it is either retired or missing in action. 
# Several minor bugs and one ugly security issues (#386271).
# Masked for removal because of lack of maintainer.

-- 

Andreas K. Huettel
Gentoo Linux developer 
dilfri...@gentoo.org
http://www.akhuettel.de/



signature.asc
Description: This is a digitally signed message part.

[gentoo-dev] econf's localstatedir default doesn't match GNU suggestions

[W. Trevor King]

I'm curious abotu why econf uses

  "${EPREFIX}"/var/lib

for the default value of localstatedir, when the GNU coding standards
[1] and autoconf site default examples [2] both suggest

  $(prefix)/var

Not that it's a big deal to add

  src_configure()
  {
econf --localstatedir="${EPREFIX}"/var
  }

to an ebuild, but the missmatch is odd.  I did some digging through
the history of both Portage and PMS, but didn't find anything clear.
PMS has had that value as the default since

  commit a686e410fd4d20f1d67b1c991936de78379d00c1
  Author: Stephen Bennett 
  Date:   Tue Mar 6 18:44:21 2007 +

Add build commands section based on pioto's patch. Add a TODO
command using the fixme package, and change todiscuss to use this
too. Possibly other misc changes.

which is not very informative on it's own.  Portage has had the value
since

  commit d9fc4acc572c6647a4f27b838d35d27d805d190e
  Author: Jason Stubbs 
  Date:   Sun Aug 28 08:37:44 2005 +

Migration (without history) of the current stable line to subversion.

Also not very helpful.

Anyhow, there is obviously a good deal of history here.  Looking
through the ebuilds of packages on my system that do have something in
`/var/lib`, it looks like they either don't use autoconf
(e.g. sys-apps/portage), hardcode the path (i.e. avoid using
localstatedir, e.g. app-admin/eselect and app-crypt/mit-krb5) or
override the value in their own ebuilds (e.g. x11-base/xorg-server)

  $ equery belongs -n /var/lib | while read LINE; do \
  ATOM="${LINE%% *}"; \
  grep -c localstatedir "/usr/portage/$ATOM/"*.ebuild; done

Is this one of those things that's too baked in to be worth changing,
or is this just too peripheral to have bothered anyone else?

Thanks,
Trevor

[1]: http://www.gnu.org/prep/standards/html_node/Directory-Variables.html
[2]: 
http://www.gnu.org/software/autoconf/manual/autoconf-2.63/html_node/Site-Defaults.html

-- 
This email may be signed or encrypted with GnuPG (http://www.gnupg.org).
For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy


signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Can we get PIE on all SUID binaries by default, por favor?

[Anthony G. Basile]

On 01/27/2012 02:39 PM, "Paweł Hajdan, Jr." wrote:

On 1/27/12 8:02 PM, Jason A. Donenfeld wrote:

I've just been informed that RHEL does not allow non-PIE executables. We
really should follow suit here.

I'm generally in favor of enabling more hardening features by default
(i.e. reversing the default, so that people who want to disable PIE can
still do it). Note that the hardened profile uses PIE by default iirc.


Exactly.  Jason, if you want PIE across the board (with a few 
exceptions), switch to hardened.




The most common argument against it is performance loss I think, and
there are probably less than 10 packages that have some compilation
issues with PIE. In my opinion we can deal with that, and security
benefits are much more important.

If the discussion on this doesn't get conclusive, how about adding the
question to the Council's agenda?



I'm trying to measure the perf difference on amd64 even as I type this.  
With nbench I'm only seeing about a 4% hit with PIE.  I'm going to try 
to narrow it down to some POC code that you can play with.  Mostly the 
hit comes on setting up call stacks because of the extra machinery in 
PIE.  When I've investigated further I'll let the list know.


--
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail: bluen...@gentoo.org
GnuPG FP  : 8040 5A4D 8709 21B1 1A88  33CE 979C AF40 D045 5535
GnuPG ID  : D0455535

Re: [gentoo-dev] econf's localstatedir default doesn't match GNU suggestions

[Mike Frysinger]

On Friday 27 January 2012 16:21:21 W. Trevor King wrote:
> I'm curious abotu why econf uses
> 
>   "${EPREFIX}"/var/lib

my understanding is that from our sampling of packages over time, it seemed 
more common for upstream to expect this to be a path where they would dump 
state into.  so if we used /var, packages would use /var/foo/ to store their 
crap which really belongs in /var/lib/foo/.

either default is a crap one, so we went with the default that requires less 
ebuilds to specify --localstatedir themselves.  and at this point, it's not 
really possible to change the behavior with EAPI, and trying to change it in a 
newer EAPI violates the principle of least surprise.
-mike


signature.asc
Description: This is a digitally signed message part.

Re: [gentoo-dev] Can we get PIE on all SUID binaries by default, por favor?

[Mike Frysinger]

On Friday 27 January 2012 16:05:13 Jason A. Donenfeld wrote:
> On Fri, Jan 27, 2012 at 21:13, "Paweł Hajdan, Jr." wrote:
> > Again - only if we don't get a consensus here.
> 
> Wait... Is anybody here *actually opposed* to not enabling PIE on *SUID
> binaries*?

he was talking system wide

considering the number set*id binaries in the tree, and their requirements 
(they tend to not be performance sensitive in the slightest), i don't have a 
problem with steering them in the PIE direction.

ignoring /usr/bin/Xorg here of course, but that has a lot more problems that i 
doubt PIE will make much of a difference.
-mike


signature.asc
Description: This is a digitally signed message part.

[gentoo-dev] useless set*id binaries

[Mike Frysinger]

hmm, i wonder why mount.nfs is set*id.  if we require everyone to use `mount`, 
there's no need for `mount.nfs` to be set*id.  someone want to point out 
something obvious that i'm missing before i adjust the nfs-utils package ?

along these lines, why is cdrtools set*id ?  if we have a "cdrom" group, and 
we assign our cdroms/dvdroms to that group, then we already have access 
control in place and can skip the set*id.
-mike


signature.asc
Description: This is a digitally signed message part.

Re: [gentoo-dev] useless set*id binaries

[Samuli Suominen]

On 01/28/2012 02:14 AM, Mike Frysinger wrote:

hmm, i wonder why mount.nfs is set*id.  if we require everyone to use `mount`,
there's no need for `mount.nfs` to be set*id.  someone want to point out
something obvious that i'm missing before i adjust the nfs-utils package ?

along these lines, why is cdrtools set*id ?  if we have a "cdrom" group, and
we assign our cdroms/dvdroms to that group, then we already have access
control in place and can skip the set*id.
-mike


cdrtools can't probe the drives without the binary being setuid, or the 
user belonging to the 'disk' group (and even that is not enough in some 
cases if the permissions vary)

Re: [gentoo-dev] useless set*id binaries

[Mike Frysinger]

On Friday 27 January 2012 19:18:07 Samuli Suominen wrote:
> On 01/28/2012 02:14 AM, Mike Frysinger wrote:
> > along these lines, why is cdrtools set*id ?  if we have a "cdrom" group,
> > and we assign our cdroms/dvdroms to that group, then we already have
> > access control in place and can skip the set*id.
> 
> cdrtools can't probe the drives without the binary being setuid, or the
> user belonging to the 'disk' group (and even that is not enough in some
> cases if the permissions vary)

the drives are owned by the "cdrom" group and have group +rw.  so if the user 
is in the "cdrom" group, why can't they probe the drives ?

"disk" owns the non-removable hard drives.

$ ls -l /dev/sr0 /dev/sg0 /dev/sg6
crw-rw 1 root disk  21, 0 Jan  6 23:07 /dev/sg0
crw-rw 1 root cdrom 21, 6 Jan  6 23:07 /dev/sg6
brw-rw 1 root cdrom 11, 0 Jan 17 22:28 /dev/sr0
-mike


signature.asc
Description: This is a digitally signed message part.

Re: [gentoo-dev] useless set*id binaries

[Samuli Suominen]

On 01/28/2012 02:41 AM, Mike Frysinger wrote:

On Friday 27 January 2012 19:18:07 Samuli Suominen wrote:

On 01/28/2012 02:14 AM, Mike Frysinger wrote:

along these lines, why is cdrtools set*id ?  if we have a "cdrom" group,
and we assign our cdroms/dvdroms to that group, then we already have
access control in place and can skip the set*id.


cdrtools can't probe the drives without the binary being setuid, or the
user belonging to the 'disk' group (and even that is not enough in some
cases if the permissions vary)


the drives are owned by the "cdrom" group and have group +rw.  so if the user
is in the "cdrom" group, why can't they probe the drives ?

"disk" owns the non-removable hard drives.

$ ls -l /dev/sr0 /dev/sg0 /dev/sg6
crw-rw 1 root disk  21, 0 Jan  6 23:07 /dev/sg0
crw-rw 1 root cdrom 21, 6 Jan  6 23:07 /dev/sg6
brw-rw 1 root cdrom 11, 0 Jan 17 22:28 /dev/sr0
-mike


i dont know why, but it does probe also non-removable disks... it probes 
per bus, iirc


you can try it easily yourself:

ssuominen@null ~ $ cdrecord -scanbus
Cdrecord-ProDVD-ProBD-Clone 3.01a06 (x86_64-unknown-linux-gnu) Copyright 
(C) 1995-2011 Joerg Schilling

Linux sg driver version: 3.5.34
Using libscg version 'schily-0.9'.
scsibus0:
0,0,0 0) 'ATA ' 'WDC WD5000AADS-0' '01.0' Disk
0,1,0 1) *
0,2,0 2) *
0,3,0 3) *
0,4,0 4) *
0,5,0 5) *
0,6,0 6) *
0,7,0 7) *
scsibus1:
1,0,0   100) 'ATA ' 'ST31000333AS' 'SD25' Disk
1,1,0   101) 'TSSTcorp' 'CDDVDW SH-S223C ' 'SB06' Removable CD-ROM
1,2,0   102) *
1,3,0   103) *
1,4,0   104) *
1,5,0   105) *
1,6,0   106) *
1,7,0   107) *
scsibus4:
4,0,0   400) 'HUAWEI  ' 'Mass Storage' '2.31' Removable CD-ROM
4,1,0   401) *
4,2,0   402) *
4,3,0   403) *
4,4,0   404) *
4,5,0   405) *
4,6,0   406) *
4,7,0   407) *
scsibus5:
5,0,0   500) 'HUAWEI  ' 'TF CARD Storage ' '' Removable Disk
5,1,0   501) *
5,2,0   502) *
5,3,0   503) *
5,4,0   504) *
5,5,0   505) *
5,6,0   506) *
5,7,0   507) *
ssuominen@null ~ $ sudo chmod 755 /usr/bin/cdrecord
ssuominen@null ~ $ cdrecord -scanbus
Cdrecord-ProDVD-ProBD-Clone 3.01a06 (x86_64-unknown-linux-gnu) Copyright 
(C) 1995-2011 Joerg Schilling
cdrecord: Permission denied. Cannot open '/dev/sg0'. Cannot open or use 
SCSI driver.
cdrecord: For possible targets try 'cdrecord -scanbus'. Make sure you 
are root.

cdrecord: For possible transport specifiers try 'cdrecord dev=help'.
ssuominen@null ~ $ groups
wheel audio cdrom video games cdrw usb users portage
ssuominen@null ~ $

Re: [gentoo-dev] useless set*id binaries

[Chí-Thanh Christopher Nguyễn]

Mike Frysinger schrieb:
> along these lines, why is cdrtools set*id ?  if we have a "cdrom" group, and 
> we assign our cdroms/dvdroms to that group, then we already have access 
> control in place and can skip the set*id.
> -mike
>From the manpage, "In order to be able to use the SCSI transport
subsystem of the OS, run at highest priority and lock itself into core
cdrecord either needs to be run as root, needs to be installed suid root
or must be called via RBACs pfexec mechanism."

I guess with the advent of burnfree technology, the priority and locking
into memory have become less important.

The cdrom group will give access to /dev/sr* but not the associated /dev/sg*


Best regards,
Chí-Thanh Christopher Nguyễn

Re: [gentoo-dev] useless set*id binaries

[Mike Frysinger]

On Friday 27 January 2012 20:07:45 Samuli Suominen wrote:
> On 01/28/2012 02:41 AM, Mike Frysinger wrote:
> > On Friday 27 January 2012 19:18:07 Samuli Suominen wrote:
> >> On 01/28/2012 02:14 AM, Mike Frysinger wrote:
> >>> along these lines, why is cdrtools set*id ?  if we have a "cdrom"
> >>> group, and we assign our cdroms/dvdroms to that group, then we already
> >>> have access control in place and can skip the set*id.
> >> 
> >> cdrtools can't probe the drives without the binary being setuid, or the
> >> user belonging to the 'disk' group (and even that is not enough in some
> >> cases if the permissions vary)
> > 
> > the drives are owned by the "cdrom" group and have group +rw.  so if the
> > user is in the "cdrom" group, why can't they probe the drives ?
> > 
> > "disk" owns the non-removable hard drives.
> > 
> > $ ls -l /dev/sr0 /dev/sg0 /dev/sg6
> > crw-rw 1 root disk  21, 0 Jan  6 23:07 /dev/sg0
> > crw-rw 1 root cdrom 21, 6 Jan  6 23:07 /dev/sg6
> > brw-rw 1 root cdrom 11, 0 Jan 17 22:28 /dev/sr0
> > -mike
> 
> i dont know why, but it does probe also non-removable disks... it probes
> per bus, iirc
> 
> you can try it easily yourself:

this is a failure in cdrecord (not that surprising).  it aborts after the first 
EACCES it gets on /dev/sg# instead of continuing on.  granting set*id to a 
binary because they can't be bothered to try the next device is dumb.

$ sudo mv /dev/sg[0-5] ~/
$ sudo chmod 755 /usr/bin/cdrecord
$ cdrecord -scanbus

Cdrecord-ProDVD-ProBD-Clone 3.01a06 (x86_64-unknown-linux-gnu) Copyright (C) 
1995-2011 Joerg Schilling
TOC Type: 1 = CD-ROM
Linux sg driver version: 3.5.34
Using libscg version 'schily-0.9'.
Using libscg transport code version 'schily-scsi-linux-sg.c-1.95'
Driveropts: 'burnfree'
SCSI buffer size: 32768
scsibus7:
7,0,0   700) 'TSSTcorp' 'CDDVDW SH-S222L ' 'SB03' Removable CD-ROM
7,1,0   701) *
7,2,0   702) *
7,3,0   703) *
7,4,0   704) *
7,5,0   705) *
7,6,0   706) *
7,7,0   707) *
-mike


signature.asc
Description: This is a digitally signed message part.

Re: [gentoo-dev] useless set*id binaries

[Samuli Suominen]

On 01/28/2012 03:49 AM, Mike Frysinger wrote:

On Friday 27 January 2012 20:07:45 Samuli Suominen wrote:

On 01/28/2012 02:41 AM, Mike Frysinger wrote:

On Friday 27 January 2012 19:18:07 Samuli Suominen wrote:

On 01/28/2012 02:14 AM, Mike Frysinger wrote:

along these lines, why is cdrtools set*id ?  if we have a "cdrom"
group, and we assign our cdroms/dvdroms to that group, then we already
have access control in place and can skip the set*id.


cdrtools can't probe the drives without the binary being setuid, or the
user belonging to the 'disk' group (and even that is not enough in some
cases if the permissions vary)


the drives are owned by the "cdrom" group and have group +rw.  so if the
user is in the "cdrom" group, why can't they probe the drives ?

"disk" owns the non-removable hard drives.

$ ls -l /dev/sr0 /dev/sg0 /dev/sg6
crw-rw 1 root disk  21, 0 Jan  6 23:07 /dev/sg0
crw-rw 1 root cdrom 21, 6 Jan  6 23:07 /dev/sg6
brw-rw 1 root cdrom 11, 0 Jan 17 22:28 /dev/sr0
-mike


i dont know why, but it does probe also non-removable disks... it probes
per bus, iirc

you can try it easily yourself:


this is a failure in cdrecord (not that surprising).  it aborts after the first
EACCES it gets on /dev/sg# instead of continuing on.  granting set*id to a
binary because they can't be bothered to try the next device is dumb.

$ sudo mv /dev/sg[0-5] ~/
$ sudo chmod 755 /usr/bin/cdrecord
$ cdrecord -scanbus

Cdrecord-ProDVD-ProBD-Clone 3.01a06 (x86_64-unknown-linux-gnu) Copyright (C)
1995-2011 Joerg Schilling
TOC Type: 1 = CD-ROM
Linux sg driver version: 3.5.34
Using libscg version 'schily-0.9'.
Using libscg transport code version 'schily-scsi-linux-sg.c-1.95'
Driveropts: 'burnfree'
SCSI buffer size: 32768
scsibus7:
 7,0,0   700) 'TSSTcorp' 'CDDVDW SH-S222L ' 'SB03' Removable CD-ROM
 7,1,0   701) *
 7,2,0   702) *
 7,3,0   703) *
 7,4,0   704) *
 7,5,0   705) *
 7,6,0   706) *
 7,7,0   707) *
-mike


and people have multiple times tried to convince the cdrtools author to 
change this, but without success.

the author can be, well, ...

i've improved the situation _a bit_:

+*cdrtools-3.01_alpha06-r1 (28 Jan 2012)
+
+  28 Jan 2012; Samuli Suominen 
+  +cdrtools-3.01_alpha06-r1.ebuild:
+  Change cdda2wav, cdrecord, readcd and rscsi from suid root to sgid 
disk for

+  udev users (note: tested with cdrecord -scanbus)

Re: [gentoo-dev] useless set*id binaries

[Mike Frysinger]

On Friday 27 January 2012 20:28:04 Chí-Thanh Christopher Nguyễn wrote:
> Mike Frysinger schrieb:
> > along these lines, why is cdrtools set*id ?  if we have a "cdrom" group,
> > and we assign our cdroms/dvdroms to that group, then we already have
> > access control in place and can skip the set*id.
> 
> From the manpage, "In order to be able to use the SCSI transport
> subsystem of the OS, run at highest priority and lock itself into core
> cdrecord either needs to be run as root, needs to be installed suid root
> or must be called via RBACs pfexec mechanism."
> 
> I guess with the advent of burnfree technology, the priority and locking
> into memory have become less important.

yeah, i would think if your system is loaded enough for this to be an issue, 
it's going to be an issue anyways.  but i'd image mlock/rtprio could be 
enabled via pam and security/limits.conf for the cdrom group.

> The cdrom group will give access to /dev/sr* but not the associated
> /dev/sg*

yes, it does:
$ find -L /dev/* -maxdepth 0 -gid 19
/dev/cdrom
/dev/cdrw
/dev/dvd
/dev/dvdrw
/dev/scd0
/dev/sg6
/dev/sr0
-mike


signature.asc
Description: This is a digitally signed message part.

Re: [gentoo-dev] useless set*id binaries

[Mike Frysinger]

On Friday 27 January 2012 20:49:49 Samuli Suominen wrote:
> and people have multiple times tried to convince the cdrtools author to
> change this, but without success.
> the author can be, well, ...

sure, i'm not expecting him to be anything resembling reasonable.  but if we 
can reduce set*id impact by default and that means carrying a custom patch, i 
think that's OK.

i thought we used to have set*id USE flags, but maybe all the packages with it 
have migrated away.

my proposal would be to add a patch to ignore EACCES just like it already does 
for ENOENT.  then add a setuid USE flag that'd give the behavior we have today 
(disabled by default) for the binaries that do writing.  the ones that only 
read have no excuse for needing setuid.  then if the user has built with USE=-
setuid, we elog a message like:
you've built with USE=-setuid.  that means in order to access
your discs, you need to add yourself to the cdrom group.
if your burning does not go well, you can try adding the cdrom
group to limits.conf with rtprio/mlock access like so:

-mike


signature.asc
Description: This is a digitally signed message part.

Re: [gentoo-dev] Can we get PIE on all SUID binaries by default, por favor?

[Jason A. Donenfeld]

On Sat, Jan 28, 2012 at 01:01, Anthony G. Basile wrote:
>
>
> Exactly.  Jason, if you want PIE across the board (with a few exceptions),
> switch to hardened.
>
>
What? Are you kidding?

Again, to reiterate, *I AM NOT SUGGESTING HAVING PIE ACROSS THE BOARD.*

What I suggest is that we have PIE for SUID executable. See the subject of
this thread.

Re: [gentoo-dev] Can we get PIE on all SUID binaries by default, por favor?

[Jason A. Donenfeld]

On Sat, Jan 28, 2012 at 01:12, Mike Frysinger  wrote:
>
> > Wait... Is anybody here *actually opposed* to not enabling PIE on *SUID
> > binaries*?
>
> he was talking system wide
>

This thread is about PIE on SUID executables.


>
> considering the number set*id binaries in the tree, and their requirements
> (they tend to not be performance sensitive in the slightest), i don't have
> a
> problem with steering them in the PIE direction.
>

Great!


>
> ignoring /usr/bin/Xorg here of course, but that has a lot more problems
> that i
> doubt PIE will make much of a difference.
>

Oh boy. Yea. Oh boy. Xorg should be PIE too, I suppose. Only takes
one rotten egg.



> -mike
>

Re: [gentoo-dev] econf's localstatedir default doesn't match GNU suggestions

[Ulrich Mueller]

> On Fri, 27 Jan 2012, W. Trevor King wrote:

> I'm curious abotu why econf uses

>   "${EPREFIX}"/var/lib

> for the default value of localstatedir, when the GNU coding
> standards [1] and autoconf site default examples [2] both suggest

>   $(prefix)/var

Right, and their $(prefix) defaults to /usr/local whereas ours
defaults to /usr. So the default localstatedir would be /usr/local/var
or /usr/var, respectively. While the former may make some sense, the
latter doesn't (and it violates the FHS).

> Not that it's a big deal to add

>   src_configure()
>   {
> econf --localstatedir="${EPREFIX}"/var
>   }

> to an ebuild, but the missmatch is odd. [...]

That's not the same, the equivalent of $(prefix)/var is not
"${EPREFIX}"/var but "${EPREFIX}"/usr/var.

> [1]: http://www.gnu.org/prep/standards/html_node/Directory-Variables.html
> [2]: 
> http://www.gnu.org/software/autoconf/manual/autoconf-2.63/html_node/Site-Defaults.html

Re: [gentoo-dev] useless set*id binaries

[Ulrich Mueller]

> On Sat, 28 Jan 2012, Samuli Suominen wrote:

> i've improved the situation _a bit_:

> +*cdrtools-3.01_alpha06-r1 (28 Jan 2012)
> +
> +  28 Jan 2012; Samuli Suominen 
> +  +cdrtools-3.01_alpha06-r1.ebuild:
> +  Change cdda2wav, cdrecord, readcd and rscsi from suid root to sgid 
> disk for
> +  udev users (note: tested with cdrecord -scanbus)

This is definitely not an improvement and should be reverted. The suid
root is also needed to elevate cdrecord's scheduling priority.

And is this such an urgent matter that there wasn't time to file a
proper bug? Or have you discussed this change with the package's
maintainer?

if has_version sys-fs/udev; then
fowners root:disk /usr/bin/{cdda2wav,cdrecord,readcd} 
/usr/sbin/rscsi
fperms u-s,g+s /usr/bin/{cdda2wav,cdrecord,readcd} 
/usr/sbin/rscsi
fi

Automagic dependency on udev in src_install? Oh my.

Ulrich

Re: [gentoo-dev] useless set*id binaries

[Samuli Suominen]

On 01/28/2012 08:28 AM, Ulrich Mueller wrote:

On Sat, 28 Jan 2012, Samuli Suominen wrote:



i've improved the situation _a bit_:



+*cdrtools-3.01_alpha06-r1 (28 Jan 2012)
+
+  28 Jan 2012; Samuli Suominen
+  +cdrtools-3.01_alpha06-r1.ebuild:
+  Change cdda2wav, cdrecord, readcd and rscsi from suid root to sgid
disk for
+  udev users (note: tested with cdrecord -scanbus)


This is definitely not an improvement and should be reverted. The suid
root is also needed to elevate cdrecord's scheduling priority.


Missed that piece of code and reverted then. Any chance you could be 
more specific?



 if has_version sys-fs/udev; then
 fowners root:disk /usr/bin/{cdda2wav,cdrecord,readcd} 
/usr/sbin/rscsi
 fperms u-s,g+s /usr/bin/{cdda2wav,cdrecord,readcd} 
/usr/sbin/rscsi
 fi

Automagic dependency on udev in src_install? Oh my.


I don't consider this as a automagic to be worried about at all.
Was bouncing back and forth with 'use kernel_linux' or 'has_version 
sys-fs/udev', since wasn't sure how other devmanagers have permissions 
set. But I guess this is now irrelevant since it's reverted.

[gentoo-dev] Lastrite: dev-java/sun-j2ee

[Ralph Sennhauser]

# Ralph Sennhauser  (28 Jan 2012)
# Hopelessly outdated, contains broken jars. #91484
# Removal in 30 days.
dev-java/sun-j2ee


signature.asc
Description: PGP signature