I'm still very unclear about what is going on here with access control.
Either the utility provides useful access control, and thus needs auditing.
Or it provides no such access control (such access control is
effectively useless), and the access control directives should not be
used. (One cou
On Tue, Mar 18, 2008 at 02:38:32PM -0700, Michael Shapiro wrote:
> Let's say my installer then runs and wants to know which two disks
> it should use as the thing to install onto.
>
> The only way to do that is to ask the BIOS as to its boot device list
> in the way that biosdev does, i.e. grab t
That's wierd but the info about the auditing got off on my original
email. Let me cut/paste it from the mail log.
Auditing did not seem to be needed.
From Nicolas.Williams Mon Mar 17 09:05:38 2008
...
The more interesting question is whether rmt is setuid [or re-execs
itself through pfe
Gary,
I just noticed your email subject line has the old expiration date
so maybe you did not see the new spec that was sent out last week.
Here is the updated spec that was sent out last week (changes included
adding the environment variables used, Garrett's suggestion to
make the command links
There have been no changes to the spec since the last time it
was sent. Let me send that in a separate email and answer
the questions below in this email.
Regards,
Margot
Gary Winiger wrote:
> Now this case has over 250 messages. IMO, it's time for the case
> submitter and case owne
Now this case has over 250 messages. IMO, it's time for the case
submitter and case owner to get together a new (current) spec.
Until then, IMO, it's impossible to winnow the case log.
I'm not sure what the answers are to the comments I posed last week.
To
Margot Miller wrote:
> Thanks Alan for this info. Have added Ted Pogue to
> this email thread as he submitted the SAM-QFS case.
>
> Looks like there are about 30 SAM-QFS commands. The
> man pages explicitly give the path to the command. I would
> imagine with that many product specific command
> > The reset-to-default behavior depends on the hardware's capability. Some
> > scanners support reset operation. Upon device close/open, a reset
> > command will be sent to the device. For those that don't support
> > hardware reset, the backend will call its own init_options() or similar
>
Joerg Schilling wrote:
> I have been told that the samfs people call their programs from scripts.
>
> Given the fact that star is widely known and much older it is obvious that
> the
> samfs people need to find a new name in case they like their program to be
> called directly from command lin
In my original materials for PSARC/2008/130 CUPS 1.3.6 I designated an
interface stability of "Volatile" for
the libcups and libcupsimage interfaces. I don't believe that we are
likely to see incompatible change in these interfaces from the open
source project and there are potentially a numbe
Garrett D'Amore wrote:
> An interesting project, especially if the security folks have an intern
> they can throw at it, might be to try to adapt libmcrypt so it can use
> the encryption framework, or to write a thin-layer libmcrypt API shim on
> top of the encryption framework.
Interesting yes
On Mon, Mar 17, 2008 at 08:33:22PM -0700, Scott Rotondo wrote:
> Ken said in another email that rmt does not run with privilege, acquired
> via setuid or pfexec. Can I also assume that there is no daemon running
> as root?
>
> Assuming that the answer is yes, and rmt really is unprivileged, ther
On Tue, Mar 18, 2008 at 10:03:20PM +, John Levon wrote:
> On Tue, Mar 18, 2008 at 02:38:32PM -0700, Michael Shapiro wrote:
>
> > Let's say my installer then runs and wants to know which two disks
> > it should use as the thing to install onto.
> >
> > The only way to do that is to ask the BIO
On Tue, Mar 18, 2008 at 02:50:38PM -0700, Vikram Hegde wrote:
> Hi,
>
> I should have mentioned this in the case materials but there are two
> classes of problems for which biosdev can be used
>
> 1. Populating the GRUB menu.lst with root(?) entries
>
> 2. Determining the boot disk or determini
Hi,
I should have mentioned this in the case materials but there are two
classes of problems for which biosdev can be used
1. Populating the GRUB menu.lst with root(?) entries
2. Determining the boot disk or determining the accessibility (to BIOS)
of various disks.
The intent of the proposal
>
> findroot - biosdev replacement
> ==
>
> BACKGROUND
>
>
> biosdev is a private utility that was introduced by the Newboot x86 project
> (PSARC/2004/454). It's primary purpose is to map B
Alan Coopersmith wrote:
> Margot Miller wrote:
>
>>- /usr/bin/star executable added
>>
>
> Joerg just raised an important point on opensolaris-discuss -
> star has a name-clash with Sun's SAM-QFS star command (which
> much to Joerg's consternation is based on GNU tar sources
> inste
Scott Rotondo wrote:
> Changing or removing /etc/default/rmt wouldn't make a difference. After
> all, it's a configurable interface and the customer could put back
> whatever contents we remove, right?
>
> The point is that we're inferring from the sample config file that the
> rmt code makes
This is going to be a general problem with these kind of "serendipitous
discovery" cases. There are a lot of freeware programs out there, and
name collisions are not uncommon. There is no central registry of
command names, so the prevailing policy is anarchy.
Making the situation much worse i
Joerg Schilling wrote:
> Scott Rotondo wrote:
>
>> Changing or removing /etc/default/rmt wouldn't make a difference. After
>> all, it's a configurable interface and the customer could put back
>> whatever contents we remove, right?
>>
>> The point is that we're inferring from the sample config
Darren J Moffat wrote:
> >> The more interesting question is whether rmt is setuid [or re-execs
> >> itself through pfexec(1)]. If it isn't then I suspect this doesn't
> >> matter. If it is then its access control decisions should be audited.
> >
> > I am a bit confused about this question.
>
"Garrett D'Amore" wrote:
> What about a third option: leave the existing Sun rmt in place, and
> deliver just star? I'm trying to figure out what problem Shillix
> /etc/rmt is trying to solve for us, and I confess, that I'm having a
> hard time seeing it. (The original case indicated interes
Joerg Schilling wrote:
> Darren J Moffat wrote:
>
The more interesting question is whether rmt is setuid [or re-execs
itself through pfexec(1)]. If it isn't then I suspect this doesn't
matter. If it is then its access control decisions should be audited.
>>> I am a bit confused a
Joerg Schilling wrote:
> "Garrett D'Amore" wrote:
>
>> What about a third option: leave the existing Sun rmt in place, and
>> deliver just star? I'm trying to figure out what problem Shillix
>> /etc/rmt is trying to solve for us, and I confess, that I'm having a
>> hard time seeing it. (The
Joerg Schilling wrote:
> Nicolas Williams wrote:
>
>>> Is there auditing for the access control that is controlled by ~/.rhosts and
>>> /etc/ssh/sshd_config?
>> Yes (see Darren's response).
>>
>> The more interesting question is whether rmt is setuid [or re-execs
>> itself through pfexec(1)]. If
Joerg Schilling wrote:
> "Garrett D'Amore" wrote:
>
>
>> What about a third option: leave the existing Sun rmt in place, and
>> deliver just star? I'm trying to figure out what problem Shillix
>> /etc/rmt is trying to solve for us, and I confess, that I'm having a
>> hard time seeing it. (
Thanks Alan for this info. Have added Ted Pogue to
this email thread as he submitted the SAM-QFS case.
Looks like there are about 30 SAM-QFS commands. The
man pages explicitly give the path to the command. I would
imagine with that many product specific commands they set
the $PATH. But what ha
An interesting project, especially if the security folks have an intern
they can throw at it, might be to try to adapt libmcrypt so it can use
the encryption framework, or to write a thin-layer libmcrypt API shim on
top of the encryption framework.
That is assuming that our encryption is better
-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 193 bytes
Desc: not available
URL:
<http://mail.opensolaris.org/pipermail/opensolaris-arc/attachments/20080318/1108eeb2/attachment.bin>
James -
There are two problems with this:
- The microcode status is exposed as part of a plugin, not as core
libses functionality. So there is no way to expose a function on top
of that. Any additional information should be presented in the
nvlist, not as part of a separate callback.
- S
Margot Miller wrote:
>- /usr/bin/star executable added
Joerg just raised an important point on opensolaris-discuss -
star has a name-clash with Sun's SAM-QFS star command (which
much to Joerg's consternation is based on GNU tar sources
instead of his).
>From PSARC/2001/599 it looks like S
I'm sorry that I have not been aware on this discussion.
Recently the similar bugs were reported and I was investigating the
root cause, and found that the last week.
I found two bugs in sfe. I'm sorry that I made them when I cleaned up
the source code to put it back into opensolaris.
The probl
Template Version: @(#)sac_nextcase 1.64 07/13/07 SMI
This information is Copyright 2008 Sun Microsystems
1. Introduction
1.1. Project/Component Working Name:
libmcrypt
1.2. Name of Document Author/Supplier:
Author: Darren Moffat
1.3 Date of This Document:
18
Eric Schrock wrote:
> On Mon, Mar 17, 2008 at 10:01:36AM +1000, James C. McPherson wrote:
>> Hi Eric,
>> Could we get some common status code mappings / handlers
>> added to ses2.h? Something common that makes use of the
>> definitions in ses2_dl_ucode_status would probably be a
>> good thing.
>>
>
34 matches
Mail list logo
