> "Raul" == Raul Miller <[EMAIL PROTECTED]> writes:
Raul> Once they're in the file system, they won't only elevate
Raul> privilege. At that point, programs can be denied privilege
Raul> (even if the user process has the capability, the program
Raul> will drop it).
Raul> I
> Raul> [Also: both have extra baggage, but MAC+capabilities looks
> Raul> like something safer to switch over to than capabilities
> Raul> without MAC.]
>
On Fri, Sep 29, 2000 at 03:20:22PM +1100, Brian May wrote:
> Where can I find out more about MAC? MAC is a completely new acronym
> "Raul" == Raul Miller <[EMAIL PROTECTED]> writes:
Raul> Or, put another way, we're going to have to re-write a lot
Raul> of administrative docs to adapt to a capabilities-based
Raul> security setup. And then we'll have to do it again for
Raul> MAC.
;-)
or should that be
On Wed, Sep 27, 2000 at 08:59:20PM -0400, Jonathan D. Proulx wrote:
> However after further reading I stand by my previous assertion that
> slapping capapilities ontop of a Un*x like system is asking for
> trouble.
Depends what you do.
> Are we really going to get anything valuable out of this? W
On Tue, Sep 26, 2000 at 10:07:28PM -0400, Raul Miller wrote:
:Warning: I'm not an expert.
Nor I..
Additional Warning: This has turned into somewhat of a rant...
However after further reading I stand by my previous assertion that
slapping capapilities ontop of a Un*x like system is asking for
tro
Warning: I'm not an expert.
On Wed, Sep 27, 2000 at 10:54:04AM +1100, Brian May wrote:
> - is root still required? If so why and what for?
Exactly.
Or, put another way, we're going to have to re-write a lot
of administrative docs to adapt to a capabilities-based
security setup. And then we'll
> "s" == s Lichtmaier writes:
>> > That's not true, capabilities can be handled with system
>> calls. A daemon > may drop all capabilities except the one
>> needed to bind to privileged ports. > But the daemon would
>> still be ran with UID 0, and be able to modify/access > a
Carl R. Witty wrote:
> There is at least one way in which root is less vulnerable than bin to
> cracking. If your machine has files exported via NFS with
> root_squash, then somebody who cracks root on a client machine can
> modify files owned by bin on your machine, but not files owned by
> root.
Joey Hess <[EMAIL PROTECTED]> writes:
> Nicolás Lichtmaier wrote:
> > Your point is so obvious. duh... how did I miss that?
> > Of course that cracking bin would be like cracking root...!
>
> This is not an issue if
>
> a) bin has no passowrd so people cannot log in as bin
> and
> b) nothing on
Seth Arnold wrote:
> > This is not an issue if
> >
> > a) bin has no passowrd so people cannot log in as bin
> > and
> > b) nothing on the system is suid bin
>
> Joey, if bin owns ls, then someone that cracks the bin account (via some
> non-interactive means) could replace ls with a version of ls
* Joey Hess <[EMAIL PROTECTED]> [000926 14:52]:
> Nicolás Lichtmaier wrote:
> > Your point is so obvious. duh... how did I miss that?
> > Of course that cracking bin would be like cracking root...!
>
> This is not an issue if
>
> a) bin has no passowrd so people cannot log in as bin
> and
> b)
Nicolás Lichtmaier wrote:
> Your point is so obvious. duh... how did I miss that?
> Of course that cracking bin would be like cracking root...!
This is not an issue if
a) bin has no passowrd so people cannot log in as bin
and
b) nothing on the system is suid bin
--
see shy jo
> > But anyway, capabilities are useable without fs support.
>
> Definitely. Some daemons like proftpd already use them.
>
> Also, keep in mind that the set of capilities differs between 2.2 and
> 2.4 kernels if memory serves me correctly, and people are still looking
> at making sure the curren
>
> Also, keep in mind that the set of capilities differs between 2.2 and
> 2.4 kernels if memory serves me correctly, and people are still looking
> at making sure the current set is an optimal one. (Fun assignment: see
> which capabilities can lead to root access. It turns out to be a
> surpris
> > > That would not be a logical step. Right now programs such as rlogin, ssh,
> > > NFS etc make sure that you cannot login as root or that root rights
> > > get smashed. If your box is cracked somehow, it often is the case that
> > > people can get any userid they like _except_ root. If the syst
Miquel van Smoorenburg <[EMAIL PROTECTED]>, wrote:
> > That would not be a logical step. Right now programs such as rlogin, ssh,
> > NFS etc make sure that you cannot login as root or that root rights
> > get smashed. If your box is cracked somehow, it often is the case that
> > people can get any
> > It seems that in order to take full advantage of capabilities, files should
> >not be owned by root. Files should be owned by a non-login user (e.g. bin).
>
> That would not be a logical step. Right now programs such as rlogin, ssh,
> NFS etc make sure that you cannot login as root or that roo
In article <[EMAIL PROTECTED]>,
=?iso-8859-1?Q?Nicol=E1s_Lichtmaier?= <[EMAIL PROTECTED]> wrote:
> It seems that in order to take full advantage of capabilities, files should
>not be owned by root. Files should be owned by a non-login user (e.g. bin).
That would not be a logical step. Right now p
In article <[EMAIL PROTECTED]>,
=?iso-8859-1?Q?Nicol=E1s_Lichtmaier?= <[EMAIL PROTECTED]> wrote:
>> I wonder if you're read linux-kernel recently, resource forks definitely
>> will never be part of (mainstream) Linux. Nasty evil things!
>
> I think that Linus has recently said he wouldn't be oppos
> > Yes, you are right, I was probably too optimisitic with that. But, perhaps,
> > the "general change" will be the modification of EXT2 to support "resource
> > forks", but the needed changes in the VFS are probably small, and perhaps,
> > one of those new filesystems will include capabilities b
Previously Nicolás Lichtmaier wrote:
> > Capabilities are the future of security in Linux. Capabilities
> > are supported in the kernel Debian is now shipping with potato. FS
> > support will surely be one of the first things added to 2.5.
On Sat, Sep 23, 2000 at 12:09:51AM +0200, Wichert Akkerma
Previously Nicolás Lichtmaier wrote:
> Yes, you are right, I was probably too optimisitic with that. But, perhaps,
> the "general change" will be the modification of EXT2 to support "resource
> forks", but the needed changes in the VFS are probably small, and perhaps,
> one of those new filesystem
> > That's not true, capabilities can be handled with system calls. A daemon
> > may drop all capabilities except the one needed to bind to privileged ports.
> > But the daemon would still be ran with UID 0, and be able to modify/access
> > any root owned file in the system.
> Granted. Application
> > That's not true, capabilities can be handled with system calls. A daemon
> > may drop all capabilities except the one needed to bind to privileged ports.
> > But the daemon would still be ran with UID 0, and be able to modify/access
> > any root owned file in the system.
>
> Why wouldn't it a
Previously Nicolás Lichtmaier wrote:
> That's not true, capabilities can be handled with system calls. A daemon
> may drop all capabilities except the one needed to bind to privileged ports.
> But the daemon would still be ran with UID 0, and be able to modify/access
> any root owned file in the s
On Fri, Sep 22, 2000 at 06:44:02PM -0300, Nicolás Lichtmaier wrote:
> That's not true, capabilities can be handled with system calls. A daemon
> may drop all capabilities except the one needed to bind to privileged ports.
> But the daemon would still be ran with UID 0, and be able to modify/access
> > It seems that in order to take full advantage of capabilities, files should
> > not be owned by root. Files should be owned by a non-login user (e.g. bin).
>
> I don't believe that is true at all. Can you explain why you think that
> would be advantageous?
>
> > That's because root will be
Joey Hess <[EMAIL PROTECTED]> writes:
> Marcus Brinkmann wrote:
> > Don't forget that joeyh has the biggest harddrive of the world. He must
> > have, because he has a maximum number of Debian packages installed.
> >
> > (Joey, what is the maximum number of Debian packages you can install without
Marco d'Itri wrote:
> On Sep 21, Joey Hess <[EMAIL PROTECTED]> wrote:
>
> >Using an existing group like bin could cause problems. It's possible
> >systems exist that have users in the bin group and don't expect them to
> >suddenly be able to edit every file on the system. (What is the bin
> I d
Marcus Brinkmann wrote:
> Don't forget that joeyh has the biggest harddrive of the world. He must
> have, because he has a maximum number of Debian packages installed.
>
> (Joey, what is the maximum number of Debian packages you can install without
> having a conflict?)
Bah. Bah I say.
[EMAIL PR
On 20-Sep-00, 23:29 (CDT), Nicol?s Lichtmaier <[EMAIL PROTECTED]> wrote:
[Manoj wrote:]
> > Umm, before we start proposing this, we should ahve a pilot
> > project, and have a few machines, including some running servers,
> > that run like this, and see what breaks. We can then rty changing
On Sep 21, Joey Hess <[EMAIL PROTECTED]> wrote:
>Using an existing group like bin could cause problems. It's possible
>systems exist that have users in the bin group and don't expect them to
>suddenly be able to edit every file on the system. (What is the bin
I don't agree. Being the owner of s
Previously Nicolás Lichtmaier wrote:
> It seems that in order to take full advantage of capabilities, files should
> not be owned by root. Files should be owned by a non-login user (e.g. bin).
I don't believe that is true at all. Can you explain why you think that
would be advantageous?
> That'
On Thu, Sep 21, 2000 at 09:57:34PM +1100, Brendan O'Dea wrote:
> On Thu, Sep 21, 2000 at 01:43:52AM -0700, Joey Hess wrote:
> >Nicolás Lichtmaier wrote:
> >> It should be:
> >>
> >> -rwxr-xr-x1 bin bin 42300 jul 29 13:26 /bin/ls*
> >>
> >Using an existing group like bin could ca
On Thu, Sep 21, 2000 at 01:43:52AM -0700, Joey Hess wrote:
>Nicolás Lichtmaier wrote:
>> It should be:
>>
>> -rwxr-xr-x1 bin bin 42300 jul 29 13:26 /bin/ls*
>>
>Using an existing group like bin could cause problems. It's possible
>systems exist that have users in the bin group a
Nicolás Lichtmaier wrote:
> It should be:
>
> -rwxr-xr-x1 bin bin 42300 jul 29 13:26 /bin/ls*
>
> That's because root will be just another user, with its set of
> capabilities, and you may like to prevent him from altering system files.
> As this is a major change, we'd better
> Nicolás> That's because root will be just another user, with its set of
> Nicolás> capabilities, and you may like to prevent him from altering
> Nicolás> system files.
>
> Nicolás> As this is a major change, we'd better start now. This will
> Nicolás> also help people who want to implement
>>"Nicolás" == Nicolás Lichtmaier <[EMAIL PROTECTED]> writes:
Nicolás> That's because root will be just another user, with its set of
Nicolás> capabilities, and you may like to prevent him from altering
Nicolás> system files.
Nicolás> As this is a major change, we'd better start now. This wi
It seems that in order to take full advantage of capabilities, files should
not be owned by root. Files should be owned by a non-login user (e.g. bin).
Currently:
-rwxr-xr-x1 root root42300 jul 29 13:26 /bin/ls*
It should be:
-rwxr-xr-x1 bin bin 42300 jul 29
39 matches
Mail list logo
