API to collect some unique IDs - Security

This is a discussion on API to collect some unique IDs - Security ; Hi all, Is there any API to collect some unique IDs (such as CPU id, harddisk id, SKU, etc) from the system w/o running the final software as root? I've looked into dmidecode.c but it is unable to read /dev/mem ...

+ Reply to Thread
Page 1 of 2 1 2 LastLast
Results 1 to 20 of 22

Thread: API to collect some unique IDs

  1. API to collect some unique IDs

    Hi all,

    Is there any API to collect some unique IDs (such as CPU id, harddisk id,
    SKU, etc) from the system w/o running the final software as root?

    I've looked into dmidecode.c but it is unable to read /dev/mem without the
    root account. Going further, demicode cannot be run even if the user is
    added to the kmem group. Is there anyway to get past this? I am using
    Ubuntu 7.10

    Thanks and best rgds,
    Alex



  2. Re: API to collect some unique IDs

    On 2008-02-21 14:39, Alex wrote:
    > Hi all,
    >
    > Is there any API to collect some unique IDs (such as CPU id, harddisk id,
    > SKU, etc) from the system w/o running the final software as root?
    >
    > I've looked into dmidecode.c but it is unable to read /dev/mem without the
    > root account. Going further, demicode cannot be run even if the user is
    > added to the kmem group. Is there anyway to get past this? I am using
    > Ubuntu 7.10
    >
    > Thanks and best rgds,
    > Alex
    >
    >


    Maybe you have something useful in mind, but every time I had heard this
    question, it come from someone that just don't get the idea with free or
    open software, and will figure out a way to "protect" their software,
    and is trying to figure out a way to make a program that refuse to work
    when copied, and will be a big problems for the few customers one day
    when then replace a machine and you are gone and forgotten.

    /bb

  3. Re: API to collect some unique IDs

    Alex schrieb:
    >
    > Is there any API to collect some unique IDs (such as CPU id, harddisk id,
    > SKU, etc) from the system w/o running the final software as root?
    >

    For which purpose you need such an API? Some licensing scheme?

    Note that if a geneneric API for such things existed, it would be easy to
    circumvent. Enforcing licenses on a user-controlled machine must be done in
    an obscure way so the cracker has to take more effort than the software's
    worth.

    Kind regards

    Jan

  4. Re: API to collect some unique IDs

    On Feb 21, 5:39 am, "Alex" wrote:
    > Hi all,
    >
    > Is there any API to collect some unique IDs (such as CPU id, harddisk id,
    > SKU, etc) from the system w/o running the final software as root?
    >
    > I've looked into dmidecode.c but it is unable to read /dev/mem without the
    > root account. Going further, demicode cannot be run even if the user is
    > added to the kmem group. Is there anyway to get past this? I am using
    > Ubuntu 7.10


    Just pick a reasonable file name '/etc/unique_id' and document that a
    unique world-readable identifier must be placed there. Don't run
    unless there's an ID there. You can create your own randomly on
    installation if you like, if it's 160-bits or more, it's sufficiently
    likely to be unique as makes no difference.

    DS

  5. Re: API to collect some unique IDs

    Alex wrote:
    > Hi all,
    >
    > Is there any API to collect some unique IDs (such as CPU id, harddisk id,
    > SKU, etc) from the system w/o running the final software as root?


    Well... you could run at root via some kind of roll based mechanism (e.g. sudo).
    But barring that, there's a lot of this kind of info populated into /sys...
    go exploring.

    This little tool I wrote might help with exploring /sys...
    http://endlessnow.com/ten/Source/showsysfs-sh.txt

    >
    > I've looked into dmidecode.c but it is unable to read /dev/mem without the
    > root account. Going further, demicode cannot be run even if the user is
    > added to the kmem group. Is there anyway to get past this? I am using
    > Ubuntu 7.10
    >
    > Thanks and best rgds,
    > Alex
    >
    >


  6. Re: API to collect some unique IDs

    ....snippity...

    And examine hal too... lshal

  7. Re: API to collect some unique IDs

    Chris Cox writes:

    > Alex wrote:
    >> Hi all,
    >>
    >> Is there any API to collect some unique IDs (such as CPU id,
    >> harddisk id, SKU, etc) from the system w/o running the final
    >> software as root?

    >
    > Well... you could run at root via some kind of roll based mechanism
    > (e.g. sudo).


    And how is that not running as root or rootlike for the duration of the
    program which needs root access for the accesses he was mentioning?

    > But barring that, there's a lot of this kind of info populated into /sys...
    > go exploring.
    >
    > This little tool I wrote might help with exploring /sys...
    > http://endlessnow.com/ten/Source/showsysfs-sh.txt
    >
    >>
    >> I've looked into dmidecode.c but it is unable to read /dev/mem
    >> without the root account. Going further, demicode cannot be run
    >> even if the user is added to the kmem group. Is there anyway to get
    >> past this? I am using Ubuntu 7.10
    >>
    >> Thanks and best rgds,
    >> Alex
    >>
    >>


    --
    Murphy was an optimist.

  8. Re: API to collect some unique IDs

    Hadron wrote:
    > Chris Cox writes:
    >
    >> Alex wrote:
    >>> Hi all,
    >>>
    >>> Is there any API to collect some unique IDs (such as CPU id,
    >>> harddisk id, SKU, etc) from the system w/o running the final
    >>> software as root?

    >> Well... you could run at root via some kind of roll based mechanism
    >> (e.g. sudo).

    >
    > And how is that not running as root or rootlike for the duration of the
    > program which needs root access for the accesses he was mentioning?


    Oddly enough key system processes are running as root on his
    box by default (believe it or not).

    What was your point? Other than trying to pick a fight?

    I was trying to help.. and you were???

    Sometimes people don't understand security. They simply
    need somebody to help them to better understand how things
    work. If you can't run something in a controlled manner
    as root.. you've got to simply turn the machine off.

  9. Re: API to collect some unique IDs

    Alex schreef:
    > Hi all,
    >
    > Is there any API to collect some unique IDs (such as CPU id, harddisk id,
    > SKU, etc) from the system w/o running the final software as root?
    >
    > I've looked into dmidecode.c but it is unable to read /dev/mem without the
    > root account. Going further, demicode cannot be run even if the user is
    > added to the kmem group. Is there anyway to get past this? I am using
    > Ubuntu 7.10
    >
    > Thanks and best rgds,
    > Alex
    >
    >

    Not so unique is the result of
    $ lspci

    But the combination of results is less than common.

    Having a look in /etc/fstab for the UUID of the hard disk is more unique
    yet it can be spoofed.

  10. Re: API to collect some unique IDs

    Chris Cox writes:

    > Hadron wrote:
    >> Chris Cox writes:
    >>
    >>> Alex wrote:
    >>>> Hi all,
    >>>>
    >>>> Is there any API to collect some unique IDs (such as CPU id,
    >>>> harddisk id, SKU, etc) from the system w/o running the final
    >>>> software as root?
    >>> Well... you could run at root via some kind of roll based mechanism
    >>> (e.g. sudo).

    >>
    >> And how is that not running as root or rootlike for the duration of the
    >> program which needs root access for the accesses he was mentioning?

    >
    > Oddly enough key system processes are running as root on his
    > box by default (believe it or not).


    I know. What is your point? Seriously.

    > What was your point? Other than trying to pick a fight?


    my point was that running it via sudo is running it as root in most
    cases. He wanted a way to access these things NOT as root. No
    fight. Just asking why you answered as you did.

    >
    > I was trying to help.. and you were???


    Correcting you.

    >
    > Sometimes people don't understand security. They simply
    > need somebody to help them to better understand how things
    > work. If you can't run something in a controlled manner
    > as root.. you've got to simply turn the machine off.


    WTF are you talking about?

  11. Re: API to collect some unique IDs

    ["Followup-To:" header set to comp.os.linux.security.]

    On 2008-02-23, Dirk T. Verbeek wrote:
    >
    > Having a look in /etc/fstab for the UUID of the hard disk is more unique
    > yet it can be spoofed.


    Having the UUID listed at all in fstab is not guaranteed. (And IIRC the
    UUID is for the given filesystem, not the entire disk.)

    --keith

    --
    kkeller-usenet@wombat.san-francisco.ca.us
    (try just my userid to email me)
    AOLSFAQ=http://www.therockgarden.ca/aolsfaq.txt
    see X- headers for PGP signature information


  12. Re: API to collect some unique IDs

    Keith Keller wrote:

    > ["Followup-To:" header set to comp.os.linux.security.]
    >
    > On 2008-02-23, Dirk T. Verbeek wrote:
    >>
    >> Having a look in /etc/fstab for the UUID of the hard disk is more unique
    >> yet it can be spoofed.

    >
    > Having the UUID listed at all in fstab is not guaranteed. (And IIRC the
    > UUID is for the given filesystem, not the entire disk.)
    >
    > --keith
    >

    IMHO, using UUID for internal fixed drives is bull****. No need for that
    crap.

    Cheers.

    --
    The world can't afford the rich.

    Q: What OS is built for lusers?
    A: Which one requires running lusermgr.msc to create them?

    My Killfile List: Frank, dennis@home ... Sorry, won't be able to read your
    BS any longer.

  13. Re: API to collect some unique IDs

    Keith Keller schreef:
    > ["Followup-To:" header set to comp.os.linux.security.]
    >
    > On 2008-02-23, Dirk T. Verbeek wrote:
    >> Having a look in /etc/fstab for the UUID of the hard disk is more unique
    >> yet it can be spoofed.

    >
    > Having the UUID listed at all in fstab is not guaranteed. (And IIRC the
    > UUID is for the given filesystem, not the entire disk.)
    >
    > --keith
    >

    I suddenly remember something interresting.
    I replaced the 60GB HD from my laptop with a 160GB one and put the old
    one in an USB enclosure.
    When I hooked it up Linux would not accept it because it had the same
    UUID as the new internal HD.
    Meaning the UUID for the new disk was during formatting generated using
    some inputs of the hardware present resulting in exactly the same number
    as the original HD.
    In a way this means it would remain the same (uniquely identifying!) for
    this particular computer but be different on another.

    I'm sure to remember there's some stuff on the net about how the HD UUID
    is generated.

  14. Re: API to collect some unique IDs

    Hadron wrote:
    > Chris Cox writes:
    >
    >> Hadron wrote:
    >>> Chris Cox writes:
    >>>
    >>>> Alex wrote:

    ....snippity...
    >> Oddly enough key system processes are running as root on his
    >> box by default (believe it or not).

    >
    > I know. What is your point? Seriously.
    >
    >> What was your point? Other than trying to pick a fight?

    >
    > my point was that running it via sudo is running it as root in most
    > cases. He wanted a way to access these things NOT as root. No
    > fight. Just asking why you answered as you did.


    Sigh.... so you believe that nothing runs as root? Of course not.
    (do you?) My point is that the OP may have been told
    some misinformation about root and possibly nothing about role
    based security. That's all.

    >
    >> I was trying to help.. and you were???

    >
    > Correcting you.


    But you didn't correct anything. You just made ... well...
    remarks because you felt like it (I guess).

    >
    >> Sometimes people don't understand security. They simply
    >> need somebody to help them to better understand how things
    >> work. If you can't run something in a controlled manner
    >> as root.. you've got to simply turn the machine off.

    >
    > WTF are you talking about?


    Root, while often attacked as a weakness in *ix systems, is
    also one of its greatest strengths. I merely want to bring
    some balance if the OP is fearing a program running as root
    since ... like it or not... *ix can't function well without
    it. That's all. I'll admit, there's a lot of efforts out
    there to minimize root... especially where it's certainly
    not required, but we're still a ways away from a totally
    rootless system (and arguably such a thing is really not
    desirable... even if it is possible).


  15. Re: API to collect some unique IDs

    NoStop wrote:
    > Keith Keller wrote:
    >
    >> ["Followup-To:" header set to comp.os.linux.security.]
    >>
    >> On 2008-02-23, Dirk T. Verbeek wrote:
    >>> Having a look in /etc/fstab for the UUID of the hard disk is more unique
    >>> yet it can be spoofed.

    >> Having the UUID listed at all in fstab is not guaranteed. (And IIRC the
    >> UUID is for the given filesystem, not the entire disk.)
    >>
    >> --keith
    >>

    > IMHO, using UUID for internal fixed drives is bull****. No need for that
    > crap.


    uuid isn't perfect. It's better when the drive can be identified by
    it's model and serial number (by-id)... and most can. But you're right that
    even that isn't always what you want to do... but some WILL want it.
    So it's there...

    It's useful when drives change position due to new controllers coming
    online (just one example). Using a more persistent name prevents
    the pain of dealing with device renames (e.g. /dev/sda becoming /dev/sdb
    all of the sudden). But obviously not perfect in cases were a
    drive fails and gets replaced... pros and cons either way....

  16. Re: API to collect some unique IDs

    Chris Cox writes:

    > Hadron wrote:
    >> Chris Cox writes:
    >>
    >>> Hadron wrote:
    >>>> Chris Cox writes:
    >>>>
    >>>>> Alex wrote:

    > ...snippity...
    >>> Oddly enough key system processes are running as root on his
    >>> box by default (believe it or not).

    >>
    >> I know. What is your point? Seriously.
    >>
    >>> What was your point? Other than trying to pick a fight?

    >>
    >> my point was that running it via sudo is running it as root in most
    >> cases. He wanted a way to access these things NOT as root. No
    >> fight. Just asking why you answered as you did.

    >
    > Sigh.... so you believe that nothing runs as root? Of course not.


    Once more : the OP asked how to access certain info WITHOUT THEM RUNNING
    AS ROOT. You then told him how to run the programs as root(sudo). What
    is so hard for you to understand.

    Why you think I do not think certain things run as root is anyones guess
    as I certainly never said that and I certainly do not think it.

    > (do you?) My point is that the OP may have been told
    > some misinformation about root and possibly nothing about role
    > based security. That's all.


    That might be your point now. It certainly was not earlier.

    To try and stop you making a bigger fool of yourself I will quote the
    original:

    ,----
    | > Is there any API to collect some unique IDs (such as CPU id,
    | > harddisk id, SKU, etc) from the system w/o running the final
    | > software as root?
    `----

    See? He is asking for APIs which DO NOT NEED TO RUN AS ROOT. Get it yet?
    By using SUDO he ****IS**** running the final SW as ROOT.




  17. Re: API to collect some unique IDs

    On 2008-02-23, NoStop wrote:
    > Keith Keller wrote:
    >>
    >> Having the UUID listed at all in fstab is not guaranteed. (And IIRC the
    >> UUID is for the given filesystem, not the entire disk.)

    >
    > IMHO, using UUID for internal fixed drives is bull****. No need for that
    > crap.


    Regardless, it's still available. And as I wrote, it's for filesystems,
    not drives.

    --keith

    --
    kkeller-usenet@wombat.san-francisco.ca.us
    (try just my userid to email me)
    AOLSFAQ=http://www.therockgarden.ca/aolsfaq.txt
    see X- headers for PGP signature information


  18. Re: API to collect some unique IDs

    Hadron wrote:
    > Chris Cox writes:
    >
    >
    >>Hadron wrote:
    >>
    >>>Chris Cox writes:
    >>>
    >>>
    >>>>Hadron wrote:
    >>>>
    >>>>>Chris Cox writes:
    >>>>>
    >>>>>
    >>>>>>Alex wrote:

    >>
    >>...snippity...
    >>
    >>>>Oddly enough key system processes are running as root on his
    >>>>box by default (believe it or not).
    >>>
    >>>I know. What is your point? Seriously.
    >>>
    >>>
    >>>>What was your point? Other than trying to pick a fight?
    >>>
    >>>my point was that running it via sudo is running it as root in most
    >>>cases. He wanted a way to access these things NOT as root. No
    >>>fight. Just asking why you answered as you did.

    >>
    >>Sigh.... so you believe that nothing runs as root? Of course not.

    >
    >
    > Once more : the OP asked how to access certain info WITHOUT THEM RUNNING
    > AS ROOT. You then told him how to run the programs as root(sudo). What
    > is so hard for you to understand.
    >
    > Why you think I do not think certain things run as root is anyones guess
    > as I certainly never said that and I certainly do not think it.
    >
    >
    >>(do you?) My point is that the OP may have been told
    >>some misinformation about root and possibly nothing about role
    >>based security. That's all.

    >
    >
    > That might be your point now. It certainly was not earlier.
    >
    > To try and stop you making a bigger fool of yourself I will quote the
    > original:
    >
    > ,----
    > | > Is there any API to collect some unique IDs (such as CPU id,
    > | > harddisk id, SKU, etc) from the system w/o running the final
    > | > software as root?
    > `----
    >
    > See? He is asking for APIs which DO NOT NEED TO RUN AS ROOT. Get it yet?
    > By using SUDO he ****IS**** running the final SW as ROOT.


    Did anyone notice that:

    1. The OP has not taken part of this discussion since
    the original question.

    2. The OP's question has a strong stink of copy protection,
    which the open source community shudders at.

    --

    Tauno Voipio
    tauno voipio (at) iki fi

  19. Re: API to collect some unique IDs

    On Feb 24, 10:14 am, Tauno Voipio wrote:

    > 2. The OP's question has a strong stink of copy protection,
    > which the open source community shudders at.


    I wish that were true. The truth is that the open source community
    shudders at copy protection for closed source programs (to prevent
    copying in violation of the license) but raises a holy stink when
    anyone tries to copy open source software in violation of its license.

    DS

  20. Re: API to collect some unique IDs

    Hadron wrote:
    ....
    > To try and stop you making a bigger fool of yourself I will quote the
    > original:
    >
    > ,----
    > | > Is there any API to collect some unique IDs (such as CPU id,
    > | > harddisk id, SKU, etc) from the system w/o running the final
    > | > software as root?
    > `----
    >
    > See? He is asking for APIs which DO NOT NEED TO RUN AS ROOT. Get it yet?
    > By using SUDO he ****IS**** running the final SW as ROOT.


    Oh I get that you want to fight.. and not discuss.. I'm upset
    at your general rudeness. That's all. Maybe we'll meet someday.
    I'll be the guy on the ground looking for my glasses... you'll
    be the guy with some cuts on his fist.

    To each his own I suppose....

+ Reply to Thread
Page 1 of 2 1 2 LastLast